Of cource you’re right. And I reported the bug several month ago:
http://bugs.mysql.com/bug.php?id=47991

Since it’s not an high traffic issue I’m not sure it will be fixed, though.

Yes… Depending on Kernel version you can get rather “fun” swapping behavior, even with swappiness=0 kernel may decide it is better to start swapping rather than shrink cache. The silly but practical “solution” is to ensure kernel can have some space for cache as it wants. Happily we’re probably speaking about 10% of physical memory here.

MySQL may have memory leaks like any software. Its best to report it and get them fixed.

There is “memlock” option which locks MySQL process in memory. The danger with it is increased change of MySQL Server being killed if no memory is available. It also not very commonly used and people reported problems with some Linux kernel versions.

# echo vm.swappiness = 0 >> /etc/sysctl.conf
# sysctl -p

will make sure the kernel decreases the fs buffer cache to a minimum before initiating swap. The system can still swap, but it is the last thing the kernel tries in a low memory situation. You want that in all your mysqld-machines and in all your httpd-machines.

@Peter: I would be interested to hear your comments about solving this via large pages (which I don’t believe are swapped out). It’s a common recommendation for other databases, but I’ve not seen many comment on it for MySQL:

http://dev.mysql.com/doc/refman/5.0/en/large-page-support.html
http://harrison-fisk.blogspot.com/2009/01/enabling-innodb-large-pages-on-linux.html

I think that what you want is to tweak /proc/sys/vm/swapiness (more info on http://lwn.net/Articles/83588/). Set it to 0.

But Peter is sure to have a better answer.

Bye,

Would be good to give some input why having 1.5GB is OS cached Linux may prefer to swap instead of freeing OS cache. And also how to fix it. This issues happens every so often.

It’s not only a matter of configuration, as I discovered myself