Skip to main content

Linux: Minimizing Memory Usage

It's still fashionable in certain Linux circles these days to pick a leaner distro in order to minimize resource utilization. Advocates of Arch Linux and Gentoo like to point out that Ubuntu is a bit heavy on RAM usage. As a Linux old timer, I'm sympathetic to the yearnings for a leaner, meaner past. Even Linus Torvalds admits that Linux is getting a bit bloated these days.

However, does switching to something like Arch Linux or Xubuntu really help? Consider the fact that I have a dual core MacBook with two gigs of RAM. It'd be one thing if I had an ancient machine, but I actually have relatively beefy hardware. Also, consider what top says when I sort by RAM usage:
top - 03:32:53 up 10 days,  4:03,  3 users,  load average: 0.37, 0.37, 0.41
Tasks: 154 total, 2 running, 149 sleeping, 0 stopped, 3 zombie
Cpu(s): 12.9%us, 5.4%sy, 0.0%ni, 81.5%id, 0.0%wa, 0.2%hi, 0.0%si, 0.0%st
Mem: 2026720k total, 1834468k used, 192252k free, 189524k buffers
Swap: 3559984k total, 36252k used, 3523732k free, 710924k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29545 jj 20 0 591m 310m 31m S 21 15.7 55:11.01 firefox
31458 root 20 0 972m 216m 58m S 8 10.9 86:57.34 Xorg
9677 jj 20 0 762m 118m 19m S 0 6.0 0:17.02 java
32600 jj 20 0 248m 55m 18m S 4 2.8 10:54.55 skype
32602 jj 20 0 109m 44m 20m S 0 2.3 7:03.57 pidgin
31311 jj 20 0 49784 36m 3468 S 1 1.8 1:48.45 ruby
1129 jj 20 0 54408 27m 13m S 1 1.4 4:27.88 gvim
31600 jj 20 0 34152 22m 8100 S 0 1.2 0:47.06 notify-osd
31563 jj 20 0 37368 20m 13m S 0 1.0 0:30.85 gnome-panel
1119 jj 20 0 55848 19m 10m R 2 1.0 1:13.64 gnome-terminal
31644 jj 20 0 73664 16m 10m S 0 0.8 0:08.64 gnome-power-man
31627 jj 20 0 46588 16m 11m S 0 0.8 0:00.74 mixer_applet2
31632 jj 20 0 29372 16m 8472 S 0 0.8 2:03.24 indicator-apple
31588 jj 20 0 26880 15m 9.8m S 0 0.8 0:09.21 nm-applet
31602 jj 20 0 28128 14m 10m S 0 0.7 0:03.17 update-notifier
31624 jj 20 0 27528 14m 10m S 0 0.7 0:07.55 fast-user-switcher
...
Firefox is eating up 310MB of resident memory. Oops! Time to restart it! NetBeans is eating up a whopping 762MB of virtual memory, although only 118MB of it are resident. Even GVim is using 27MB of resident memory. I have no clue why X is taking up so much memory. Despite all that, I still have massive amounts of memory free for the OS to dedicate to buffers and cache.

The fact of the matter is I need Firefox with Firebug, etc. in order to do my job, and using NetBeans (with the jVi plugin) makes me more productive than using GVim or Emacs alone. Remember the days when people joked that Emacs stood for "Eight Megs And Constantly Swapping"? It's hard to imagine an integrated development environment taking up only 8MB. Even my terminal eats more than that these days!

Hence, my point is that I could switch to Arch Linux, but that's optimizing the wrong thing. NetBeans and Firefox are the ones that eat the most RAM.

Comments

Shannon, you are forgetting about the shared memory - i.e. code which is being shared by multiple applications. Gvim doesn't consume 27MB but only 14MB, the rest is shared libraries like GTK. That's the reason why you have so much RAM left :-)

That is also why you must use the same technology as your underlying operating system when developing a desktop software, otherwise every single little Gnome applet would end up eating 20MB (if you did them in Java) and your entire system would swap itself to death.

Can't comment on Gentoo, but Arch is indeed sweet, check it out sometimes: it does feel snappier and the packages in standard repos are much newer than Debian/Ubuntu's
Anonymous said…
The classical reason why X is seemingly taking up so much memory is that it includes graphics cards drivers. These drivers need to map the memory on the graphics card, and thus it looks to the kernel as if the process is using hundreds of megs of RAM, while it's really not.
Unknown said…
This is exactly right. However, even with Firefox and Netbeans eating all the RAM who cares? It's only an issue if you run out. As long as you have RAM free, who cares how much any individual apps are using?
Paul Brannan said…
Apreche, the less memory applications use, the more memory is available for disk buffers, and the snappier your system will feel.
jjinux said…
Eugene, thanks for the insightful comment.

> Shannon, you are forgetting about the shared memory - i.e. code which is being shared by multiple applications. Gvim doesn't consume 27MB but only 14MB, the rest is shared libraries like GTK. That's the reason why you have so much RAM left :-)

Thank you for explaining that! I've been using Linux for a decade, and I still didn't know that!

> That is also why you must use the same technology as your underlying operating system when developing a desktop software, otherwise every single little Gnome applet would end up eating 20MB (if you did them in Java) and your entire system would swap itself to death.

Agreed. I love native GUIs.

> Can't comment on Gentoo, but Arch is indeed sweet, check it out sometimes: it does feel snappier and the packages in standard repos are much newer than Debian/Ubuntu's

Ugh, okay, I'm convinced. I have to give it a shot. I used to switch distros every month, but I've been pretty content with Ubuntu for a few years. I guess its time to give Arch a month ;)
jjinux said…
> The classical reason why X is seemingly taking up so much memory is that it includes graphics cards drivers. These drivers need to map the memory on the graphics card, and thus it looks to the kernel as if the process is using hundreds of megs of RAM, while it's really not.

Ah, thanks.

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within Tunes.org , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and jabber.org. Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p