为什么在32位和64位Linux上，同一进程使用pmap查看内存使用量有很大差异？

Question

我正在搭建一个新的服务器（64位Debian），为了尽可能地减小Apache进程的大小，我禁用了不需要的所有模块。然后，我将64位机器上的Apache与开启了更多模块的32位Debian机器上的Apache进行了pmap输出比较。令我惊讶的是，在64位机器上“优化”后的Apache似乎消耗了更多的内存。

pmap -d（只显示摘要行）显示：

64bit: mapped: 188584K    writeable/private: 14680K    shared: 72K

32bit: mapped: 33824K    writeable/private: 7304K    shared: 888K

仔细查看输出结果后，我发现.so库的内存分配存在差异。以libc为例...

64位：

00007f9988e8d000    1380 r-x-- 0000000000000000 008:00001 libc-2.11.3.so

00007f9988fe6000    2044 ----- 0000000000159000 008:00001 libc-2.11.3.so

00007f99891e5000      16 r---- 0000000000158000 008:00001 libc-2.11.3.so

00007f99891e9000       4 rw--- 000000000015c000 008:00001 libc-2.11.3.so

32位：

b7501000    1364 r-x-- 0000000000000000 008:00001 libc-2.7.so

b7656000       4 r---- 0000000000155000 008:00001 libc-2.7.so

b7657000       8 rw--- 0000000000156000 008:00001 libc-2.7.so

因此，64位输出的第二行存在差异。我无法找到任何解释Mode="-----"的分配方式，并且每个.so文件似乎都有一个，并且大小始终为2044或2048。这是否与64位机器上的内存分配有关？相比于32位机器，我是否真的会获得更少的处理器每GB RAM的数量？

- Lemo

---

一个典型的64位程序将会使用更多的内存来存储代码，因为指令（opcode）可能会更长，立即数也可能会更长。而且，与32位相比，内存中的每个指针都要使用两倍的字节数。 - Yann Droneaud

@ydroneaud，你说的有一定道理，但我认为这并不能解释非常大的差异。 - Lemo

Answer 1

经过更多的研究，我终于找到了这篇文章，它说pmap输出中的这些“-----”2MB行并不表示实际的内存使用情况，而是64位地址空间为了提高性能而使用的一个怪癖。 总结如下：

“在64位Linux上具有大量共享库的应用程序被报告每个共享库使用2MB比它们实际占用的要多。这个额外的内存不会占用任何RAM或交换空间，只是占用每个进程中的地址空间，在64位平台上这种资源非常丰富。根本原因与保持库的高效共享有关，但实现方式有点奇怪。”

我仍然很难相信，在64位Linux上报告进程内存使用情况的这个基本错误/特性的信息竟然如此难以找到！

- Lemo

---

你把内存使用量和地址空间使用量弄混了。前者使用昂贵的RAM，而后者不消耗任何资源（只是造成困惑）。请始终使用pmap -x命令，如果RSS为0，则表示只是一个空的地址空间，不会使用任何内存空间。 - kubanczyk