Why do I see big differences in memory usage with pmap for the same process on 32bit and 64bit Linux?

Question

I was setting up a new server (64bit Debian) and, in an attempt to make the apache process as small as possible, disabled any modules that I didn't need. I then compared the pmap output to apache on a 32bit Debian box with lots more modules turned on. I was very surprised to see that the "optimized" one on the 64bit machine seemed to be consuming much more memory.

pmap -d (just the summary line) shows:

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

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

Looking more closely at the output. I see differences in the memory allocations for the .so libs. Taking libc as an example...

64bit:

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

32bit:

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

So the difference is the second line in the 64bit output. I can't find any explanation for those allocations with Mode="-----" and every .so seems to have one and the size is always 2044 or 2048.

Is this something to do with memory allocation on 64but machines and will I really get considerably less procs per GB of RAM than I would on the 32bit machine?

Answer 1

After more research, I finally found this article which says that these "-----" 2MB lines in the pmap output do not indicate actual memory usage but are a quirk of how the address space is used on 64bit for performance reasons. The summary given is:

"Applications with lots of shared libraries on 64-bit Linux are reported as using 2MB more per shared library than they actually occupy. This extra doesn’t cost you any RAM or swap space, just address space within each process, which is in plentiful supply on 64-bit platforms. The underlying reason is to do with keeping libraries efficiently sharable, but the implementation is a little odd."

I'm still finding it hard to believe it was so hard to find information on this fundamental bug/feature in how process memory usage is reported on 64bit Linux!