Rudd-O.com

Lately, I’ve been wondering if it’s at all convenient to disable swap on Linux, when memory is so cheap nowadays. Of course, having tons of RAM is a great thing: the more code and data the operating system can maintain into RAM, the faster the system will go. Ideally, you’d want to have as much physical RAM as needed to keep all your frequently-used programs and their data in memory.

I ended up keeping swap active. And here’s why.

But… I do have enough RAM for my programs… so I disabled swap. What’s the dillio?

But, if you had enough RAM to keep the entire working set in memory (in other words, to keep both data and code for all your running programs in main memory, at all times), why would you want swap? More concretely, if you had 512 MB of RAM, and your open programs occupied 490 MB of RAM, why would you need swap?

We all know using the disk as swap is slow. So, many people eliminate swap from their systems as soon as they install lots of RAM. And one of the biggest benefits of having lots of RAM is caching. Linux will attempt to cache disk files as aggressively as possible. Taking a page from the example I just concocted, if all I had left is (512-490) = 22 MB of free RAM, Linux would only be able to cache 22 MB of data.

Caching and program startup speed

Why is that figure important? Because, by now, you’ve probably noticed that the slowest operation on Linux is loading an application (especially big ones, like OpenOffice.org). But what you probably don’t know is that most of the time used to load an application is spent on disk accesses: firing up OpenOffice.org causes at least 130 MB of mostly small files to be read from the disk, and those disk accesses add up dramatically, mainly because of disk seek time.

You’ve also probably noticed that loading the same application a little while later takes a much shorter time. Why is that? It’s the cache who’s responsible of this big speedup: if Linux avoids reading files from disk, it runs much, much faster.

It’s also clear that having 22 MB available for a disk cache is just not enough to have OpenOffice.org start in less than 10 seconds, whether it’s the first time you’re starting it, or you just ran it a few moments ago and you’re running it again.

Most other everyday operations are affected. Opening folders in Nautilus or Konqueror are good examples.

So, how does swap actually enter the RAM equation here? What’s Linux not telling me?

It’s unbelievably simple, although not apparent at first.

Most running programs have code paths and data in memory that they rarely, if ever, touch. I would be bold and say most program-allocated memory is very rarely touched, but I might be wrong. So, the RAM taken up by unused code and data would actually be better utilized as cache for frequently-used files (or, even more beneficial, inode and dentry cache).

Having a swap partition gives Linux a space to put those rarely-used code paths and data segments on disk, freeing memory for the disk cache and new tasks. (Actually, shared libraries, unlike program data, can be evicted from RAM and re-read again from the shared library files when needed, but this incurs more disk seeks and computation effort than reading them back from swap, so if Linux has swap available for use, it’ll always prefer to put the shared libraries’ memory into swap).

The more memory available for the cache, the faster the response for frequently-performed tasks (like opening your huge MP3 folder… or my own huge MP3 folder, with Nautilus).

And that’s exactly why having swap is beneficial: unused code and data can be evicted from RAM, and that RAM can be put to better use. Even if you had over a gigabyte of physical RAM, that RAM would be better utilized as disk cache instead of being taken up by unused code. I’m not kidding: swap can make the difference between zero disk reads and three hundred disk reads.

This becomes more critical when low on RAM: imagine if the system were able to cache those 22 MB plus a 150-something MB of RAM, gotten by evicting unused stuff? Seen under that light, starting OpenOffice.org up is beginning to sound even doable, right?

There’s another reason, but it’s not performance-related. Some applications do allocate and consume a lot of memory. If you were to load several of those applications, the possibility of hitting zero free memory without swap is greater. And hitting zero memory is not good, because the system will kill processes it deems “memory hogs”. Best-case scenario: the application you just started dies. Worst-case scenario: a system daemon providing vital services (in my computer, it would be MythTV recording an episode of Nip/Tuck) dies. No one wants that!

In short: don’t skimp on swap. I do not believe in the 2.5X formula for swap (RAM times two point five). But I do keep twp half-a-gigabyte swap partitions (on different disks, in separate controllers, with equal priorities for added performance, and not the disk I use for MythTV) mounted at all times.

And how much RAM should you buy? As a general rule, if having all your commonly-used applications open causes the system to become slow (especially when opening the GNOME or KDE panel menu, or switching between applications), with applications appearing to “hang” for a couple of moments, that’s your cue to get more RAM: double it.

A faster processor won’t help at all, seeing as most of the time is spent on reading and writing to the disk swap partition. More swap won’t save you from this occurrence (indeed, it’s the accesses into swap which is making your applications “hang”), but not having it would be even worse for system performance (seeing as your system would still be short on memory, and it wouldn’t have a space to put unused data away).

What might help, if you’re short on money and long on free disk space, is setting up two swap partitions, each on a different disk connected to a different controller, and mounted with the same priority.

But remember that deciding to not be a cheap bastard and getting more RAM is the best course of action.

This entry was posted on Wednesday, January 11th, 2006 at 17:24 and is filed under Linux, Server management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.