> > When I first saw how much swap is beeing used I was a little > scared and my only thought was of how to reduce it. The > higher the amount of used swap, the worse it is for the > system I thought. I still believe that this is right, but I > also found a chapter about memory management in "Linux System > Administrators Guide". Now I see that you are right, it's > more important to monitor swapping over time periods. >
Exactly - some swapping is normal, and small amounts of occasional swapping is no problem. In fact, it helps out poorly written programs where the programmers don't bother to properly manage memory, in that it dumps out the pages from the working set that are not frequently used. > I ran sar, but I don't have enough other values to compare > them. Here are my daily average values for pswpin/s and pswpout/s. > > # for x in /var/log/sysstat/sa[0-9][0-9]; do sar -W -f $x | > grep ^Aver; done > Average: 0.78 0.00 > Average: 1.41 0.00 > Average: 3.23 0.11 > Average: 10.32 0.22 > Average: 17.49 0.02 > Average: 15.87 0.03 > Average: 27.74 0.06 > Average: 18.13 0.26 > Average: 6.88 0.12 > Average: 4.28 0.07 > > Is that good or bad? I have another system with sar activated > but I only get zeros. So no swapping seems to be done there. The average values here are not as useful as individual values, as they tend to hide the extremes (for example, lots of 0 page swaps and one or two 200 page swaps). They will tell you as a trend if your system is overloaded, but not anything about the occasional swap peaks and thrashing. You need to look at the individual values to see if you have extreme highs. Each unit is a page, which is 4k bytes, so I see on one day you had an average 112k of swap / second. This is higher than you'd want. My average for example is .024, and never gets above 4. And your heavy load is swapins, which means either you have processes that are periodically spiking to get their working sets, or you have very heavy swap in requirements during boot, and then little afterwards. Again, you need to examine the numbers. > > > Trying to reduce processes to the point of starvation, etc. > is not the > > best approach - rather, and I'm sure you know the drill, > adding more > > RAM is the way to go. > > Adding more RAM is my last resort. The system is in > production and it is not so easy to have down times. Of > cource, if anything else fails, I will go that way. But maybe > the values that I have written above aren't so bad and I can > live with that swap behaviour? Eventually I have learned that > swapping in general is not necessarily bad. > Understood - nobody ever wants downtime. Yet, a 30 minute scheduled downtime for a RAM upgrade is far more tolerable and safer than mucking with various daemon configurations on a production system that you don't understand well, right? And in the end, you have a stronger work horse. Best of luck, -mike ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
