如何衡量Linux中应用程序或进程的内存使用情况?
在博客文章《了解Linux上的内存使用情况》中,ps并不是一个准确的工具。
为什么ps是“错误的”根据您的看法,ps不会报告进程的实际内存使用情况。它真正要做的是显示如果只有一个进程在运行,每个进程将占用多少实际内存。当然,一台典型的Linux机器在任何给定时间都有几十个进程在运行,这意味着ps报告的VSZ和RSS数字几乎肯定是错误的。
(注:这里详细介绍了这个问题。)
如何衡量Linux中应用程序或进程的内存使用情况?
在博客文章《了解Linux上的内存使用情况》中,ps并不是一个准确的工具。
为什么ps是“错误的”根据您的看法,ps不会报告进程的实际内存使用情况。它真正要做的是显示如果只有一个进程在运行,每个进程将占用多少实际内存。当然,一台典型的Linux机器在任何给定时间都有几十个进程在运行,这意味着ps报告的VSZ和RSS数字几乎肯定是错误的。
(注:这里详细介绍了这个问题。)
当前回答
如果进程没有占用太多内存(可能是因为您希望是这样,或者其他命令给出了这个初始指示),并且进程可以承受短时间的停止,您可以尝试使用gcore命令。
gcore <pid>
检查生成的核心文件的大小,以了解特定进程正在使用多少内存。
如果进程使用数百兆字节或千兆字节,这将不会太好,因为根据I/O性能,核心生成可能需要几秒钟或几分钟才能创建。在核心创建过程中,进程被停止(或“冻结”)以防止内存更改。所以要小心。
还要确保生成核心的装载点有足够的磁盘空间,并且系统不会对在该特定目录中创建的核心文件做出负面反应。
其他回答
使用smem,它是ps的替代方案,ps计算每个进程的USS和PSS。你可能想要PSS。
USS-独特的集合大小。这是该进程独有的非共享内存量(将其视为U表示唯一内存)。它不包括共享内存。因此,这将低估进程使用的内存量,但当您想忽略共享内存时,这很有用。PSS-比例设置大小。这就是你想要的。它将唯一内存(USS)与共享内存的比例除以共享该内存的进程数相加。因此,它将为您提供每个进程实际使用多少物理内存的准确表示——共享内存真正表示为共享内存。想象一下P代表物理内存。
这与ps和其他实用程序报告的RSS相比如何:
RSS-常驻集大小。这是每个进程使用的共享内存加上非共享内存的数量。如果任何进程共享内存,这将超额报告实际使用的内存量,因为相同的共享内存将被计数多次-再次出现在共享相同内存的其他进程中。因此,它相当不可靠,特别是当高内存进程有很多分叉时——这在服务器中很常见,比如Apache或PHP(FastCGI/FPM)进程。
注意:smem还可以(可选)输出饼图等图形。你不需要这些。如果您只想从命令行使用它,就像您可能使用ps-Av一样,那么您不需要安装Python和Matplotlib推荐的依赖项。
使用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工具。
没有任何简单的计算方法。但有些人试图得到一些好的答案:
ps_mem.pyGitHub上的ps_mem.py
使用时间。
不是Bash内置时间,而是您可以找到的时间,例如/usr/bin/time。
下面是它的内容,在一个简单的ls上:
$ /usr/bin/time --verbose ls
(...)
Command being timed: "ls"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2372
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 1
Minor (reclaiming a frame) page faults: 121
Voluntary context switches: 2
Involuntary context switches: 9
Swaps: 0
File system inputs: 256
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
更“真实世界”使用情况的一个好测试是打开应用程序,运行vmstat-s,并检查“活动内存”统计数据。关闭应用程序,等待几秒钟,然后再次运行vmstat-s。
无论释放了多少活动内存,应用程序显然都在使用中。