Re^2: large .so sizes under x86

I'm seeing libc.so.6:

% ldd ./auto/Time/HiRes/HiRes.so
    librt.so.1 => /lib64/librt.so.1 (0x00002af3572c2000)
    libc.so.6 => /lib64/libc.so.6 (0x00002af3574cb000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00002af357822000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003bf0000000)
[download]

What do you get when you run this script?

use Time::HiRes;

open(SMAPS, "/proc/$$/smaps");
while (<SMAPS>) {
  if (m/^\d/) {
    chomp($lib = (split(' ', $_))[5]);
  } elsif (m/^Size:\s*(\d+.*)/) {
    my $size = $1;
    print "$size $lib\n" if ($lib =~ m/HiRes/);
  }
}
[download]

I am getting (Centos 5.5, perl 5.8):

24 kB /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes
+/HiRes.so
2044 kB /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiR
+es/HiRes.so
4 kB /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes/
+HiRes.so
[download]

Does the 2044 kB entry represent real memory usage (unshared with any other library)? I'm trying to determine how much real memory my application is using.

Comment on Re^2: large .so sizes under x86_64 Select or Download Code

Replies are listed 'Best First'.
Re^3: large .so sizes under x86_64 by Eliya (Vicar) on Apr 08, 2011 at 22:55 UTC
Ah, sorry, I missed that you were talking about memory usage (as opposed to shared object file size). And yes, I do get similar numbers. Note that the "Size" figures (like your 2044 kB) are rather meaningless. You can think of them as the address regions that a process could (in theory) access without causing a segfault. As long as it doesn't, the figure is irrelevant for what one typically thinks of as "memory usage". What's more interesting in this regard is the resident size (RSS), in particular the private (non-shared) pages of it. But note that this is also a somewhat too simplified view of things... Anyhow, for a more detailed analysis of memory usage, you might be interested in exmap. Its docs give a good overview of the terminolgy, btw. Also, there's Linux::Smaps, so you don't have to parse the proc file yourself. And IIRC, there's even a script "out there" (using this module) which assembles the smaps info and creates an easier-to-digest summary report. Unfortunately, I can't remember its name, but maybe you can dig it up...	[reply]

Replies are listed 'Best First'.

Re^3: large .so sizes under x86_64
by Eliya (Vicar) on Apr 08, 2011 at 22:55 UTC

Ah, sorry, I missed that you were talking about memory usage (as opposed to shared object file size). And yes, I do get similar numbers.

Note that the "Size" figures (like your 2044 kB) are rather meaningless. You can think of them as the address regions that a process could (in theory) access without causing a segfault. As long as it doesn't, the figure is irrelevant for what one typically thinks of as "memory usage". What's more interesting in this regard is the resident size (RSS), in particular the private (non-shared) pages of it. But note that this is also a somewhat too simplified view of things...

Anyhow, for a more detailed analysis of memory usage, you might be interested in exmap. Its docs give a good overview of the terminolgy, btw.

Also, there's Linux::Smaps, so you don't have to parse the proc file yourself. And IIRC, there's even a script "out there" (using this module) which assembles the smaps info and creates an easier-to-digest summary report. Unfortunately, I can't remember its name, but maybe you can dig it up...

[reply]