Slashdot Mirror
How can you Reduce Disk Swapping in Linux?
A member of the voiceferous Clan Anonymous Coward asks: "I am finding that on my 64meg box that Linux is using the swap file even though it looks like there is plenty of RAM, but it is used by the disk(?) cache. For example, 4.8M of swap is used when the disk cache is 20M. What can be tuned to reduce the disk cache size? Sample /proc/meminfo info follows:
total:64569344 used:57200640 free:7368704 shared:32337920 buffers:3235840 cached:20496384 used-swap:4837376"
The work-around is to use RAM disks. Simply create a RAM disk, with memory that would otherwise be free, format it as swap-space, and activate it with swapon.
It doesn't stop the swapping, but at least it's all in RAM, rather than RAMDisk.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
It's dynamically allocated. Nothing used by programs is used for the disk cache, and you may see some swapping of programs that are probably started, but never used (innd anyone, or httpd on a home system that isn't on the net?).
-- Ever notice that fast-burning fuse looks exactly the same as slow-burning fuse? I didn't... (Edgar Montrose)
As far as I am aware, this isn't really an issue.
The amount of physical RAM free is rarely more than a few megs, as you've probably noticed (this is the "free" value in your example). Incidentally, my preferred way to determine free memory is with the free command.
What probably caused you to go into the swap there was you ran a big program or two at some point (Netscape, and X in general can be real killers). Linux will automatically scale down the buffers and cache to practically zero if necessary. Try running some programs that eat memory and watch the memory stats some time. It will only swap if necessary. When it does swap, it only swaps dormant processes, which you'll find plenty of in most standard distributions. Typically, you'll find you've got junk like nfsd and httpd and other more bizarre daemons running that you don't really need, and these unused processes will be what has swapped.
Because what is swapped was sleeping, it is likely to stay that way, so you only get a one-off performance hit from the swapping. When you close down your large apps, you'll find the memory which gets freed goes back to being used for cache/buffers, instead of swapping stuff back into memory. Why? Because that would be just as slow as swapping it out in the first place, and it's handy to keep that RAM free (bigger cache == better performance). If any of those processes wake up, they'll get automatically swapped back in.
So, to answer your question, no tuning is needed. The disk cache only takes memory not needed by processes. If RAM is low, the disk cache will shrink to virtually nothing, and if still more memory is needed, sleeping processes will get swapped. If RAM then gets freed up, the cache will expand again to fill the void. If a swapped process becomes active again, it gets swapped back into memory.
If you are really concerned, try disabling unused services on your system free memory. This is relatively distribution specific; refer to your documentation. But the only time when you should be worried is when RAM is so low that even mostly active processes get swapped - because then you'll get lots of disk thrashing. My guess is if your system is running with 20-odd megs of buffers and cache (plus 7Mb free), you're probably quite comfortable.
You might like to spend a little bit of time playing with top (table of processes). It lists your processes, and can be set to sort by CPU usage, Memory size, etc.
Hope this helps.
Linux has a very interesting memory management system that isn't intuitive at first. It enlists swap space even when you have plenty of physical RAM available. The degree to which you enlist swap space depends highly on how much disk activity you're performing and less on whether your program fits in memory. So every time you access the disk the kernel makes a decision: swap out physical RAM to speed up the disk or overwrite existing cache data to speed up the program. That decision has little to do with how far your resident set has exceeded physical RAM but mainly depends on how recently you accessed your resident set.
In fact as you approach 3/4 of your physical RAM the kernel becomes very reluctant to keep programs in memory. It's virtually impossible to use 100% of physical RAM because by that time the kernel is swapping out your resident sets with every disk access. Just try recording some uncompressed video. You'll see the video recording software fits perfectly well in RAM but after writing a few gigabytes of data the kernel has swapped out everything it can to increase disk caching. In fact your first fwrite will be very slow, as the kernel is writing physical RAM to disk to free up cache and only then writing your actual data.
Now this scheme can get very problematic if you really need the programs that the kernel swaps out. There are parameters in the kernel source which determine the swapping threshold but the problem is more what to set those parameters to than where they are.
See, every now and then, xmms loses its mind and grows to hundreds of megabytes. I'd like to set things up so that as soon as it hits 20M or so, it just dumps core instead.
But I find that neither limit datasize 1000 nor limit memoryuse 1000 cause subsequently-launched processes to be unable to malloc enormous amounts of memory (I tried it with a simple malloc-bomb program; its mallocs never fail.)
Is there some kernel flag I have to set to make heap limits be obeyed or something?