我正在使用htop；这是一个非常好的控制台程序，类似于Windows任务管理器。

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

基于对相关问题的回答。

您可以使用SNMP获取网络上特定设备中进程的内存和CPU使用情况：）

要求：

运行进程的设备应安装并运行snmpsnmp应该配置为接受来自运行以下脚本的请求（可以在文件snmpd.conf中配置）您应该知道要监视的进程的进程ID（PID）

笔记：

HOST-ROURCES-MIB:：hrSWRunPerfCPU是此进程消耗的系统CPU资源总量的秒数。请注意，在多处理器系统上，该值可能在实际（墙上时钟）时间的一厘秒内增加超过一厘秒。HOST-ROURCES-MIB:：hrSWRunPerfMem是分配给此进程的实际系统内存总量。

过程监控脚本

echo "IP address: "
read ip
echo "Specfiy PID: "
read pid
echo "Interval in seconds: "
read interval

while [ 1 ]
do
    date
    snmpget -v2c -c public $ip HOST-RESOURCES-MIB::hrSWRunPerfCPU.$pid
    snmpget -v2c -c public $ip HOST-RESOURCES-MIB::hrSWRunPerfMem.$pid
    sleep $interval;
done

Valgrind可以显示详细信息，但它会显著降低目标应用程序的速度，而且大多数时候它会改变应用程序的行为。

Exmap是我还不知道的东西，但似乎需要一个内核模块来获取信息，这可能是一个障碍。

我假设每个人都想知道关于“内存使用”的以下内容。。。在Linux中，单个进程可能使用的物理内存量大致可分为以下几类。

M.匿名映射内存-p专用.d dirty==malloc/mma映射的堆和堆栈分配和写入的内存.c clean==分配、写入、然后释放但尚未回收的malloc/mma映射的堆和堆栈内存.s已共享.d dirty==malloc/maped堆可以在写入时获得副本并在进程之间共享（已编辑）.cclean==malloc/maped堆可以在写入时获得副本，并在进程之间共享（已编辑）M.n命名映射内存-p专用.d dirty==文件映射的写入内存专用.c clean==映射的程序/库文本专用映射.s已共享.d dirty==文件映射的写入内存共享.c clean==映射的库文本共享映射

Android中包含的工具showmap非常有用

virtual                    shared   shared   private  private
size     RSS      PSS      clean    dirty    clean    dirty    object
-------- -------- -------- -------- -------- -------- -------- ------------------------------
       4        0        0        0        0        0        0 0:00 0                  [vsyscall]
       4        4        0        4        0        0        0                         [vdso]
      88       28       28        0        0        4       24                         [stack]
      12       12       12        0        0        0       12 7909                    /lib/ld-2.11.1.so
      12        4        4        0        0        0        4 89529                   /usr/lib/locale/en_US.utf8/LC_IDENTIFICATION
      28        0        0        0        0        0        0 86661                   /usr/lib/gconv/gconv-modules.cache
       4        0        0        0        0        0        0 87660                   /usr/lib/locale/en_US.utf8/LC_MEASUREMENT
       4        0        0        0        0        0        0 89528                   /usr/lib/locale/en_US.utf8/LC_TELEPHONE
       4        0        0        0        0        0        0 89527                   /usr/lib/locale/en_US.utf8/LC_ADDRESS
       4        0        0        0        0        0        0 87717                   /usr/lib/locale/en_US.utf8/LC_NAME
       4        0        0        0        0        0        0 87873                   /usr/lib/locale/en_US.utf8/LC_PAPER
       4        0        0        0        0        0        0 13879                   /usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES
       4        0        0        0        0        0        0 89526                   /usr/lib/locale/en_US.utf8/LC_MONETARY
       4        0        0        0        0        0        0 89525                   /usr/lib/locale/en_US.utf8/LC_TIME
       4        0        0        0        0        0        0 11378                   /usr/lib/locale/en_US.utf8/LC_NUMERIC
    1156        8        8        0        0        4        4 11372                   /usr/lib/locale/en_US.utf8/LC_COLLATE
     252        0        0        0        0        0        0 11321                   /usr/lib/locale/en_US.utf8/LC_CTYPE
     128       52        1       52        0        0        0 7909                    /lib/ld-2.11.1.so
    2316       32       11       24        0        0        8 7986                    /lib/libncurses.so.5.7
    2064        8        4        4        0        0        4 7947                    /lib/libdl-2.11.1.so
    3596      472       46      440        0        4       28 7933                    /lib/libc-2.11.1.so
    2084        4        0        4        0        0        0 7995                    /lib/libnss_compat-2.11.1.so
    2152        4        0        4        0        0        0 7993                    /lib/libnsl-2.11.1.so
    2092        0        0        0        0        0        0 8009                    /lib/libnss_nis-2.11.1.so
    2100        0        0        0        0        0        0 7999                    /lib/libnss_files-2.11.1.so
    3752     2736     2736        0        0      864     1872                         [heap]
      24       24       24        0        0        0       24 [anon]
     916      616      131      584        0        0       32                         /bin/bash
-------- -------- -------- -------- -------- -------- -------- ------------------------------
   22816     4004     3005     1116        0      876     2012 TOTAL

如果您想要比使用Valgrind进行评测更快的东西，并且您的内核更旧，而且您不能使用smaps，那么一个带有显示进程驻留集选项的ps（使用ps-o rss，命令）可以让您快速、合理地了解所使用的非交换内存的实际数量。

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

gcore <pid>

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

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

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