最近整理SDK运行期间占用游戏内存的情况，分析的时候发现有VSS/RSS/PSS/USS四个值，专门整理一下，方便以后查阅。 名词解释： VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存） RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存） PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存） USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存） 大
关键词：VSS、RSS、PSS、USS、_mapcount、pte_present、mem_size_stats。
如何检查Ubuntu Linux上的内存使用情况，我们可以安装并使用Smem内存报告工具来显示Ubutnu Linux系统上的内存使用情况。 Smem是一个命令行工具，用于检查Linux，每个进程的内存使用情况，百分比或图表。 Stellarium smem是一个可以在Linux系统上提供大量内存使用情况报告的工具。 与现有工具不同，smem可以报告比例集合大小（PSS），这是对虚拟内存系统中库和应用程序使用的内存量的更有意义的表示。 📷 Smem使用被称为Resident Set Size(RSS)的标准
smem 是Linux系统上的一款可以生成多种内存耗用报告的命令行工具。与现有工具不一样的是 smem 可以报告 PSS【Proportional Set Size（按比例占用大小）】，这是一种更有意义的指标。可以衡量虚拟内存系统的库和应用程序所占用的内存数量。
上一篇我们了解了内存在内核态是如何管理的，本篇文章我们一起来看下内存在用户态的使用情况，如果上一篇文章说是内核驱动工程师经常面对的内存管理问题，那本篇就是应用工程师常面对的问题。
缺乏足够的物理内存（RAM）的系统的运行速度将显着降低，因为进程在RAM和交换之间移动。如果Linux系统开始运行缓慢，则首先解决的任务之一是释放物理内存。
前言： procrank是一个统计内存使用的神器，包括VSS，PSS，PSS和USS的详细参数。作为一个内存使用的分析工具，简直厉害的不要不要的。 作者尝试过几个Linux发行版，都没有把procrank作为可以安装的包。这也不奇怪，作者接触这个命令的时候，也是在Android中使用到的。尽管后来不从事嵌入式开发了，每当遇到类似的问题时，都会情不自禁的想到这个神奇的工具。在Iaas平台中，统计KSM也是利器。 源代码： 如上面所说，代码选自Android的源代码。为了使用方便，作者在github上做了一份拷
为了了解 Linux 或 macOS 上的内存使用情况，人们通常使用 top 或 htop。我很想看到一个单一的数字：一个进程占用了多少内存。但这些工具所显示的统计数据可能很难理解。对于网页浏览器来说，它甚至更加复杂，因为它们经常运行许多独立的进程。它们在 top 输出中显示为一个长长的列表，每一个都有自己的单独指标。
smem是一个工具，可以提供大量关于 Linux 系统内存使用情况的报告。与现有工具不同，smem 可以报告比例集大小 (PSS)，它更有意义地表示虚拟内存系统中库和应用程序使用的内存量。 由于大部分物理内存通常在多个应用程序之间共享，因此称为常驻集大小 (RSS) 的内存使用标准度量将大大高估内存使用。相反，PSS 衡量每个应用程序在每个共享区域中的公平份额，以给出一个现实的衡量标准。 Smem功能 系统概览列表 按进程、映射、用户输出 按进程、映射或用户过滤输出 来自多个数据源的可配置列 可配置的输出单
/proc/PID/smaps 文件是基于 /proc/PID/maps 的扩展，他展示了一个进程的内存消耗，比同一目录下的maps文件更为详细。
PostgreSQL 查看内存使用的方法比较多, 大部分都是进入到POSTGRESQL 中进行查看的,今天从PostgreSQL 外部来查看内存的使用方式和方法.
#!/usr/bin/env python Try to determine how much RAM is currently being used per program. Note per program, not per process. So for example this script will report RAM used by all httpd process together. In detail it reports: sum(private RAM for program pro
在使用 smem 命令时，有几个注意事项可以帮助你更有效地利用这个工具并避免潜在的误解或错误。以下是几点重要的使用注意事项：
用户经常因为OOM killer造成数据库崩溃问题来找我们寻求帮助。Out Of Memory killer会杀死PG进程，并且是我们遇到的数据库崩溃问题中首要原因。主机内存不足的原因可能有多种，最常见的有：
可以观察到非常有意思的现象，这个进程占用了124%的内存，实际上Swap为0。总占用也没到100%。这是为什么呢？
作者遇到了业务的一个性能抖动问题，在这里介绍一下它的原因和解决办法。 分析 1，page fault 在Linux上，进程分配到的内存是虚拟内存，经过内核的页表管理，会把虚拟内存映射成物理内存。 a，在第一次访问内存的时候，会触发page fault，内核会给进程分配好内存，进程继续执行。 b，内核进行内存回收，可能会把进程的部分内存进行回收，swap到磁盘上，下次访问到再换回来。当然，这个在实际业务上未必会启用swap以防止性能下降。 c，进程自己判断，认为部分内存段时间内不会使用，会尝试把它归还给内核。它的好处是不需要修改进程的虚拟地址空间，只是把内存页面（page）归还给内核，下一次访问到的时候，会因为page fault而重新分配物理内存。 另外需要注意的时候，处理page fault的过程中，需要持有进程的内存的锁（current->mm->mmap_sem）。 2，TLB shootdown 例如某服务器有40CPU，那么就意味着可以同时运行40个task。 例如某业务有30个线程，且这30个线程都很忙，并行执行在30个CPU上。 因为30个线程共享地址空间，它们使用的是相同的页表（page table）。所以在运行这30个线程的CPU上，会加载相同的页表。 当代CPU为了加速TLB查找的速度，会使用cache，也就是说会把对应的页表项（page table entry）加载到TLB cache中。 在运行的某一个时刻，某1个线程执行了上述的page fault的case 3，也就是执行了系统调用int madvise(void *addr, size_t length, MADV_DONTNEED)，想要释放1个page（4K大小），除了需要修改页表释放该page外，还需要确保CPU的TLB cache中也是没有该page的PTE的。因为如果TLB cache还有该PTE，那么CPU访问这个page就不会出错，而这个page已经被释放并分配给其他进程使用的话，就会造成安全问题。 在多核场景下，这个问题就变得更加复杂了。除了运行madvise的线程之后，还需要确保另外的29个线程运行的CPU的TLB cache也是没有该PTE的。为了实现这种效果，需要当前的CPU通知另外的29个CPU，执行clflush或者重新加载cr3。这个通知的过程需要发送IPI（inter processor interrup）。 发送IPI的这个过程，在x86上的体现就是需要CPU执行wrmsr指令，对应的操作是触发ICR。了解虚拟化的朋友应该知道，wrmsr这条指令在虚拟机上需要经过Hypervisor处理，性能更低一些。 除此之外，在执行madvise的过程中，还需要持有当前进程的内存的锁（current->mm->mmap_sem），而且这个锁的粒度比较大。 而jemalloc库，默认情况下，则会释放过期的内存，调用madvise(void *addr, size_t length, MADV_DONTNEED)。 3，smaps/smaps_rollup cat /proc/PID/smaps，可以查看进程的每一段VMA信息。
物理内存：不解释 虚拟内存：进程独享，由操作系统通过地址映射的方式，转换为对物理内存的访问。在32位Linux机器上，每个进程的虚拟内存都是4G。（这里的虚拟内存与操作系统使用中过程常见的虚拟内存概念不同，不要混淆了，如Linux中swap）
从操作系统的角度来说，内存就是一块数据存储区域，是可被操作系统调度的资源。在多任务（进程）的操作系统中，内存管理尤为重要，操作系统需要为每一个进程合理的分配内存资源。所以可以从操作系统对内存分配和回收两方面来理解内存管理机制。
本文主要分析 Linux 系统内存统计的一些指标以及进程角度内存使用监控的一些方法。
理解硬件访问内存的原理,MMU和页表；澄清Linux内核ZONE，buddy，slab管理；澄清用户空间malloc与内核关系，Lazy分配机制；澄清进程的内存消耗的vss,rss,pss,uss概念；澄清内存耗尽的OOM行为；澄清文件背景页面与匿名页，page cache与swap；澄清内存的回收、dirty page的写回，以及一些内存管理/proc/sys/vm sysctl配置的幕后原理；DMA和cache一致性，IOMMU等;给出一些内存相关的调试和优化方法；消除网上各种免费资料的各种误解。
应用版本升级后使用内存突增？如何跟踪？这次MIG专项测试组为大家分享内存问题跟踪实战过程！ MIG专项测试组 致力于为腾讯移动互联网事业群(MIG)提供专项评测及深度优化（性能、功能、安全等）；同时负责探索新的测试理论和方法，研发评测工具及基础组件。 背景 手机管家从4.4升级到4.5后，用户数据反馈待机内存出现了2-4M左右的增长。经过代码排查及MAT分析，发现有几处代码会导致内存增长,只要将这些代码屏蔽掉一部分，内存情况就下降到正常水平。
原文 https://mp.weixin.qq.com/s/8A_y1dlZrUvpaJfbQrVK3w
今天同事反映一个问题，某个测试库修改了密码，并改了相关应用使用的密码后，仍出现一会账户就被锁住，报ORA-28000: the account is locked的错误。 检查过程： 1. 查看资源限制生效参数 SQL> show parameter resource NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resource_limit boolean FALSE FALSE表示未启动资源限制。 2. 查看该用户所用的PROFILE SQL> select resource_name, limit from dba_profiles where profile='DEFAULT'; RESOURCE_NAME LIMIT -------------------------------- ---------------------------------------- COMPOSITE_LIMIT UNLIMITED SESSIONS_PER_USER UNLIMITED CPU_PER_SESSION UNLIMITED CPU_PER_CALL UNLIMITED LOGICAL_READS_PER_SESSION UNLIMITED LOGICAL_READS_PER_CALL UNLIMITED IDLE_TIME UNLIMITED CONNECT_TIME UNLIMITED PRIVATE_SGA UNLIMITED FAILED_LOGIN_ATTEMPTS 10 PASSWORD_LIFE_TIME UNLIMITED PASSWORD_REUSE_TIME UNLIMITED PASSWORD_REUSE_MAX UNLIMITED PASSWORD_VERIFY_FUNCTION NULL PASSWORD_LOCK_TIME 1 PASSWORD_GRACE_TIME 7 其中FAILED_LOGIN_ATTEMPTS表示连续登陆失败的次数，这里表示连续登陆10次失败则锁定用户。 3. 解除用户锁定ALTER USER pss3 ACCOUNT UNLOCK;后观察现象 SQL> select name, lcount from user$ where name='PSS3'; NAME LCOUNT ------------------------------ ---------- PSS3 10 不到一分钟，登陆失败次数就到10次了。 初步结论： 可能有应用仍使用旧的密码登陆，登陆失败后重复尝试，直到10次为止。 但问题就来了： 1. FAILED_LOGIN_ATTEMPTS设置为10次，但未启动resource_limit，为什么还受到10次的限制呢？ 2. 怎么知道还有哪些应用由于未修改密码导致ORA错误呢？ 问题1：FAILED_LOGIN_ATTEMPTS设置为10次，但未启动resource_limit，为什么还受到10次的限制呢？ 这篇MOS文章160528.1(Profile Limits (Resource Parameter(s)) Are Not Enforced / Do Not Work)文章说了一些： After creating a new profile or altering an old one to limit the following profile resources there is no change: SESSIONS_PER_USER CPU_PER_SESSION CPU_PER_CALL CONNECT_TIME IDLE_TIME L
90058 kB: com.tencent.mobileqq (pid 16731)
32位操作系统的内存布局很经典，很多书籍都是以32位系统为例子去讲解的。32位的系统可访问的地址空间为4GB，用户空间为1GB ~ 3GB，内核空间为3GB ~ 4GB。
/proc/meminfo是了解Linux系统内存使用状况的主要接口，我们最常用的”free”、”vmstat”等命令就是通过它获取数据的 ，/proc/meminfo所包含的信息比”free”等命令要丰富得多，然而真正理解它并不容易，比如我们知道”Cached”统计的是文件缓存页，manpage上说是“In-memory cache for files read from the disk (the page cache)”，那为什么它不等于[Active(file)+Inactive(file)]？AnonHugePages与AnonPages、HugePages_Total有什么联系和区别？很多细节在手册中并没有讲清楚，本文对此做了一点探究。
论文: Object Detection Made Simpler by Eliminating Heuristic NMS
PSS 私钥签名流程的一种填充模式。目前主流的RSA签名包括RSA-PSS和RSA-PKCS#1 v1.5。
a). 进程使用的物理内存： find /proc/ -maxdepth 1 -iname "[0-9]*" | xargs -I{} cat {}/smaps | grep Pss: | awk '{s+=$2}END{print s}' b). slab分配占用的内存，采用slab机制主要是解决申请时候浪费page的问题，这一部分的内存并不是application 所占用的，所以要单独列出来, 可以在meminfo 中查看到其占用空间以及可回收空间大小. c). pagetable在虚拟地址到物理地址的转换中发挥着关键的作用，所以也不属于application占用的内存，属于系统所用，所以也单独列出来. 其大小随着内存的变大而变大，可以在meminfo 中找到占用的大小. d). free的内存，这一部分内存是从system的角度看，依然是free的，也就是说这一部分内存还没有被system 进行接管. e). cache/buffer内存的大小，这一部分可以在meminfo 中找到，这里主要是 application 的所使用的cache/buffer. f). 其他原因导致的内存gap, 在下面的示例中，上述所述的6种内存的总和大于实际的总内存，这是因为 shmem 是被application使用的，所以在计算进程使用的物理内存的时候，已经包含了shmem,而cache又计算了一次，因此最后的结果应该是减去SHMEM, 这样 和总内存相比，还有5497KB的gap .那么这个gap 到底应该是available的，还是算作used的，不得而知，那么因为这个gap 不大，所以对于内存的使用状况统计，我们可以暂且忽略该gap， 所以我们可以有如下的公式作为一个参考： total = free + cache + buffer + process_used_via_pss + slab + pagetables - shmem
Accellera的便携式测试和激励标准提供了强大的验证功能，这些功能并不能代替UVM，而是可以增加现有的验证流程。这就是便携式激励和UVM相互作用的方式。
JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存，同时对物理内存的使用做了定量的分析，从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客，以飨读者。 由于物理内存定量分析部分用到了linux kernel虚拟内存管理的知识，读者如果有兴趣了解请看ulk3(《深入理解linux内核第三版》)
url = ‘http://qq.yh31.com/ka/qw/List_%s.html’% i
| 作者：杨一迪，腾讯云数据库后台开发工程师，主要负责腾讯云PostgreSQL、CynosDB等产品后台开发工作。 ---- 现网运维过程中，常有用户咨询实例的内存使用情况，故而和大家一起分享我对于内存占用情况的理解，共同进步。 1 简述 查看进程占用内存情况的方式比较多，包括top命令、/proc/${pid}/smaps文件统计、cgroup统计等。但不同方式的查询结果具体代表什么含义，这里通过一个测试程序，简单验证下这三种查询方式如何反映进程的内存使用情况。想看结论的直接看文末的总结。本文有
问题：我想要监测Linux系统的内存使用状况。有哪些可用的图形界面或者命令行工具来检查当前内存使用情况？
今天介绍的是一篇纯生信分析的单细胞数据挖掘的文献，分析方法是单细胞分析中比较常规的方法（单细胞图谱，细胞通讯），不过有疾病之间的差异比较。
APP要做性能测试，什么样的数据能反应应用的性能情况，如何评估应用的性能状态？ 不知道该如何入手？一起来分析下如何给APP做性能测试。 性能测试三角：性能指标、测试场景、测试工具。 首先要思考选哪些指标来评估性能：内存、cpu、电量还是什么？接着，选择你需要测试的场景，测试场景描述了你需要在何种场景下取性能数据，要测试APP何种功能等等。最后，根据你的指标和场景选择适合你的测试工具。 下面就从这三方面来具体分析。 一、性能指标 常见的性能指标有：内存、CPU、电量、流量、速度/耗时。这里从2个角度分析：
SSB（Synchronization Signal/PBCH, 同步广播块）是5G中使用的最重要的导频信道之一，其作用关系到UE接入小区的很多方面，如小区搜索、波束测量、波束选择、波束恢复等。
Kubernetes v1.25引入了仅适用于无状态Pod的用户命名空间支持。在Kubernetes 1.28中解除了这个限制，经过了1.27版本的一些设计更改。
《全民K歌内存篇1——线上监控与综合治理》 《全民K歌内存篇2——虚拟内存浅析》 《全民K歌内存篇3——native内存分析与监控》 一、简介 在多任务操作系统中，每个进程都拥有独立的虚拟地址空间，通过虚拟地址进行内存访问主要具备以下几点优势： 进程可使用连续的地址空间来访问不连续的物理内存，内存管理方面得到了简化。 实现进程与物理内存的隔离，对各个进程的内存数据起到了保护的作用。 程序可使用远大于可用物理内存的地址空间，虚拟地址在读写前不占用实际的物理内存，并为内存与磁盘的交换提供了便利。 Androi
Spring提供了JdbcTemplate模板类来操作数据库，JdbcTemplate是对原生JDBC进行了全面的封装，统一处理了数据库连接的获取与释放等操作，使用起来比较方便。本节分析JdbcTemplate的源码。
APP要做性能测试，什么样的数据能反应应用的性能情况，如何评估应用的性能状态？ 不知道该如何入手？一起来分析下如何给APP做性能测试。
本人在做手机APP性能数据的过程中，又重新看了一些Android的内存相关知识，对之前写过的一篇APP性能的线程类的方法做了优化，总得来说，就是增加了PSS数据和增加了数据获取之后的数据整理工作。
“问渠那得清如许，为有源头活水来”，通过前沿领域知识的学习，从其他研究领域得到启发，对研究问题的本质有更清晰的认识和理解，是自我提高的不竭源泉。为此，我们特别精选论文阅读笔记，开辟“源头活水”专栏，帮助你广泛而深入的阅读科研文献，敬请关注。
硬件平台: 全志R/V/F/MR/H 系列芯片。软件平台: Tina v3.5 及后续版本。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
云直播
