如何衡量Linux中应用程序或进程的内存使用情况?
在博客文章《了解Linux上的内存使用情况》中,ps并不是一个准确的工具。
为什么ps是“错误的”根据您的看法,ps不会报告进程的实际内存使用情况。它真正要做的是显示如果只有一个进程在运行,每个进程将占用多少实际内存。当然,一台典型的Linux机器在任何给定时间都有几十个进程在运行,这意味着ps报告的VSZ和RSS数字几乎肯定是错误的。
(注:这里详细介绍了这个问题。)
如何衡量Linux中应用程序或进程的内存使用情况?
在博客文章《了解Linux上的内存使用情况》中,ps并不是一个准确的工具。
为什么ps是“错误的”根据您的看法,ps不会报告进程的实际内存使用情况。它真正要做的是显示如果只有一个进程在运行,每个进程将占用多少实际内存。当然,一台典型的Linux机器在任何给定时间都有几十个进程在运行,这意味着ps报告的VSZ和RSS数字几乎肯定是错误的。
(注:这里详细介绍了这个问题。)
当前回答
这是对工具和问题的极好总结:archive.org链接
我会引用它,这样更多的开发者会真正阅读它。
如果要分析整个系统的内存使用情况,或者要彻底分析一个应用程序的内存使用(而不仅仅是其堆使用情况),请使用exmap。对于整个系统分析,找到具有最高有效使用率的进程,它们实际上占用了最多的内存,找到具有最大可写使用率的过程,它们创建了最多的数据(因此可能泄漏或数据使用效率很低)。选择这样的应用程序并在第二个列表视图中分析其映射。有关详细信息,请参见exmap部分。还可以使用外部停止检查X资源的高使用率,特别是在X服务器的进程占用大量内存的情况下。有关详细信息,请参见外部停止部分。如果要检测泄漏,请使用valgrind或kmtrace。如果您想分析应用程序的堆(malloc等)使用情况,可以在memprof或kmtrace中运行它,分析应用程序并在函数调用树中搜索最大的分配。有关更多详细信息,请参见其章节。
其他回答
如果您想要比使用Valgrind进行评测更快的东西,并且您的内核更旧,而且您不能使用smaps,那么一个带有显示进程驻留集选项的ps(使用ps-o rss,命令)可以让您快速、合理地了解所使用的非交换内存的实际数量。
使用smem,它是ps的替代方案,ps计算每个进程的USS和PSS。你可能想要PSS。
USS-独特的集合大小。这是该进程独有的非共享内存量(将其视为U表示唯一内存)。它不包括共享内存。因此,这将低估进程使用的内存量,但当您想忽略共享内存时,这很有用。PSS-比例设置大小。这就是你想要的。它将唯一内存(USS)与共享内存的比例除以共享该内存的进程数相加。因此,它将为您提供每个进程实际使用多少物理内存的准确表示——共享内存真正表示为共享内存。想象一下P代表物理内存。
这与ps和其他实用程序报告的RSS相比如何:
RSS-常驻集大小。这是每个进程使用的共享内存加上非共享内存的数量。如果任何进程共享内存,这将超额报告实际使用的内存量,因为相同的共享内存将被计数多次-再次出现在共享相同内存的其他进程中。因此,它相当不可靠,特别是当高内存进程有很多分叉时——这在服务器中很常见,比如Apache或PHP(FastCGI/FPM)进程。
注意:smem还可以(可选)输出饼图等图形。你不需要这些。如果您只想从命令行使用它,就像您可能使用ps-Av一样,那么您不需要安装Python和Matplotlib推荐的依赖项。
我正在使用Arch Linux,有一个很棒的软件包叫做ps_mem:
ps_mem -p <pid>
示例输出
$ ps_mem -S -p $(pgrep firefox)
Private + Shared = RAM used Swap used Program
355.0 MiB + 38.7 MiB = 393.7 MiB 35.9 MiB firefox
---------------------------------------------
393.7 MiB 35.9 MiB
=============================================
#!/bin/ksh
#
# Returns total memory used by process $1 in kb.
#
# See /proc/NNNN/smaps if you want to do something
# more interesting.
#
IFS=$'\n'
for line in $(</proc/$1/smaps)
do
[[ $line =~ ^Size:\s+(\S+) ]] && ((kb += ${.sh.match[1]}))
done
print $kb
如果进程没有占用太多内存(可能是因为您希望是这样,或者其他命令给出了这个初始指示),并且进程可以承受短时间的停止,您可以尝试使用gcore命令。
gcore <pid>
检查生成的核心文件的大小,以了解特定进程正在使用多少内存。
如果进程使用数百兆字节或千兆字节,这将不会太好,因为根据I/O性能,核心生成可能需要几秒钟或几分钟才能创建。在核心创建过程中,进程被停止(或“冻结”)以防止内存更改。所以要小心。
还要确保生成核心的装载点有足够的磁盘空间,并且系统不会对在该特定目录中创建的核心文件做出负面反应。