Looking close at memory usage

Working with 16Mb of physical memory has underscored the importance of two things: first, lightweight applications, and second, keeping a close eye on what is taking up space.

System monitors such as htop are useful for the second point, although using a monitor to watch memory use defeats the purpose to a small degree; it does, after all, take up space. For a shorter, quicker peek, this little script does a great job. Here’s what the output looks like:

 Private  +   Shared  =  RAM used	Program 

  0.0 KiB +  10.0 KiB =  10.0 KiB	dhcpcd
  0.0 KiB +  11.5 KiB =  11.5 KiB	agetty
  0.0 KiB +  12.0 KiB =  12.0 KiB	udevd
  0.0 KiB +  12.5 KiB =  12.5 KiB	startx
  0.0 KiB +  22.5 KiB =  22.5 KiB	xinit
  0.0 KiB +  37.0 KiB =  37.0 KiB	hnb
  0.0 KiB +  42.0 KiB =  42.0 KiB	mc
  0.0 KiB +  49.0 KiB =  49.0 KiB	vim (2)
  0.0 KiB +  49.5 KiB =  49.5 KiB	musca
  0.0 KiB +  50.5 KiB =  50.5 KiB	charm
 40.0 KiB +  11.5 KiB =  51.5 KiB	init
 96.0 KiB +  43.0 KiB = 139.0 KiB	tty-clock
240.0 KiB +  68.5 KiB = 308.5 KiB	htop
312.0 KiB +  41.5 KiB = 353.5 KiB	alpine
500.0 KiB + 243.0 KiB = 743.0 KiB	bash (4)
736.0 KiB +  51.0 KiB = 787.0 KiB	centerim
768.0 KiB +  77.0 KiB = 845.0 KiB	urxvtd
996.0 KiB +  49.0 KiB =   1.0 MiB	Xorg
---------------------------------
                          4.5 MiB
=================================

 Private  +   Shared  =  RAM used	Program 

I find that interesting mostly because it helps answer a long-standing question, of how it all fits. But it also puts a few things into perspective, like the fact that Musca takes up less space than tty-clock, or that htop and alpine are standing on the same amount of ground, more or less.

On a bigger system the results might be a little more intersting. And now I can take a more critical approach to lightweight versus heavyweight software, with some numbers to back myself up. :twisted:

P.S.: Thanks to LinuxPlanet for pointing it out. ;)

About these ads

22 thoughts on “Looking close at memory usage

  1. Ali Gündüz

    This was exactly what I was looking for, too. It makes analyzing memory usage much simpler and lighter. I mean, who doesn’t like a program that gives results by just printing plain text? :)

    The other day, I was experimenting to see what was my minimal memory usage on my thinkpad x200s laptop. And, as you can see in the picture linked below, memory usage of htop itself was limiting the accuracy:

    [BTW I'm thinking the main reasons for it being still too large (at least in K.Mandla standards) are the large framebuffer resolution and a great variety of loaded kernel modules.]

    I also uploaded a simple PKGBUILD for this script to the ArchLinux AUR:

    http://aur.archlinux.org/packages.php?ID=29703

    Reply
  2. hdrev

    i tried to run that script but i get this:
    memusage.sh: line 64: import: command not found
    memusage.sh: line 66: syntax error near unexpected token `!=’
    memusage.sh: line 66: `if os.geteuid() != 0:’

    oh, and congratulations, maybe it dosnt seem great for you, but having a 16mb pc in shape is a big thing

    Reply
  3. CorkyAgain

    Instead of a single snapshot, shouldn’t you be taking a series of samples over a prolonged period of time — similar to the way a profiler gathers statistics on what parts of a program use the most CPU time?

    A program’s memory usage is usually not constant, and your single snapshot is very likely to have missed its peaks. But you need to know about those peaks if you’re trying to evaluate the load a given mix of applications puts on the system.

    If I were you, btw, I’d ditch that tty clock, and replace bash with something lighter-weight.

    Reply
    1. K.Mandla Post author

      Yes, an average over time might be more “accurate,” in a manner of speaking. If anyone can adapt the script to do that, it would be cool.

      And yes, tty-clock is something of a heavyweight by comparison. Another of the lessons learned by this. ;)

      Reply
  4. ArmorNick

    What an epiphany; one of your heaviest apps is actually a clock. Go figure :D .

    You probably already know this, but for those who don’t, the Arch Wiki has a very good page on lightweight apps.

    Reply
  5. kalex

    Cool idea to use a script for this. When I play with it,though, the total doesn’t even come close to matching up with the output from ‘free -m’. Am I missing something?

    Reply
    1. K.Mandla Post author

      Not sure. Seems like the numbers should more or less correspond, but free -m and this script might calculate things differently. If you check back against the description of the script and maybe the man pages for free, it might give you an idea.

      On my machine, the numbers correspond roughly to what htop reports. I don’t often rely on free -m, mostly because I always found the output to be somewhat scattered.

      As for how to trim X’s profile … I wish I knew.

      Reply
  6. the_englishman

    How did you get x to use so little memory? Mine is using 2.9% of my 1 gig in puppy linux fluxbox version. Any idea how I can get ot down? Also, htop lists the command as…

    x :0 -br -nolisten tcp

    Any idea what any of those flags mean?

    Reply
  7. K.Mandla Post author

    X -help says:

    [:DISPLAY]
    -br ... create root window with black background
    -nolisten string ... don't listen on protocol

    I have a feeling different distros assign different default flags for X sessions though. My Crux sessions start with only x :0 -auth /home/kmandla/.serverauth.XXX.

    Reply
  8. Pingback: Mingetty and dash « Motho ke motho ka botho

  9. Pingback: A text editor in 2.5Kb « Motho ke motho ka botho

  10. Pingback: Shaving megabytes: cplay and mcplay « Motho ke motho ka botho

  11. Pingback: X and Openbox in 12Mb « Motho ke motho ka botho

  12. Fransje

    Nice script indeed!
    I do encounter a problem however.. When comparing the python script to the values given by gnome-system-monitor, the results I get are off by about 60 Mb, with gnome-system-monitor giving me a higher memory usage in the order of 20%. This is huge! Would anybody know where this is coming from?
    Kind regards.

    Reply
  13. Pingback: A clever memory script in perl « Motho ke motho ka botho

  14. Pingback: A clever memory script in perl « Motho ke motho ka botho

  15. Pingback: A comparison of text-based browsers « Motho ke motho ka botho

  16. Pingback: aphex: The tiny hex editor | Inconsolation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s