Why linux default (i have Redhat CenOS) swappiness (http://en.wikipedia.org/wiki/Swappiness) value is 60 (to rather use disc than RAM?) while HDD is slower than RAM?
Why it is not like lets say 30 ? or closest to zero as possible?

(i have linux webserver)

For desktop I usually set it to 1 to make the system more responsive. It can be set higher for servers that only care about throughput and not latency.

I typically build my systems with more RAM than I'll need and set swappiness to 0. I hate the swap, if it ever gets used on my systems it means I'm doing something wrong.

I have no idea why the default value is so high. My guess is it's a remnant of years ago when RAM was so much more expensive than it is today. Same reason why ext defaults to a massive 5% reserved sectors.

For a desktop with high amounts of RAM you don't even need swap. For a server, you probably want some, but do reduce swappiness, try 20.

I don,t know nowadays why the community left as default swappiness of 60. Maybe the reasons are for what suicidaleggroll said, or maybe it is because most of the daemons are always on sleep state and can be swap out to disk while the kernel provide more ram cache for running proccess, or maybe there are other reasons.

I always keep some swap partition on my system, even if it is only 20MB of disk space, the reasons are that databases like MySQL or Oracle demand swap to work on Linux, otherwise Oracle won,t install and MySQL start to have fishy behaviours. Also if you disable swap partition you will need to disable kswapd kernel daemon, and no, you cannot disable it with "kill signal" you need to recompile the kernel for this, since this little one is searching constantly for "swap partitions" and if it doesn,t find one it starts to eat plenty of your CPU and sometimes making your system unresponsive (since linux kernel use the entire ram as ram cache, once cache is reached and there,s no where to swap out stuff, system will crash).

Of course if you,re not going to use some apps that demands swap partitions , or if you,re 100% sure that you never going to install some apps with a memory leak inside, you can happily disable any swap partition and recompile your kernel with kswapd disable too. Otherwise, keep a little swap partition and tweak swappiness.

1 members found this post helpful.

Hi,

Swap allocations should not be an issue with modern systems having Gigs of RAM along with Gigs of available storage space. Whenever I setup using a 'SSD' then I set swappiness to; When I setup with '/etc/rc.d/rc.localI use a modern MLC 'SSD' with a Good SandForce controller and am not worried about wear. 'SSD' will likely outlast the Life of the Laptop.
Hope this helps.
Have fun & enjoy!

Almost everything said so far in this thread is based on a fundamental misunderstanding of the effect of the swappiness parameter on Linux behavior. You should not adjust settings unless you understand them.

The key to understanding swappiness is understanding anonymous vs. non anonymous memory. Usually only anonymous memory is swapped out to the swap file. Non anonymous memory may be discarded from ram and later reread from its original source in the file system. The most important (and on many systems largest) kind of non anonymous memory is program executable code.

The major effect of swappiness is to set the bias for discarding non anonymous memory vs. anonymous memory when there is memory pressure. Discarding and later reloading non anonymous memory takes one disk access while discarding and later reloading anonymous memory takes two. So you want an appropriate bias to tend to select non anonymous to discard (a swappiness of 100 means no bias). But you also want to keep the general principles of LRU memory management. If some anonymous memory is far more stale than some non anonymous memory, the reduced probability that the anonymous memory will be reused soon overwhelms the two to one difference in ultimate cost of discarding.

If you have your major file system on media such as flash, where the effective cost of one write operation is much greater than the effective cost of one read then the default swappiness is too high and should be set lower (but not down to near zero). Otherwise messing with it is just a way to slightly detune your system.

Most of us have so much ram that the value of swappiness makes only a trivial difference. Set it lower as described in the earlier posts in this thread and you just make your system slightly slower. But the more it might matter the more unwise it is to mess with it based on the common misunderstanding of what it means.

1 members found this post helpful.

johnsfine

SOme members prefer to not even have a swap partition on their system, in case no swap partition exists, swappiness is useless and kswapd daemon too. Not having swap partition is not good on production servers or desktop PC of gamers, or people who love to watch plenty of HD vids. Once ram cached reach their limits, linux kernel won,t find swap partition and will do 2 things, or start to shutdown services to free up ram or linux will crash totally, I always keep a little swap partition no matter if I have 60GB of ram.

Swappiness value at 60 is not so bad like people think, having swappiness at 60 doesn,t mean that once linux reach used ram of 60% your system will start to swap. It doesn,t work this way, having swappiness at 60 means, once reached real used ram of 60% linux will start to swap, but I mean real used mem, not used ram cached, in some case having swappiness at 5 or 1 or 0 means, that you,re letting your system to start to kill services once no more ram is available.

1 members found this post helpful.

I disagree.

swappiness basically controls the balance of disk cache vs program memory in RAM. If you are using 2 GB of RAM for programs on a 4 GB system, it controls whether or not the remaining 2 GB is enough for disk cache, or if it should flush some of those programs to swap to create more space for disk cache.

I don't want the kernel deciding that because I haven't interacted with Open Office in 30 minutes, it should dump OO to swap so some other process can use a little more disk cache in order to run 5% faster, at the expense of OO being completely unresponsive for a minute or more the next time I go to use it.

If I'm not interested in using an open program, I'll close it. If I have it open, it means I'm using it, and I don't want to sit there banging my head against the wall waiting for it to swap back into RAM the next time I try to interface with it. If having that program open means some other program takes two seconds longer to run because it couldn't grab that extra couple hundred MB of disk cache, so be it. And I CERTAINLY don't want to go to lunch and come back to find all of my programs have been moved to swap and I can't do anything for the next 5 minutes, all so that some background process that I don't even care about could run a few percent faster while I was away from the machine.

That's why I set swappiness to 0 (though I see now with newer kernels 0 means "off", while 1 now means "only use the swap in an OOM condition", so for future systems I'll be setting it to 1 instead).

Hi,

Swappiness setting are the relative weight for kernel swap management on runtime memory whenever the data must be moved or it will be dropped.

SSD do not have moving parts so the rotational latency are not a factor. The SSD controller will use the devices cache if that has been configured for use.

Hope this helps.
Have fun & enjoy!

Interestingly, if I understood what john's saying correctly, you'd be doing exact opposite to what you wanted to. Setting swappiness to near zero would mean that the program executables (non anonymous memory, like openoffice) are the first thing to get kicked out of RAM - because they don't need to be swapped per se. Memory management only needs to silently drop them out.. and next time you try to access the program, it gets reloaded from the executable file itself. Having higher swappiness would mean the anonymous memory is more likely to make room by going to swap file, leaving executables to linger in longer.

For smallish SSD drives low swappiness would make sense first to prevent unnecessary writes that wear out the drive, and second because the access time is generally fast enough that reloading the executables isn't a major issue.

There is some of that effect, but there can also be some reality to suicidaleggroll's point (though I doubt that is common).

So far as I understand, Linux lacks any practical prioritization for memory. You can prioritize CPU use, and on older (under resourced) systems, prioritizing CPU use indirectly but effectively prioritizes memory. But on most modern systems, that is not effective.

Imagine you have low priority processes (such as backup or indexing) that do a lot of file I/O, while you have high priority processes suspended waiting for user action or slow internet response. You would want the memory priority of the high priority processes to remain above that of the low priority processes. But there is no direct control for that.

Instead, you might recognize the situation (such as in backup or indexing) in which the low priority processes' memory use is almost entirely non-anonymous, while the high priority processes have a significant fraction anonymous. Then by increasing the relative memory priority of anonymous over non anonymous you are crudely and partially increasing the relative memory priority of the higher priority processes.

I've never seen the situation in which the above effects were enough to make lower swappiness yield better responsiveness. But I'm willing to believe the online descriptions that say others have.

The fact that such an effect sometimes exists (caused by background processes doing significant file I/O) should not be a reason for ordinary users to look at the stat on swap space used and imagine their system is less responsive because of it. We see many posts here in which it is clear the lack of system responsiveness is entirely a user delusion caused by the expectation that swap space usage results in poor responsiveness.

On the issue of SSD drives, I'm far from expert, but my understanding is that wearing out the drive is no longer a significant concern. The performance concern relates to having a significant fraction of the transfers be writes. The drive keeps a small pool of erased sectors. When you write, the contents go quickly into pre erased sectors. The drive dynamically shuffles the identity of sectors, so the same logical sector written is not the same physical sector as the last time it was written. Then the expensive operation of erasing the prior physical location of the relocated sector happens later. But if the drive accumulates too big a backlog of sectors needing to be erased and/or runs out of pre erased sectors, the performance becomes terrible. So the use of the SSD should be biased to have significantly more reads than writes, which is a reason swappiness should be set to treat the write/read swap operation as more than the usual twice as "expensive" as the discard/reread of non anonymous.

BTW, that is an extra reason to use a tmpfs rather than a directory on your SSD drive for /tmp. If the size of /tmp varies so widely that you cannot reasonably include it in the demands on your swap file, then you can't use a tmpfs. But typically you can make swap large enough to include /tmp. When files get created and deleted quickly in a normal /tmp directory (which should be a common event) the directory sector ends up getting written even if the file is gone before that write reaches the media. But in a tmpfs, the rapidly changing directory of /tmp is almost never written out to swap.

1 members found this post helpful.

I'm not sure what you mean. The memory usage of a running process (what would be swapped to RAM) is not the executable file itself. The data can't be silently dropped out of RAM because that would seg fault the program the next time it tried to access that memory. If the program is running, the data it is holding in memory has to be somewhere. If it's not in RAM, then it must be in the swap, it can't just disappear and re-load itself from the disk, because there's a good chance it never has and never will exist on the disk. This data will contain things like the formatting of an open web page, images on that web page, a buffered video, a half-composed email in Thundirbird, etc. Anything that you would lose if power was suddenly cut to your system. Swappiness controls the willingness of the OS to move a program's memory off to the swap in order to make more room in RAM for disk cache. More disk cache means whatever process is reading those cached files gets to run faster. Moving a program off to swap means its significantly less responsive the next time you go to use it. It's a tradeoff, and that tradeoff is controlled by swappiness.

I am surprised that johnsfine has never noticed the effect, I have found it to be quite obvious (less so with SSDs though). However, different people use their machines in different ways. Somebody who closes down programs when they are not immediately being used, or who shuts down their computer whenever they leave their desk, likely won't notice the effect of swappiness because their programs are never idle long enough to be swapped anyway. For somebody like me who never shuts down the computer, and is often pulled away from my disk while I'm in the middle of working on a project with 10 web pages, 4 emacs sessions, and 15 terminal windows running with codes open or running or being debugged, swappiness makes a big difference.

If you want to test the effect yourself, then before you leave your desk for the night, set the swappiness to 100, open a few memory-hungry processes (web browser with a few tabs open to different pages, thunderbird, etc.) and leave them running overnight. Make sure hibernate, sleep, etc. are all disabled on your machine, and make sure the typical background processes on your machine are all enabled (updatedb, security updates from your package manager, etc.). When you go to use your computer the next day, see how long it takes before it's done "waking up" and is ready to use. The next day, do the same thing but with swappiness set to 1. The difference is that with swappiness set to 1, there will be no "wake up" period, it will be ready to go the instant you sit down, just like you never left. The tradeoff, of course, is that while you were sleeping the system wasn't able to use as much disk cache and your high I/O background processes likely ran slower than they would have the night before.

The problem, in my mind, is that the kernel is very good at determining if a block of occupied RAM has been idle for a long time, and if another process could make better use of that memory in other ways. However, the kernel is very bad at predicting when that block of occupied RAM it just moved to swap will be needed again, so it can pre-fetch it off of the swap to get things ready. Instead, it moves it to swap, and then when it's needed again, it goes "Oh crap! Quick, drop the cache, we need to pull this memory back out of swap because he's trying to use it!", and in the mean time you're sitting there staring at the screen waiting for it to respond. I, on the other hand, am much better at predicting when I'm going to need a process again, so if I'm doing some I/O intensive work I can just shut down some memory hogs to free up space in RAM for disk cache, and before I need them again I'll open them back up. I don't need the kernel trying to do it for me, because in my experience it does a pretty poor job.

BTW - here's a discussion on tuning swappiness, explaining both sides of the argument. I am firmly on the low swappiness, low latency side of the fence, but the other side has a valid argument as well.

https://archive.today/FKlQ

Back when that was written (2004) it really was more of an either-or scenario, RAM was too expensive to have an overabundance of it, and you did need to carefully choose how you wanted things to work. Nowadays RAM is so cheap that there's really no reason IMO not to just stick 16+ GB into your system, set swappiness to a low value, and enjoy both low latency AND plenty of disk cache.

With 16 GB, unless it's a server running high memory tasks or virtual machines you can just remove swap.