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)
I have 192 megs of ram and my computer constantly swap in and out of the swap file. The buffer/cache sometime gets as big as 100+ megs, any ideas why? any idea how I can turn down the cache size?
_______________________________________________
There is no statute of limitation on stupidity.
Linux' memory management is looking out for your own best interests here. The most recently used page, be it a disk block or a vm block, is kept in memory. When more memory is needed, the least recently used page is discarded, and replaced with the data being read in.
Creating ramdisks etc... is likely only to slow your system down by increasing the amount of file IO being done from the disk.
If a process needs realtime response to interrupts, etc..., then consider writing it to use mlock().
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.
"try disabling unused services on your system free memory"
should be:
"try disabling unused services on your system to free memory"
A friend of mine was saying in Linux/Apache frequently used files would automagically go into RAM. For example, a web server serving static pages would automagically have those files in RAM for serving out. Thus, increasing the speed.
Is this a load of hooey? Could someone perhaps explain or give a link to an explanation to the memory management in Linux?
Thanks.
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?
Read. Play with /proc/sys/vm/* and see if it helps.
JWZ's question is a good one; I'd like to know why the RSS rlimit stuff doesn't seem to work, too. The other rlimits seem to work.
In my local experience, this is quite to be
expected with a 2.2.* series kernel (used in
a number of recent distributions, eg Redhat 6.0
onwards). 2.2.* seems to aggressively swap things
out to make room for various sorts of disk cache;
the same machines under 2.0.* didn't go into the
swap until they actually mostly ran out of memory
for real, non-cache/non-buffer pages.
This aggressiveness appears to be basically
harmless; I haven't noticed any particular
performance problems due to it..
Although it can be somewhat disconcerting to
see a
machine with lots of real memory and no programs
applying memory pressure be 10 or 20 megabytes
into swap.
I have the same problem. The way Linux manages virtual memory and disk cache _by default_ doesn't scale well with common desktop use. Not to put down linux developers who knows exactly what's going on, but having such management too dynamical, lacking some intelligence, can severely hurt performance in some cases. That's my experience after all.
Technically I'd say there are a few solutions to the problem:
Dumb:
1) Set the size of disk cache statical. This is the easiest solution, but requires manual tuning of the system.
Intelligent:
2) Persistantly register the usage of files, how much they are being used when they first are being used/run, % of CPU, etc. The disk cache and VM can then operate better by sorting processes, memory areas and files by certain priority criterias. This can then be used to set a more averagely needed disk cache size, and to completely skip files you usually access once in a blue moon.
The more choices we have, the better chance of a perfect fit.
- Steeltoe
http://www.debunkingskeptics.com/
: 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.)
Doing a buf = malloc(1000000000); doesn't exactly do what one would think. Allocating a gig of RAM actually works on a machine with only 32M or RAM and swap space. The reason is that the linux kernel is smart and it only virtually maps in memory that you have actually used. So to write a proper malloc bomb program you have to then go in and set every byte (or atleast one byte in every page). Otherwise the whole buffer never actually gets mapped to RAM. The same goes for huge arrays on the stack. Damn, dynamic paging is great.
xosview is really a fantastic little program, it'll tell you everything that is going on system-wise. I thought I'd miss my Sun perf meters, well xosview just blows those crusty perf meters away.
Why not try swapoff !
;-)
That will stop those anoying little critters...
You may of course have to buy a few more Mb RAM
Seriously though as has been said here a few times allready, Linux swaps out unused program code so you get more disk buffers & hopefully better performance. If it is thrashing you are either doing lots with big memory footprint apps, or you have some funny data/code usage patterns. The good old answer of more memory may be the right one or get into some real kernel tuning.
Cheers,
R.
Maybe you live in interesting times
In Windows tech circles, balooning disk cache is generally considered to be a real performance problem in the OS. Many tech web sites post ways around this annoying behavior, such as entering values to limit filesystem cache size. I'm sorry to see this spread to Linux.
you can get more ram: - order ram - install ram you can use less ram: - disable services you don't use - write your own, less bloated, software - kill netscape - boot/restrict users