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

我正在设置一台新服务器(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 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.

这与64but机器上的内存分配有关吗？与32bit机器上的内存相比,我每GB RAM会获得更少的处理吗？

解决方法:

经过更多研究,我最终发现this article,它表示pmap输出中的这些“ —–” 2MB行并不表示实际的内存使用情况,而是出于性能原因如何在64位上使用地址空间的怪癖.给出的摘要是：

“据报道,在64位Linux上具有许多共享库的应用程序每个共享库使用的内存比实际占用的内存多2MB.这额外的开销不会花费您任何RAM或交换空间,而只是在每个进程内分配地址空间,这是很多的它是在64位平台上提供的.根本原因是与保持库的有效共享有关,但是实现有些奇怪.”

我仍然很难相信,很难找到有关此基本错误/功能的信息,以了解如何在64位Linux上报告进程内存使用情况！

标签：pmap,memory-management,linux
来源： https://codeday.me/bug/20191201/2083005.html