Comments on Storing Files/Directories In Memory With tmpfs
Storing Files/Directories In Memory With tmpfs You probably know that reading from RAM is a lot of faster than reading files from the hard drive, and reduces your disk I/O. This article shows how you can store files and directories in memory instead of on the hard drive with the help of tmpfs (a file system for creating memory devices). This is ideal for file caches and other temporary data (such as PHP's session files if you are using session.save_handler = files) because the data is lost when you power down or reboot the system.
9 Comment(s)
Comments
I noticed some common confusion in the comments posted... TmpFS is not necessarily kept in RAM, it uses virtual memory and can thus be swapped out to disk as well...Which is good IMHO. (Not everything you cache may not be used that often.) So the maximum possible size is not limited by the amount of RAM you have, but by the virtual memory size.
Actually, I tent to use the size of my swap as the maximum size for tmpfs on /tmp, since I'm hardly using my swapfile for anything but suspend to disk.
(If you want to keep as much data in memory, you may want to lower the "swappiness" value in /proc/sys/vm/swappiness anyway)
This reminds me of a a hardware add-on for the IBM 360/370 computers in the 1970's. IBM was beginning to incorporate paging and swapping into it's operating systems. Hard drives at that time weren't very fast, but then, neither were the computers, so even though paging sped things up, it was still slow. So this add-on was a lot of RAM, connected to a hard drive interface. It looked like a hard drive from the OS side, but I/O performance was a lot closer to RAM than to a hard drive. The price was also closer to the price of RAM, too. This was back when a single RAM chip still had under 4K bits per chip (yeah, do the math on what 256 kilobytes would require).
If the temporary file is small enough to fit into a virtual RAM drive, perhaps it would be just as smart to simply ask the developer to keep the information in memory, and not write it out until either the program ends, or the program knows persistent storage is required.
Finally, if temporary space is really required, why not put it on a fast thumb drive? While not as fast as RAM, it's faster than a hard drive, and leaves more RAM available.
Nice and useful :-)
please do an equivalent article for FreeBSD. I want this, but in freebsd. : >
/sbin/mount -o rw,size=2048000000 -t tmpfs tmpfs /tmpfs
# Now you have a /tmpfs folder sized 2Gb located in RAM (blazing fast)
/bin/mkdir /tmpfs/phpsess
# If you have heavy loaded MySQL at your server, there is one more MAIN THING you can do:
# locate my.cnf (at FreeBSD you should look in /etc or /usr/local/etc)
tmpdir = /tmpfs
# Wish you the best! http://server-kiev.com
Thanks for the article. TMPFS is a really great tool, and deserves more attention. Something that your article could be a little clearer on are the advantages of TMPFS over the traditional RAM disks that many of your readers may already be familiar with:
1) A TMPFS system only uses RAM as needed. The 2GB figure for the /dev/shm example in the article is just the maximum, it usually uses no memory at all.
2) Infrequently used content in a TMPFS system can be swapped out if the system is under memory pressure.
The speed is almost the same as working with fylesystem on disk
I do not issue any guarantee that this will work for you!
It worked quite well. And thanks for the explanation of how to shrink the size of /dev/shm. It's always amazed me that no matter how much RAM I install, Linux finds a way to use all of it, and still requests additional swap space.
Great article! My only comment would be that in later Ubuntu (all Debian I would guess) releases, you might as well use /dev/shm, rather than mount a new tmpfs. That is what /dev/shm or, now, /dev/run/shm are for. Otherwise, it is smart to use this. Is it better than /tmp? A little. It's my new config in any event.