If swap fills to 100%, cache is dropped to make room for more app use of RAM. Once that last non-active ram is used up, the system will begin delivering oom errors. If the oom occurs on an application, the application will either halt or crash (depends on code - halt is recommended). If the oom occurs on a kernel process, the system will crash (usually).<br>
A process halted by an oom error is still in memory and will ned to be closed out to free ram. <br><br>It's pretty easy to add more swap space. Anthing over 2G is pretty useless though. The kernel is good abouttracking swap use so it won't try and write 1.1G to a 1G swap.<br>
<br><div class="gmail_quote">On Fri, Jun 27, 2008 at 6:01 PM, Jerry Yu <<a href="mailto:jjj863@gmail.com">jjj863@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On a db server with 16G ram and 1G swap, swap is nearly full. (It<br>
swang between 88 and 96% last week). What's the worst-case scenarios<br>
in terms of performance and/or availabilitu, when kernel decides to<br>
page out a few extra idle pages (more than the free space in swap)<br>
from physical ram?<br>
<br>
Assume the following,<br>
* Free physical ram is at 5G, or 9G including buffer/cache.<br>
* no new program will be launched, except stock RHEL 5.1 cron jobs and<br>
a few ssh sessions<br>
* OLTP transaction load against the db may spike 5 times over the<br>
weekly average, with more client connections to db server<br>
* swappiness is at default<br>
* db is the only non-os process running. Mem for db is preallocated.<br>
No tweaks is done to prevent db pages from being paged out<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>-- <br>James P. Kinney III <br>