December 18, 2014
 
 
RSSRSS feed

How do You Really Measure Linux Bloat? - page 2

Different Methods to Query Memory Usage

  • August 27, 2009
  • By Akkana Peck

mem_usage.py

mem_usage.py shows you the memory profile of a single program by process ID.

$ mem_usage.py 4418
Mapped memory:
               Shared            Private
           Clean    Dirty    Clean    Dirty
    r-xp    8364        0    15484        0  -- Code
    rw-p       0        0        0     1704  -- Data
    r--p     704        0      648      516  -- Read-only data
    ---p       0        0        0        0
    rw-s       0      304        0        0
    r--s     800        0       40        0
   total    9868      304    16172     2220
Anonymous memory:
               Shared            Private
           Clean    Dirty    Clean    Dirty
    rwxp       0        0        0     1340  -- Writable code (stack)
    r-xp       0        0        0        0
    rw-p       0        0        0    81048  -- Data (malloc, mmap)
    ---p       0        0        0        0
   total       0        0        0    82388
   ----------------------------------------
   total    9868      304    16172    84608

Is that more useful than psmem.py's summary? Probably -- it gives you an idea of what's dirty and what's clean. Dirty memory can't be shared with other processes.

smem.pl

smem.pl, by Ben Maurer, gives a lot more information on each process -- basically a formatted summary of the smaps file. Output looks like this:

$ smem.pl 4418
VMSIZE:     279600 kb
RSS:        110952 kb total
             10172 kb shared
             16172 kb private clean
             84608 kb private dirty
PRIVATE MAPPINGS
     vmsize   rss clean   rss dirty   file
   15360 kb        0 kb    14432 kb
   20480 kb        0 kb    12064 kb
    9216 kb        0 kb     8588 kb
    8192 kb        0 kb     8192 kb
    9216 kb        0 kb     5924 kb
    4096 kb        0 kb     4096 kb
    3072 kb        0 kb     3072 kb
    4096 kb        0 kb     2904 kb
    2048 kb        0 kb     2020 kb
    2048 kb        0 kb     1876 kb
    9216 kb        0 kb     1036 kb
    9216 kb        0 kb     1032 kb
    9216 kb        0 kb     1032 kb
    1024 kb        0 kb     1024 kb
    1024 kb        0 kb     1020 kb
    1056 kb        0 kb      992 kb   /usr/local/firefox3.5/libxul.so
    6144 kb        0 kb      940 kb
[ ... ]
     192 kb        0 kb      192 kb
     216 kb        0 kb      116 kb   [stack]
      64 kb        0 kb       64 kb
      64 kb        0 kb       64 kb
      52 kb        0 kb       52 kb   /usr/local/firefox3.5/libnssckbi.so
      76 kb        0 kb       40 kb
    1048 kb        0 kb       36 kb
      32 kb        0 kb       32 kb
      32 kb        0 kb       32 kb   /usr/lib/libORBit-2.so.0.1.0
      28 kb        0 kb       28 kb   /usr/lib/libbonobo-2.so.0.0.0
      28 kb        0 kb       28 kb   /usr/local/firefox3.5/libmozjs.so
     256 kb        0 kb       20 kb
... and so on (535 lines for Firefox right now). This is a little more digestible than the raw smaps file, and it's helpfully sorted from largest to smallest, but it's still TMI -- too much information if all you want to know is which apps are bloated.

smem.pl uses the Perl Linux::Smaps CPAN module. Unfortunately, that module isn't available in Debian or Ubuntu, so if you don't have CPAN set up, you may need to install a couple of dependencies, Class:Member and Linux:Smaps. Here's how to do that:

wget http://search.cpan.org/CPAN/authors/id/O/OP/OPI/Class-Member-1.6.tar.gz
tar xf Class-Member-1.6.tar.gz
cd Class-Member-1.6.tar.gz
perl Makefile.PL
make
make test
sudo make install
cd ..

wget http://search.cpan.org/CPAN/authors/id/O/OP/OPI/Linux-Smaps-0.06.tar.gz
tar xf Linux-Smaps-0.06.tar.gz
cd Linux-Smaps-0.06.tar.gz
perl Makefile.PL
make
make test
sudo make install

Exmap

Useful scripts! But none of them does quite what you'd want. Wouldn't it be great to have a program that would measure the shared memory and divide it among all the programs using it? So if you had three programs using libgtk, that library's size would count 1/3 for each of them?

John Berthels has written a program that uses a custom kernel module to get that information. It's called exmap.

That's the good news. The bad news is that it's a bit tricky to get running. There is an Ubuntu package, but it doesn't work (see bugs 186545 and 284863) and Fedora and Gentoo don't have exmap at all.

To build it from source, download 0.10 from the exmap web page and extract the tarball:

tar xvf exmap-0.10.tgz
cd exmap-0.10
Then you'll need to patch it -- at least, the current source didn't build for me. You can get a patch from my web site: exmap-0.10.diff. Apply it:
patch -p0 < exmap-0.10.diff

Assuming the patch applies, you'll also need kernel headers installed, as well as library and development packages for libgtk2.0, libgtkmm-2.4 and libpcre3. On Ubuntu, try

apt-get install linux-headers-generic libpcre3-dev libgtkmm-2.4-dev

Now you can build it:

make
Watch the output carefully -- it doesn't stop on errors, so it may look like it succeeded when it didn't.

Once it builds, it's easy to run. Just load the kernel module and run gexmap (Figure 1):

sudo insmod kernel/exmap.ko
./src/gexmap
If you have problems running gexmap, try it as root, but I didn't need that on Ubuntu.

gexmap gives you a nice GUI interface, so you can click around and examine exactly where your memory is going -- maybe one of the handiest bloat-measuring tools Linux has.

Akkana Peck is a freelance programmer and the author of Beginning GIMP: From Novice to Professional. ��She also stubbornly refuses to part with her ancient Vaio with 192Mb RAM, and remembers when computers only had 4k of memory and people worried a lot more about bloated software.

Sitemap | Contact Us