>> >>> Swap usage on Linux always seems a little tricky to me. Should my >> >>> goal on a web server be zero swap usage, meaning the attached graph >> >>> should show no green lines at all if I'm doing it right? >> >> >> >> No. You want things that aren't in use to be swapped, like memory >> >> leaks and such. You don't want things that will be used to be >> >> swapped. >> > >> > Does this look OK? It looks to me like heavy swapping in and out with >> > plenty of free memory (minus buffers/cache). >> >> Or put another way, how do I know when swapping is a problem? I'm >> running munin so I can look over graphs of my system's characteristics >> but I'm not sure what to look for to determine if I'm swapping >> excessively. > > "Swapping excessively" is inherently a use-case-specific problem, but it comes > down to two questions: > > * Do you notice your system spending time in iowait swapping data in while > you're waiting on it? > * Do you notice your system spending time in iowait swapping data out while > you're waiting on it? (I.e. as it tries to make room for new memory > allocations)
I can't find a good graph for iowait in munin. Is watching wa in top my best bet? If I do find a correlation between iowait and web server response times, should I just decrease memory usage until the problem goes away? What I do notice is that my web server's response time increases along with the swapping peaks in the graph I posted before. - Grant > If the answer to those questions is yes, then you're swapping excessively. If > not, you're not. > > There are ways other than swap to find yourself in iowait, though. I wonder > what might a good metric of combining iowait numbers with swap event counts. > Swap events without iowait are likely imperceptible. > > But it does all come down to perception and how you want to manage it. I have > some nodes that swap a *lot*, but I don't care as long as they don't fall > behind in their workload. And I have some nodes that I don't permit to swap at > all, as that causes latency spikes that are difficult to nail down, or can > cause > snowballing cascade events across several nodes and processes that interact > with each other.
