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. 😈
P.S.: Thanks to LinuxPlanet for pointing it out. 😉
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
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
Hmm. It’s a python script, so it should work with
python ps_mem.py
.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.
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. 😉
What an epiphany; one of your heaviest apps is actually a clock. Go figure 😀 .
You probably already know this, but for those who don’t, the Arch Wiki has a very good page on lightweight apps.
The python script for ram usage is really awesome.
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?
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.
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?
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
.Pingback: Mingetty and dash « Motho ke motho ka botho
Pingback: A text editor in 2.5Kb « Motho ke motho ka botho
Why do you sum the *shared* memory ? (*)
(*) http://modperlbook.org/html/10-1-1-Calculating-Real-Memory-Usage.html
You’ll have to ask the author of the script that question. 😉
Pingback: Shaving megabytes: cplay and mcplay « Motho ke motho ka botho
Pingback: X and Openbox in 12Mb « Motho ke motho ka botho
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.
Pingback: A clever memory script in perl « Motho ke motho ka botho
Pingback: A clever memory script in perl « Motho ke motho ka botho
Pingback: A comparison of text-based browsers « Motho ke motho ka botho
Pingback: aphex: The tiny hex editor | Inconsolation
Pingback: aphex: The tiny hex editor | Linux Admins
Pingback: stftp: The simple terminal FTP client | Inconsolation
Pingback: stftp: The simple terminal FTP client | Linux Admins