I have 4 GB of RAM but so far never needed more than half of them, so one day I told me: «why don’t I move /tmp into the RAM so that it’s faster?» (it also has some other benefits, like that when you power off the data there gets removed in a more safely manner than if it had been written to the hard disk, but I won’t get into this now; I don’t want to convince anyone to do the same, but just explain it for those who might have the same idea).
To achieve this the only thing I had to do is open /etc/fstab and add the following line to it (this works on both Ubuntu Jaunty and Debian Lenny):
none /tmp tmpfs nr_inodes=200k,mode=01777,nosuid,nodev 0 0
(By default, up to half of the RAM is allocated for /tmp; you can override this value adding the «size» option; eg., «size=2G» to give it 2 GB or «size=1G» to give it only one).
Some people advice to do this change in a recovery console, but I did it live from my normal session and it works as well; just don’t forget to apply the change with the following commands if you do it like me:
sudo mv /tmp /tmp-orig; sudo mkdir /tmp; sudo mount /tmp; sudo mv /tmp-orig/* /tmp; sudo mv /tmp-orig/.* /tmp; sudo rmdir /tmp-orig
you can make it > your physical RAM: if you actually use more than a few meg, e.g. big unzip, it will swing into swap space anyway.
How measurable are the speed effects? Only thing I can think of this helping in is when downloading; and even that is more constrained more by network speed than anything…
wj:
2 GB is a bit more than a “a few meg”, and I usually don’t uncompress stuff bigger than, say, 50 MB. And yes, I know it will go into SWAP if there isn’t enough space in RAM, but even then performance won’t be worse than before (actually, I’ve read somewhere that having /tmp in SWAP is faster than having it in the root partition, but I don’t know how trustful that source was).
Vadim P.:
I can’t say, I haven’t run any benchmarks or anything (although that may be something interesting to do some day I’m bored). I didn’t notice any visible difference but it’s difficult to tell with measuring it; in any case, it doesn’t do any harm.
Thanks for commenting!
Wow, I can’t believe nobody has thought of this before. I would also be interested in hearing what kind of performance increases you get from this.
IMO for most modern Linux kernels you should not do that.
1. /tmp will generally be cleaned, you don’t need to worry about it.
2. if you have enough RAM, most disk reads and writes are already using the RAM, it is unecessary to create a specific /tmp partition and reserve RAM for it.
3. using ram as /tmp reduces your effective RAM amount and reduces the cache size. hence the total system throughput will decreased.
For optimal system performance, it is better not to use your RAM as /tmp.
pansz: SunOS and then Solaris have had /tmp on tmpfs since 1990 and a lot of Linux admins will put /tmp on tmpfs. It’s a very good method for speeding up access to small transient files.
1. /tmp is not automatically cleaned, unless you write a script to do so. Named pipes and other similar objects do get removed automatically, but most other files do not. My Linux workstation has files in /tmp that are months old. tmpfs is a clean slate on each reboot. /var/tmp is used to maintain temp files that need to persist across reboots.
2. You are correct in that disk caching does help keep recently used files in RAM, but to ensure that you get consistently fast /tmp files, keeping them in RAM is a good idea. Once you start running out of memory the tmpfs starts to swap back out to disk, (and you fall back to a normal /tmp speed), but /tmp on tmpfs is usually a good bet. Best case: tmpfs is much faster, worst case: not any slower that before. win-win
3. tmpfs does *not* reduce your effective RAM amount, since it uses swap as a backing store and does not “hard-set” a specific amount of RAM that is unavailable to your apps, so if your apps need more memory, the system falls back to using disk for /tmp anyway. It may appear that you are using more RAM in “top”, but that memory is not inaccessible to other applications.
On older versions of ubuntu doing this broke the upgrade onto a new release! You have to remove the tmpfs disk before upgrading!
@poldi: I’ve had no problems with it upgrading from Jaunty to Karmic. Thanks for the warning though :).
@McKing
“Once you start running out of memory the tmpfs starts to swap back out to disk, (and you fall back to a normal /tmp speed)”
How can you be sure that the /tmp ramdisk is what will get swapped out to disk? If it does, then yes, worst case scenario is no different than before. But if things stored in RAM other than the /tmp ramdisk start swapping (instead of the /tmp ramdisk) you could (theoretically) be a lot slower, no?
Is there something special about the tmpfs implementation that ensure that ramdisks swap out before anything else?