我build立了一个新的服务器（64位Debian），并试图使apache进程尽可能小，禁用任何我不需要的模块。 然后我将pmap输出与一个32位Debian盒子上的apache进行了比较，这个盒子上有更多的模块打开。 我很惊讶地发现，64位机器上的“优化”似乎消耗了更多的内存。
pmap -d（只是摘要行）显示：
64bit: mapped: 188584K writeable/private: 14680K shared: 72K 32bit: mapped: 33824K writeable/private: 7304K shared: 888K 仔细观察输出。 我看到.so库的内存分配的差异。 以libc为例
64位：
00007f9988e8d000 1380 rx-- 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 rx-- 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台机器上的内存分配问题，我真的会得到每GB的内存比我在32位机器上less得多吗？
经过更多的研究，我终于找到这篇文章 ，说这些在pmap输出中的“—–”2MB行并不表示实际的内存使用情况，但是由于性能的原因，64bit上的地址空间是如何使用的。 给出的总结是：
“在64位Linux上有很多共享库的应用程序被报告为每共享库使用2MB以上的实际占用量，这额外的花费并不需要任何RAM或交换空间，只是每个进程中的地址空间足够多在64位平台上供应，其根本原因在于保持图书馆的高效共享，但实施起来有点奇怪。
我仍然觉得很难相信在64位Linux上如何报告进程内存使用情况这个基本的错误/特性的信息是如此之难！