Monday, May 08, 2006

Breaking news: g-s-m now gives useful information

Tired of guessing what 20 MB of RSS really means? Want numbers that give you statistics that aren't lies. Wait no longer. With a simple patch gnome-system-monitor version 2.14.2 gives useful information when combined with a modern kernel (in FC5, Ubuntu Dapper, or SUSE 10.1).

This new statistic is the Writable Memory column in gnome-system-monitor. You may have to modify your preferences to expose this. This column gives you the private dirty RSS, the memory statistic which I've talked about in previous posts. This is the amount of memory that is private to your process, modified from the on disk version, and loaded into memory. The number is a very good indication of how much memory you are using.

Note how the Writable Memory column is less than the traditionally used RSS. This is becaused shared rss is not taken in to account.

I'd like to propose that we make One True Statistic for g-s-m: writable memory + X memory. This is an very accurate accounting of memory usage. I think it's as good as we can get without further kernel patches.

4 comments:

Hongli said...

Which exact kernel version does it require? I'm an FC4 user. And are there any commandline tools to get the same numbers?

Anonymous said...

This patch is in Dapper Drake (System Monitor 2.14.3).

cwillu said...

Another thing that may be worth considering is 'shared' libraries that are only used by a single process.

'clock-applet' is currently showing 31M in vm, and 6.4M in resident. According to 'writable memory' and 'x server memory', there's only about 500k actually private to the applet, which doesn't seem bad. But I don't think that those two columns will always tell the whole story.

There's a ps_mem.py script floating around which uses /proc/{pid}/smaps. I hacked it up to charge shared libraries that are only used once to the process that references them (and I believe only if it's in resident memory, but my understanding could be faulty).

In any case, 'clock-applet' shows up as using 2.9M resident via this approach, implying that there's 2-odd megs of shared libraries that are only used by the clock applet; at this point, I get suspicious. Is there any particular reason that /usr/lib/gnome-panel/clock-applet should be using 2752kb of resident? :)

cwillu@gmail.com

pixelbeat said...

I just updated the ps_mem.py script
to use PSS when available (in kernel 2.6.23 an later).

www.pixelbeat.org/scripts/ps_mem.py