Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an SSD, so space is a scarce resource. I'd like to use up as little as possible for swap. In fact, I have spent the last year completely without a swap partition (the computer has 6 GB RAM).

I am planning a clean reinstall and want to try some new things. Among them, I want to reduce the write load on the SSD by placing the write-heavy system directories on tmpfs. Specifically, I want to place /tmp, /var/tamp and /var/tmp/cache in the RAM. Obviously, this will increase my RAM usage, and at some point, I might need swap after all.

I haven't logged temp directory sizes and RAM usage in the past, and don't want to install logging tools and wait with the reinstall until I have gathered sufficient data. What are my best options for making a guess for a suitable swap partition size? How sensible will such a guess be? Am I just left shooting in the dark or relying on overgenerous guidelines of the sort "1.5x your RAM size"?

I do a complete shutdown every night, so I hope the temp directories won't get too big in size.

share|improve this question
up vote 4 down vote accepted

You have three issues when it comes to swap space.

First, with insufficient swap space, some workloads are just not possible to perform. If a program needs more memory than available physical RAM, it just can't run without swap.

Second, with very low swap space, your computer may not be able to evict things that are never accessed from physical RAM. Often some chunk of memory will never be accessed, but the operating system cannot prove that. So it cannot just release the memory. Without enough swap, that information stays stuck in RAM forever, never being accessed. Many processes dirty a bunch of memory on startup that they never touch.

Last, with very low swap space, your decision to overcommit VM or not can have drastic consequences. If you don't permit the system to overcommit VM, you'll wind up refusing operations that actually don't use much memory. (Imagine if a large process calls fork. It may be about to call exec, but unless you permit overcommitting, the OS must refuse the fork if it doesn't have enough RAM+swap for the new process to dirty every writable mapped page.) If you do permit the system to overcommit, and you don't actually have enough RAM+swap for an atypical workload, you may find processes being unceremoniously terminated.

Personally, assuming typical usage, I'd allocate 2GB for swap and make sure reasonable overcommitting is allowed.

share|improve this answer

If you are not doing any memory intensive tasks, then a computer with 6G RAM can do without swap (warning: I am crazy).

Mounting /tmp (its /var siblings) as tmpfs is a very good practice. For my netbook with 1G RAM, no swap , kept 100M /tmp tmpfs and never gave problem (unless you want to yank things from there like caches things, which people normally don't want).

If anything screws up, all you have to edit is /etc/fstab .

Paranoia is good but your chances of losing data less as only tmp/cache directories are in memory, actual data is written to disk anyway.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .