使用Ubuntu中提供的内置System Monitor GUI工具。

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

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

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

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

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

除了答案中列出的解决方案之外，您还可以使用Linux命令“top”。它提供了运行系统的动态实时视图，并给出了整个系统的CPU和内存使用情况，以及每个程序的百分比：

top

通过程序PID进行过滤：

top -p <PID>

按程序名过滤：

top | grep <PROCESS NAME>

“顶部”还提供一些字段，例如：

VIRT—虚拟映像（kb）：任务使用的虚拟内存总量

RES——驻留大小（kb）：任务使用的非交换物理内存；RES=代码+数据。

DATA——数据+堆栈大小（kb）：除可执行代码外，专用于其他代码的物理内存量，也称为“数据驻留集”大小或DRS。

SHR—共享内存大小（kb）：任务使用的共享内存量。它只是反映了可能与其他进程共享的内存。

此处参考。

使用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

这是对工具和问题的极好总结：archive.org链接

我会引用它，这样更多的开发者会真正阅读它。

如果要分析整个系统的内存使用情况，或者要彻底分析一个应用程序的内存使用（而不仅仅是其堆使用情况），请使用exmap。对于整个系统分析，找到具有最高有效使用率的进程，它们实际上占用了最多的内存，找到具有最大可写使用率的过程，它们创建了最多的数据（因此可能泄漏或数据使用效率很低）。选择这样的应用程序并在第二个列表视图中分析其映射。有关详细信息，请参见exmap部分。还可以使用外部停止检查X资源的高使用率，特别是在X服务器的进程占用大量内存的情况下。有关详细信息，请参见外部停止部分。如果要检测泄漏，请使用valgrind或kmtrace。如果您想分析应用程序的堆（malloc等）使用情况，可以在memprof或kmtrace中运行它，分析应用程序并在函数调用树中搜索最大的分配。有关更多详细信息，请参见其章节。