更“真实世界”使用情况的一个好测试是打开应用程序，运行vmstat-s，并检查“活动内存”统计数据。关闭应用程序，等待几秒钟，然后再次运行vmstat-s。

无论释放了多少活动内存，应用程序显然都在使用中。

对此没有一个单一的答案，因为您无法精确指出进程使用的内存量。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将在程序的整个生命周期内为您提供更好的内存使用情况。

使用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工具。

使用smem，它是ps的替代方案，ps计算每个进程的USS和PSS。你可能想要PSS。

USS-独特的集合大小。这是该进程独有的非共享内存量（将其视为U表示唯一内存）。它不包括共享内存。因此，这将低估进程使用的内存量，但当您想忽略共享内存时，这很有用。PSS-比例设置大小。这就是你想要的。它将唯一内存（USS）与共享内存的比例除以共享该内存的进程数相加。因此，它将为您提供每个进程实际使用多少物理内存的准确表示——共享内存真正表示为共享内存。想象一下P代表物理内存。

这与ps和其他实用程序报告的RSS相比如何：

RSS-常驻集大小。这是每个进程使用的共享内存加上非共享内存的数量。如果任何进程共享内存，这将超额报告实际使用的内存量，因为相同的共享内存将被计数多次-再次出现在共享相同内存的其他进程中。因此，它相当不可靠，特别是当高内存进程有很多分叉时——这在服务器中很常见，比如Apache或PHP（FastCGI/FPM）进程。

注意：smem还可以（可选）输出饼图等图形。你不需要这些。如果您只想从命令行使用它，就像您可能使用ps-Av一样，那么您不需要安装Python和Matplotlib推荐的依赖项。

这里再次投票支持Valgrind，但我想补充一点，您可以使用Alleyoop这样的工具来帮助您解释Valgrind生成的结果。

我一直使用这两种工具，并且总是有简洁、无泄漏的代码来自豪地展示它；）

很难确定，但有两件“接近”的事情可以帮助我们。

$ ps aux

将为您提供虚拟大小（VSZ）

您还可以通过转到/proc/$pid/status从/proc文件系统获取详细的统计信息。

最重要的是VmSize，它应该接近ps aux给出的值。

/proc/19420$ cat status
Name:      firefox
State:     S (sleeping)
Tgid:      19420
Pid:       19420
PPid:      1
TracerPid: 0
Uid:       1000    1000    1000    1000
Gid:       1000    1000    1000    1000
FDSize:    256
Groups:    4 6 20 24 25 29 30 44 46 107 109 115 124 1000
VmPeak:    222956 kB
VmSize:    212520 kB
VmLck:          0 kB
VmHWM:     127912 kB
VmRSS:     118768 kB
VmData:    170180 kB
VmStk:        228 kB
VmExe:         28 kB
VmLib:      35424 kB
VmPTE:        184 kB
Threads:   8
SigQ:      0/16382
SigPnd:    0000000000000000
ShdPnd:    0000000000000000
SigBlk:    0000000000000000
SigIgn:    0000000020001000
SigCgt:    000000018000442f
CapInh:    0000000000000000
CapPrm:    0000000000000000
CapEff:    0000000000000000
Cpus_allowed:    03
Mems_allowed:    1
voluntary_ctxt_switches:    63422
nonvoluntary_ctxt_switches: 7171