[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: very large ram disk problems -- swapping, caching, and why tmpfs and not ext2 or reiserfs



Matthew Kirk wrote:
...
2.  I understand, through the "grape vine" that a ram disk built with tmpfs
can have its contents swapped.  I also understand this is not true of ext2
or reiserfs.

Is that correct?
My primary concern with using tmpfs has to do with swapping -- I'm using a
ram disk for a variety of reasons, but one of them is to avoid having any
writes to the file system for staging files and to ensure that certain files
are present for processing and don't need to be re-loaded.  Swapping defeats
that purpose. I can't use /tmp because I also need to pre-reserve space.
In another thread earlier, I wrote a small piece on virtual memory. I don't want to repeat all of that here, just a quick summary so you know what your options are.

Simply put, RAM+swap = virtual memory.

The kernel keeps track of where the physical line is between RAM and swap, but for some applications its all one space. tmpfs is one of those applications.

The kernel will favor RAM for all applications in virtual memory, and will use the swap space only when RAM is exhausted according to some complex rules. Basically everything in virtual memory can grow and shrink at will. The kernel at one end, and disk cache and other non priority applications (like tmpfs) at the other end. Each of the applications and methods used in virtual memory have minimum space requirements associated with them. Swapping does not occur until ALL of those minimums are reached.

So if you have lots of RAM, tmpfs is very much a RAM disk. If you run short on RAM alot then a tmpfs file system will perform about like any other, except it will be doing physical read a writes to the swap area. Filling up a tmpfs file system is a good way to cause lots of trouble. :)

It is my belief that tmpfs first appeared on Solaris. At least that is where I saw it first. We used it by default to mount /tmp on all desktop systems, especially developer systems where lots of small files are constantly affected, and the compilers write lots of temporary files. tmpfs in those types of systems basically fights disk cache for RAM space and it works very well. However, copying large files to /tmp can be problematic. By default, we ran scripts to clean out anything a week old in /tmp on all of those systems.

Here is a link to a munin example page:
http://munin.ping.uio.no/ping.uio.no/beate.ping.uio.no-memory.html

Note that the bright green at the bottom is the apps layer. The kernel layer is actually underneath that, if you can imagine it. The kernel layer is static, so munin does not show it. The dark blue near the top is 'free' or unused memory. Notice that the disk cache (orange) pushes up into 'unused' until it is gone. That is completely normal and desirable. Notice also that this system has some swapping activity. This system is NOT a candidate for tmpfs unless that swap activity is from a memory leak that has been corrected but the system has not been rebooted since it was fixed. But notice the size of cache (orange) comparative to the other elements. On other systems that don't show swapping, I would guess that they would be prime candidates for tmpfs.

Good Luck!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]