Memory consumption by a .so file for a running process
I wanted to know how much memory is consumed by C++ standard library for a process running on Linux. There is no straightforward way I could find so I have written a small script to do exactly that.
Script Location: https://gist.github.com/4215536
How to use?
$ wget https://raw.github.com/gist/4215536/6ae899f454fd72ba3b6202724e15f855f80e33b3/mem-usage.rb
$ ruby ./mem-usage.rb /proc/5952/maps | grep libstd
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16: 2988.0 KBs
In the above example, 5952 is the PID of Thunderbird mail client and C++ standard library consumes 2988 KB of memory for this process.
spinningmatt are discussing. 
Siddhesh 1:08 pm on December 6, 2012 Permalink |
It’s actually quite easy to do:
pmap $(pgrep cat) | grep -v “\[” | awk ‘BEGIN{prev=”"; size = 0;} {if (prev == “” || prev == $4) {size=size + $2} else { printf(“%s: %dK\n”, prev, size); size = $2}; prev = $4}’
I’m sure there’s an easier way to do this. Also, you’re only seeing the static sections allocated for the library, not stuff that the library dynamically allocates – that is in the anonymous mappings or in the heap.
tuxdna 1:29 pm on December 6, 2012 Permalink |
@Siddhesh: You are correct. For my purpose I was only concerned about how much more memory would be needed if I link to C++ standard library.
I think there should be a nice tool to do such an analysis.
spinningmatt 1:25 pm on December 6, 2012 Permalink |
$ pmap $(pidof thunderbird)
…
00000032d3400000 916K r-x– /usr/lib64/libstdc++.so.6.0.17
00000032d34e5000 2044K —– /usr/lib64/libstdc++.so.6.0.17
00000032d36e4000 32K r—- /usr/lib64/libstdc++.so.6.0.17
00000032d36ec000 8K rw— /usr/lib64/libstdc++.so.6.0.17
00000032d36ee000 84K rw— [ anon ]
…
Often the dynamic [anon] sections follow their named library. However, I don’t know if that’s intended behavior or a happy accident.
tuxdna 1:27 pm on December 6, 2012 Permalink |
Wow! I didn’t know about pmap at all.
Siddhesh 1:34 pm on December 6, 2012 Permalink |
> Often the dynamic [anon] sections follow their named library.
No they dont. There are no guarantees about location of dynamically allocated address space.