如何衡量Linux中应用程序或进程的内存使用情况?

在博客文章《了解Linux上的内存使用情况》中,ps并不是一个准确的工具。

为什么ps是“错误的”根据您的看法,ps不会报告进程的实际内存使用情况。它真正要做的是显示如果只有一个进程在运行,每个进程将占用多少实际内存。当然,一台典型的Linux机器在任何给定时间都有几十个进程在运行,这意味着ps报告的VSZ和RSS数字几乎肯定是错误的。

(注:这里详细介绍了这个问题。)


当前回答

还有三种方法可以尝试:

ps aux—排序设备它按%MEM对输出进行排序。ps aux | awk“{打印$2,$4,$11}”|排序-k2r |头-n 15它使用管道进行排序。顶部-a它开始按%MEM排序

(摘自此处)

其他回答

使用ps或类似工具,您只能获得该进程分配的内存页数量。此数字正确,但:

不反映应用程序使用的实际内存量,只反映为其保留的内存量如果页面被共享,例如由多个线程共享或使用动态链接库共享,则可能会产生误导

如果您真的想知道应用程序实际使用的内存量,则需要在探查器中运行它。例如,Valgrind可以让您了解所使用的内存量,更重要的是,了解程序中可能的内存泄漏。Valgrind的堆轮廓仪工具称为“massif”:

Massif是一个堆分析器。它通过定期拍摄程序堆的快照来执行详细的堆分析。它会生成一个图表,显示一段时间内的堆使用情况,包括程序中哪些部分负责最多内存分配的信息。该图由文本或HTML文件补充,该文件包含更多信息,用于确定分配最多内存的位置。Massif运行程序的速度比正常速度慢20倍。

如Valgrind文档中所述,您需要通过Valgrind运行程序:

valgrind --tool=massif <executable> <arguments>

Massif写入内存使用快照的转储(例如Massif.out.1245)。这些快照提供(1)内存使用的时间线,(2)每个快照的程序内存分配位置的记录。分析这些文件的一个很好的图形工具是massif可视化工具。但我发现,与Valgrind一起提供的基于文本的简单工具ms_print已经有了很大的帮助。

要查找内存泄漏,请使用valgrind的(默认)memcheck工具。

对此没有一个单一的答案,因为您无法精确指出进程使用的内存量。Linux下的大多数进程使用共享库。

例如,假设您想计算“ls”进程的内存使用情况。是否只计算可执行文件“ls”使用的内存(如果可以隔离它)?libc怎么样?或者运行“ls”所需的所有其他库?

linux-gate.so.1 =>  (0x00ccb000)
librt.so.1 => /lib/librt.so.1 (0x06bc7000)
libacl.so.1 => /lib/libacl.so.1 (0x00230000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00162000)
libc.so.6 => /lib/libc.so.6 (0x00b40000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00cb4000)
/lib/ld-linux.so.2 (0x00b1d000)
libattr.so.1 => /lib/libattr.so.1 (0x00229000)
libdl.so.2 => /lib/libdl.so.2 (0x00cae000)
libsepol.so.1 => /lib/libsepol.so.1 (0x0011a000)

您可能会认为它们是由其他进程共享的,但“ls”在未加载的情况下无法在系统上运行。

此外,如果您需要知道一个进程需要多少内存来进行容量规划,则必须计算该进程的每个额外副本使用多少内存。我认为/proc/PID/status可能会在一次提供足够的内存使用信息。另一方面,Valgrind将在程序的整个生命周期内为您提供更好的内存使用情况。

虽然这个问题似乎是关于检查当前运行的进程,但我希望看到应用程序从头到尾使用的峰值内存。除了Valgrind,您还可以使用tstime,这要简单得多。它测量“高潮”内存使用情况(RSS和虚拟)。根据这个答案。

注意:只有当内存消耗增加时,此功能才能100%正常工作

如果您想通过给定的进程(或一组已处理的共享公用名称,例如google chrome)监控内存使用情况,可以使用我的bash脚本:

while true; do ps aux | awk ‚{print $5, $11}’ | grep chrome | sort -n > /tmp/a.txt; sleep 1; diff /tmp/{b,a}.txt; mv /tmp/{a,b}.txt; done;

这将持续查找更改并打印它们。

如果进程没有占用太多内存(可能是因为您希望是这样,或者其他命令给出了这个初始指示),并且进程可以承受短时间的停止,您可以尝试使用gcore命令。

gcore <pid>

检查生成的核心文件的大小,以了解特定进程正在使用多少内存。

如果进程使用数百兆字节或千兆字节,这将不会太好,因为根据I/O性能,核心生成可能需要几秒钟或几分钟才能创建。在核心创建过程中,进程被停止(或“冻结”)以防止内存更改。所以要小心。

还要确保生成核心的装载点有足够的磁盘空间,并且系统不会对在该特定目录中创建的核心文件做出负面反应。