Cit*_*ght 25 memory virtual-memory
以下是我服务器上mysql和的内存使用情况apache。根据pmapsay的输出，mysql正在使用大约 379M，apache正在使用 277M。
[root@server ~]# pmap 10436 | grep total
total 379564K
[root@server ~]# pmap 10515 | grep total
total 277588K
将其与 的输出进行比较top，我发现值几乎匹配。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10515 apache 20 0 271m 32m 3132 S 0.0 6.6 0:00.73 /usr/sbin/httpd
10436 mysql 20 0 370m 21m 6188 S 0.0 4.3 0:06.07 /usr/libexec/mysqld --basedir=....
现在这些值绝对不是这两个进程的当前内存使用情况，因为如果是的话，它会超过ram我系统上的 512M ，我明白这些是分配给这两个进程的页面大小的事实，而不是真的他们积极使用的内存大小。现在，当我们使用 时pmap -x，我看到一个额外的列Dirty，它显示进程的内存使用量要少得多。如下面的示例所示，第一列Dirty显示的是 15M，而不是 379M。我的问题是：coloumn 下的值Dirty是该进程主动使用的“真实”内存量吗？如果不是，那么我们如何找出进程的真实内存使用情况？不是ps，top原因与上述相同。我们下面有什么吗/proc 这将提供此信息？
[root@server ~]# pmap -x 10436 | grep total
total kB 379564 21528 15340
[root@server ~]#
[root@server ~]# free -m
total used free shared buffers cached
Mem: 489 447 41 0 52 214
-/+ buffers/cache: 180 308
Swap: 1023 0 1023
[root@server ~]#
Gil*_*il' 20
没有给出“进程的实际内存使用情况”的命令，因为没有进程的实际内存使用情况这样的东西。
进程的每个内存页可以是（除其他区别外）：
我认为“脏”数字将 RAM（不是交换）中的所有内容加在一起，而不是由文件支持。这包括共享和非共享内存（尽管在大多数情况下，除了分叉服务器，共享内存仅由内存映射文件组成）。
显示的信息pmap来自和。那是进程的实际内存使用量——它不能用一个数字来概括。/proc/PID/maps/proc/PID/smaps
我将引用我在手册页中为一个应用程序编写的内容，该应用程序执行类似于 top 的分析并从与pmap（例如/proc/[N]/maps）相同的来源绘制信息：
虚拟地址空间 VS。物理内存
在解释上述一些统计数据时，了解虚拟地址空间和物理内存之间的区别很重要。顾名思义，虚拟地址空间不是真实的；它基本上是当前分配给进程的所有内存的映射。这个map的大小限制对于每个进程都是一样的（一般是2-4GB），并且不是累积的（即你可能有几十个或者几百个进程，每个进程都有自己的2-4GB的虚拟地址）空间，在实际只有 512 MB 物理内存的系统上）。
数据实际上不能从虚拟地址空间存储或检索；真实数据需要真实的物理内存。管理一个与另一个的关系是内核的工作。虚拟空间统计信息（VirtualSz、Data+Stack 和 Priv&Write）对于考虑进程的结构和与物理内存使用的关系很有用，但对于实际使用的 RAM 量，物理内存统计信息（ResidentSz、Share 和比例）才是最重要的。
pmap主要是向您报告有关虚拟地址空间的信息。您在top输出中观察到的“值几乎匹配”可能是指 VIRT 图，它与 RES 图非常不同。这些完全对应于我上面标记为“VirtualSz”和“ResidentSz”的内容（VIRT 代表虚拟，RES 代表居民）。
现在，当我们使用 pmap -x 时，我看到一个额外的列脏，它显示进程的内存使用量要少得多。如下面的示例所示，Dirty 列显示 15M，而不是第一列中的 379M。我的问题是：Dirty 列下的值是否是该进程主动使用的“真实”内存量？
不，但有点。“脏”内存是指已经从磁盘加载并随后修改的数据；由于它已被修改，因此它必须是常驻内存的一部分，因为这些更改当前存储在 RAM 中。然而，它并不是它的同义词。