A A
RSS

SWAP Devices Explained: Do I Need One?

Mon, Jan 6, 2014

Tweet this!

The swap device – you probably have one, and you may have used it, but you may not know precisely what it is or whether you actually need it. Once upon a time, when a typical computer had only a few hundred megabytes of RAM, swap devices were critical to a machine’s performance and stability.  But are swap devices still necessary?  What exactly do they do?

This article will explain the purpose of the swap device, clear up a few common misconceptions, and help you understand whether or not you truly need one.

 

Swap isn’t RAM

The most common misconception regarding swap devices is that it acts as RAM for your system, in addition to the physical DRAM that you actually have installed.  While that is somewhat true, it’s not entirely accurate.  Put simply, swap is a file or partition on your hard disk that is a place for your operating system to store memory contents that are not being actively used.  By moving memory contents from RAM to swap, the operating system frees up real, physical RAM capacity, enabling it to store other, more active data in that RAM.  The act of moving data from RAM to swap is known as “swapping out” in Linux (“paging out” in Windows).  If the data in swap is later requested, it will be read from swap into RAM, which is referred to as “swapping in.”  While swapping isn’t an inherently bad thing, it will cause poor performance in many cases.

To understand why “swapping” can lead to performance problems, it’s necessary to consider the relative performance of RAM and hard disk.  For random operations

In fact, the difference between disk and RAM is so significant thay machines that are in the state where swap is being heavily and actively used as will often appear to be crashed or hung. So if swap is so slow, why do we have it?  What’s it good for?

 

Swap frees up RAM

The true purpose of swap space isn’t to act as additional RAM; it’s to act as a storage location for things that are in RAM but aren’t actually being used.  When you open a program, that program’s data (the executable, libraries, and all the files it needs to operate) must be stored in RAM.  All open programs must be stored in RAM, regardless of whether or not they are actually being used; if you open Firefox and keep it minimized for weeks, it must still keep itself in RAM, even though it is idle.  On systems with an abundance of RAM, this isn’t a problem, but when memory is a scarce resource (as it was several years ago), that RAM is essentially being wasted.  This is where the idea of swap space comes in; the operating system can detect that a program is not being used, and move its memory contents to swap, freeing up RAM for other programs.

In the event that the swapped-out program is used, the operating system will read the data from swap and put it back in RAM. This is why you may notice that a program that’s been idle for a long time takes a while to become responsive.

 

There’s another beneficial aspect to swapping out programs that aren’t in use.  In addition to storing program data, the operating system will generally use any available RAM as a cache for the hard disk, which greatly speeds up file access (remember that RAM is much faster than disk).  By freeing up memory via swap operations, the amount of memory which can be used for disk caching is increased, and overall performance improves.

Should I still have a swap partition?

Modern computers can have a huge amount of RAM, so is swap still necessary?  The answer is, as usual, “it depends.”  Swap still plays the same role that it did previously (as described above), and in some cases it can be useful.  Generally, these are desktop use cases, where applications may be left open for a long period of time without being used.  My general recommendation for desktops is to have a swap partition, but ignore the old rule of thumb which said “your swap size should be twice your RAM size.”  That simply doesn’t make sense anymore, when you might have sixteen gigabytes of DRAM in your system.  For most users, even ten gigabytes of swap space is more than sufficient.  You will most likely never use it all, but hard disk space is generally inexpensive, so it’s not worth the headache of trying to identify the optimal swap capacity.

 

For server environments, especially where there are large amounts of RAM installed, swap can be detrimental for performance.  Servers generally don’t launch applications and let them sit around idle; a web server will always be serving web data, a mail server will always be running a mail program, and servers should never have user applications open and idle in the background.  A word of warning, however; in the event that some runaway application on your server starts consuming more RAM than you expect, the Out Of Memory (OOM) killer will be invoked and start killing off processes, in a desperate attempt to save the machine from dying.  The same is true if you do have a swap partition; the difference is that the system will become slower and slower (as it swaps data around) before the OOM killer begins to take action.

 

My general recommendation for server environments is to intelligently plan your memory usage – a server administrator should know how much RAM is needed by his services – such that your system memory is sized appropriately, and to use a minimally-sized swap partition. One additional improvement you can make is to tell the system not to use swap unless it is truly necessary; this is done by configuring the “swappiness” setting.  Dedicated servers should run with low swappiness values; a value of ten is a good starting point, and in some cases a value of zero is optimal.

 

SSD as Swap

Finally, there’s a lot of talk about using Solid State Drives (SSD), or flash memory, as swap.  Generally, this is inadvisable.  The entire purpose of a swap device is that the system writes data to it that it doesn’t think it will need to access (read), making swap a write-intensive workload.  SSDs are not ideal in cases where the primary operation is writing data, as write operations to SSD are far slower than read operations, and flash memory can only do a limited number of writes before it fails.  This “write wear” problem is quickly going away with more modern SSDs, but ultimately SSD is relatively expensive when compared to hard disk, and using SSD for swap is a waste of fast, expensive storage.

 

Conclusion

I’d love to know how your system is configured.  Do you have swap partitions on your desktops?  How about your servers?  Do you have so much RAM in your machines that you never use swap?  Leave a comment below with your thoughts!

Like this post?

11 Responses to “SWAP Devices Explained: Do I Need One?”

  1. Tony says:

    Nice article. Thank you.

    Question:
    I have a laptop with 8 Gb of RAM and 8 Gb swap
    When I want to try a distro, where/when ever possible, I load it into RAM. ( example : LiveCD/DVD of PCLinuxOS )

    How will SWAP benefit me , comparing:
    a-2Gb ram and 8 Gb swap
    b-8Gb ram and 2 Gb swap
    c- other combinations..please yourself

    I don’t <> to know, but it would certainly be interesting

  2. Duncan says:

    TL;DR summary: Good article, but missing any mention of the primary use of swap on many modern systems, as the place the hibernate image is stored.

    You do a very good job of explaining swap. Often times I read and article, then say to myself “OK, that was nice in a handwavy way, but where’s the actual explanation promised in the title?” I don’t feel that way about this article; you’re to be commended for actually explaining what the article title promised to explain, and I especially appreciated the desktop/server swap-usage contrast, as it nicely illustrated your point about the ideal swap usage case being that of still loaded but currently unused applications. =:^)

    Size-wise, I agree with your recommendation to ignore the old “twice the size of RAM” rule, but not necessarily with the 10-gig rule. For actual swap purposes (as opposed to hibernate, separately discussed below), I’ve found that 10 gigs may actually still be impractically large.

    Try this: Setup a swap-used monitor (watch free in a text terminal suffices), and (after saving your work in anything else running that you care about) load something memory intensive enough to push several gigs into swap. (Finding something that memory intensive is left as an exercise for the reader, but setting up a tmpfs at something above physical memory size and copying the content of a dvd to it multiple times as necessary can work for a reader technical enough to be comfortable with the necessary tmpfs configuration.) Don’t do anything else with the commputer while it’s doing this, so the speed at which your swap is being written is about the fastest you could expect in practice. Decide how long you’re practically willing to wait for something like this should swap actually needed to be used at that level, before you’d rather simply give up and reboot, and note how much swap is used at that point. In practice, a swap size much larger than that (but take into account hibernate, discussed below) is going to be wasted, because were you to actually ever get that far into swap, you’d probably just reboot and start over anyway.

    At least here, with swap on traditional “spinning rust” hard drives, I reached that “reboot time” pain point well before swap usage reaches 10 gigs. In practice, I found I could be several hundred gigs into swap before I’d notice it, but I started noticing it at something below a gig, and was definitely feeling the pain at 2 gig. My “OK, reboot time!” pain point was about 4 gig, tho I did keep a bigger swap for hibernate.

    Meanwhile, here on my desktop/workstation, I don’t actually have swap configured at all ATM, after upgrading the main system storage to SSD and not bothering to configure swap on it (yet? see hibernate, below) at all. I have 16 gigs of RAM and seldom use it all even as cache — 4 gigs of it are mostly entirely wasted, tho that’s partly because I normally do shut down apps when I’m not using them, and actually do the same with non-core partitions such as my media and distro packages partitions, mounting and unmounting them as I need access to them or not. My old system had 8 gigs RAM which was about right most of the time, but I’d occasionally cache-spill (have to dump cache when the memory was needed for something else, even with swap) when I was doing something particularly memory intensive, so when I upgraded I decided to get more. But due to the powers-of-two configuration that’s most efficient for RAM and it being reasonably cheap these days, I got 16 gigs even tho 10 or 12 would have actually fit my use-case better, and I very rarely use that last 4-6 gig even for cache.

    But then there’s hibernate, aka suspend-to disk, since Linux uses a swap partition to store its hibernate image, too. That you failed to even mention hibernate is this otherwise great article’s biggest omission, since that’s *THE* reason many people with sufficient memory on a modern system might still want a swap partition for their desktops/laptops.

    For a hibernate image the size/time factor is even bigger, since that’s real time you’re waiting for the system to write out the image before shutting the system off, and again real time you’re waiting for it to read back in the image before resuming. But fortunately, the hibernate image’s write/read is sequential, while in-operation swap usage tends to be more random, so hibernate read/write tends to be faster for its size than ordinary swap usage is. Also, particularly for people who only hibernate the machine once or twice a day as an alternative to shutting it down entirely, a wait of a bit longer in ordered to recover more of the cache they’d lose if they simply shut down instead, may be considered acceptable.

    In practical terms the kernel can often hibernate to even a relatively minimal half-gig or even smaller image (and swap partition size). That will be quite fast but will drop a lot of cache in ordered to properly save application memory, so cache is mostly cold after resume and reading frequently accessed and thus normally cached files last used before hibernate will be as slow as if you’d rebooted. So it’s much like a reboot, except you don’t have to actually login and start your apps again as they’re still running, so is likely faster and less hassle than a full reboot would be. This will likely be best for people who tend to hibernate a lot, say for people with laptops that don’t handle suspend-to-ram very well but who want to conserve battery between laptop tasks, and thus hibernate for a few minutes multiple times per day.

    A hibernate image middle ground for people with a reasonable but moderate amount of RAM (say 2-4 gig) is about half the size of RAM (thus 1-2 gig). Similarly for those with plenty of RAM (8 gig plus), but with a somewhat less than half RAM swap image in that case, say 2-4 gigs. This will normally allow saving some cache into the hibernate image, but probably not all of it, with a still not horribly slow hibernate/resume speed. Hibernate/resume will take somewhat longer, but system responsiveness after the resume is likely to be better as a result of keeping that extra cache. This is likely best for desktop usage and for laptops with reliable suspend-to-ram as well, where hibernate usage is likely to be 1-3 times a day, say overnight, or for overnight plus commutes (laptops used both at home and at work).

    One additional hint here is that a quick swapoff -a; swapon -a, after resume (you can script it), can help flush that last bit from the swap back into memory that would otherwise stay in the hibernate/swap image until demand-paged back in, making post-resume responsiveness the better for it.

    For users with plenty of RAM who really hate to see good cache dumped, and for users with a low RAM size (2 gig or under) in the first place, a hibernate image up to the size of RAM can be used. As hibernate image size exceeds 4 gig you’ll really feel the additional time to hibernate/resume, but it can be worth it for some users, and the additional hibernate image size for low-RAM users will let them make the most of what they have, at little cost in additional hibernate/resume time since the image size remains small for them anyway. The post-resume swapoff/swapon toggle trick mentioned above will be appreciated by the high memory folks, but it could actually make things worse for those with limited memory.

    The plenty-of-RAM full-RAM-size hibernate image scenario is a reasonable exception to your general don’t put-swap-on-SSDs recommendation as well, since with that much RAM and full-size hibernate images they’re probably not using swap for swap, and probably aren’t hibernating a dozen times a day either, so SSDs’ limited-write-cycle-factor won’t be such a big deal for them, while the increased speed of SSD over that of spinning rust will likely make a BIG difference in hibernate/resume time for that use case, hibernate images over 4 gig.

    I mentioned that with 16 gig RAM here, I didn’t bother configuring swap at all. That’s because last I tested it (several kernels ago and the chipset was still new at the time so it may work now, one of these days I need to test and see), hibernate didn’t work at all on my system (tho fortunately suspend-to-RAM worked well), so there was no reason to configure swap for hibernate, and with 16 gig RAM, I didn’t need swap as swap, either. But one of these days I’ll configure a swap partition and test it again, and if it hibernate now works, I’ll probably setup a full 16-gig-RAM sized swap for purposes of hibernate only, on the SSD.

    Larger-than-RAM hibernate images can be configured and do no harm, but the additional space is not used. Still, that can be useful for low-RAM folks actually primarily using swap as swap (not primarily as a hibernate image), and/or for those who want maximum flexibility as they’re anticipating a memory upgrade before their next repartitioning.

    Tying up loose ends…

    Quite conveniently, 4 gigs seems a reasonably practical general-use-case maximum size for both swap usage and hibernate image usage, tho individual use cases may find other sizes better for one or both.

    Older kernels couldn’t handle hibernate image sizes larger than half of RAM size due to the way they handled image restore, but that restriction should be gone now (since sometime before kernel 3.0 I guess).

    There’s a knob to adjust the hibernate image size: /sys/power/image_size. The default at one point was half a gig, but I /believe/ it’s larger (half the size of RAM or the size of the swap partition, I’m not sure which) now. That lets you tweak hibernate image size independent of the swap partition size (except of course that you can’t go larger than the size of the partition).

    There’s (slightly dated) suspend/hibernate documentation in the kernel’s Documentation/power/swsusp.txt file (and other files in that same location). Depending on the distro, the full path might be
    /usr/src/Documentation/power/swsusp.txt.

    Some distros use an alternate partial-userspace solution called suspend2, with a bit more flexibility, but the swapfile as hibernate image approach remains the default, AFAIK.

    Summary

    Other than the big omission of any mention of hibernate and the fact that it might be the major or only use of the swap partition on a modern system, the article was as I said, rather good. But that’s a pretty big omission, given that in practice hibernate often IS the primary use of swap partitions, these days.

    Duncan

    • Jonathan DePrizio says:

      Duncan,

      Thanks for that amazing comment! Yes, you are correct – I omitted the use of hibernate. That’s a great point, and one that I should not have overlooked. I’ll update the article to include it.

      Thanks again!

  3. Bob Robertson says:

    A year ago when I first configured encrypted disk, I accidentally did not configure any swap partition. My desktop system ran just fine. I have found that my 4G of RAM is more than enough for everything I do (which does not include things like heavy database).

    I’ve since rebuilt, this time with swap, and I deliberately put the “swappiness” at 0, and things are running great.

    Both “free” and “top” provide read-outs on what swap is being used. I’d say that running “free” a couple of times during what a user thinks of as “normal-heavy work load” would give a great sense of how much swap is ever used, and setting swappiness to 10, or even 0, on any system with more than 1GB of RAM certainly can’t hurt.

  4. Roland says:

    Swap is much more useful on multi-disk systems. Put a swapfile (same size) on every disk and they will be used in parallel. Much faster.

    • Duncan says:

      Agreed. I had parallel swap setup here for many years (as mentioned in my longer post I don’t actually have it configured ATM), and had thought about throwing that idea into my longer comment as well, but decided that post was was already too long and complex as it was.

      The how-much-swap-can-I-actually-use-before-the-pain-gets-too-high test I proposed there was actually done on a 4-way-parallel swap setup, tho that was with older and perhaps a bit slower 300-gig disks, which I figure somewhat balances it out. But I guess the “too long to wait, just reboot” pain point for many will be reached at or below about 4 gig anyway, well below the 10 gig suggested in the article, thus making my point, that 10 gig is probably still a waste, and people can do the test themselves and decide their own pain point, if they care.

      But due to swap’s dual use as a hibernate image partition as well, the restriction that said hibernate image /cannot/ be split up across multiple swap partitions, and the fact that I wanted a 4-gig hibernate image while still keeping partitioning identical across the four devices, I ended up with 16 gigs of swap (split 4 devices, 4 gig swap on each) after all, even if my actual swap usage pain point was ~4 gigs. But in practice 3/4 of that 16 gig was never actually used as swap as it would have been too painful (I did actually try it once when I happened to see something eating memory, just to see, before killing the offending application as swap usage approached 15.5 gig out of 16, usage increased at perhaps a gig a minute so I was waiting probably 15 minutes for it to happen, definitely NOT a time I’d be willing to wait under ordinary conditions, but it was fascinating to watch… ONCE!), and only one of the four partitions was (fully) used for hibernate.

      Meanwhile, parallel swap isn’t /quite/ as simple as just putting a same-sized swap partition on each of multiple devices. By default (if the priority option isn’t set), the kernel will prioritize successive swap partitions as -1, -2, -3, etc, and use them in that order, all of one before the next.

      But setting specific swap priority on a swap partition/file always makes it a higher priority than the default, and if in addition you set the same priority on multiple partitions, the kernel will effectively raid0-stripe across all at the same priority.

      See the documentation in the swapon (2) and (8) manpages.

      So in ordered to stripe swap across those four devices, I had the options field of fstab set to pri=100 for all of them.

      (The 100 value was picked out of the air as easy to remember, while allowing additional flexibility to set further swap partition priorities above or below it as desired. The available to be assigned range is 1-32767 (apparently a signed 16-bit integer with the negative range reserved for kernel-assigned defaults), tho the upper limit on actual swap areas the kernel can handle is apparently 29 or so on a modern kernel, based on the manpages.)

      Duncan

  5. Grant says:

    I do things differently. I configure swap, even on a server with plenty of RAM. There are tasks, even on a server, which are done only occasionally, or often only as part of the boot sequence. Allowing these to be moved out to swap increases the memory available for disk cache and improves performance. I have not run into an issue where the items being pulled from swap was a bigger performance hit than not having the memory free for disk cache for the data. Most memory intensive processes that are would cause a performance drag is swapped are used often enough to keep then out of the LRU trap, so they are not swapped.

  6. Jay says:

    I have 4 Linux boxes, with 4 to 16G or RAM.
    In each case I have a swap partition on an SSD slightly larger than the RAM size.

    The oldest is 3 years old now, and no signs of write endurance problems.

    I do have VM swapiness set to zero on some and 2 on others. With so much RAM, the swap is rarely used, but is there in case some rogue application starts filling the RAM.

Trackbacks/Pingbacks

  1. Links 7/1/2014: Instructionals | Techrights - 07. Jan, 2014

    [...] SWAP Devices Explained: Do I Need One? [...]

  2. Managing SWAP Devices in Linux | Techthrob.com - 13. Jan, 2014

    [...] recently wrote about the Linux swap device and what it’s used for.  This tutorial covers the basics of actually managing the swap devices and/or files on your [...]

  3. Understanding Linux Memory Usage | Techthrob.com - 21. Jan, 2014

    […] is incredibly fast, and whenever possible the system will almost always use RAM before it goes to swap, which is a part of your hard disk that is being utilized as memory. Hard disks (even solid state […]

Leave a Reply

Weekly Poll

What's the best Linux distribution for desktops?

View Results

Loading ... Loading ...

Search TechThrob

Advertisement