When should I worry about swap usage?

The problem it is situation based and not a fixed process (hence "some"). Setting swappiness to 0 tells the kernel basically to never swap to disk (however regardless of this setting, if you run out of RAM, its going to swap anyways). The problem with this is that not everyone has the same box spec. If all boxes were guaranteed to have certain amounts of RAM necessary to always handle their load, then a SMALL performance benefit might be seen. However, swapiness allows the kernel to move things onto disk and back that it might not need again in the short term (how often and aggressively it does this is controlled by the value), thus freeing up the memory to do other, USEFUL things rather than holding something reserved. Now, the issue of Linux Kernel Memory management has been debated back and forth by people far smarter than me, including the source developers who had a great conversation on the mailing lists about 5 years ago, and even they didn't reach a firm "number" for everyone, 0 or 100 or anything in between.

Given a scenario which might be useful as an example, if your machine is already near the limit of memory due to actual load, with swappiness at 0 if you only have 20 megs of ram left and suddenly you need immediately 50, then RIGHT THEN the kernel has to write 30 (or 50 depending on the task/process) to the disk to free up memory space for what it requires to operate. If it had been allowed to move inactive stuff ahead of time, it could have been prepared better for this, since now there is a visible slowdown to the user perhaps.

As such, I can't tell you "snort" will always run better with swappiness at 60, and at Astaro we've even adjusted it downwards to 30. now for a desktop, id agree 0 is a great number since you don't want to sit down and open your vlc player then wait for the kernel to move things around from swap (causing a delay of a few seconds perhaps where you wait and tap your foot). However this also only works if you never run out of memory or it actually gets far slower. On desktops running linux, this is worth it, on production servers running crucial tasks, we let the kernel operate the way it was designed to. 

Regardless, setting swappiness to zero isn't going to lower your ram usage, and at the same time isn't going to provide any real, noticeable performance benefit (as some have confirmed) that you will see and go "wow" so its kind of a moot point.

On the hard disk question, once the kernel has itself hard disk it can use as swap, a nice, optimized and proven piece of real-estate, it makes absolutely zero performance difference if it gives it back or hangs onto it for future use, since again, if its not actually using the allocated space, there is zero impact. Its actually a bit faster for the future since it doesnt have to "find" space instantly when a future situation requires it. Since its not really "me" per se that wants to keep it allocated, you'd have to defer super-deep design questions to the Suse Enterprise Kernel builders [;)].

Hope that is of some use...

Good points Angelo. It's not like Astaro is moving out memory that is being actively used. memory is only swapped out when it is idle for some time. For example, numerous processes on Astaro are low priority background processes, and are only active every few minutes. Why waste physical memory waiting for an app that will only be used briefly every few minutes. The idle process isn't going to suffer if it has to wait an extra few ms for the memory to be swapped back in.  On the other hand, by NOT swapping that memory, you may cause performance problems elsewhere.

For instance you run the risk of causing a user-noticeable network slowdown when an active file download now has to wait for the kernel to reclaim enough RAM from idle processes to scan it. This is a problem I DO see whenever customers begin to run out of physical memory. By being extremely reluctant to swap idle processes into RAM, you force that bottleneck to happen sooner than it needs to.

So, Alan and Angelo, there's actually an Astaro algorithm that swaps based on how long it will be until the code is needed again - a predictive swap?  It's been a few years since I worked inside an OS on virtual memory swaps, but I'm glad to know there's been an improvement over swapping out the least-recently-used memory blocks.

Still, with an upper-limit of 50MB for virus-scans, and 240+MB of unused RAM (maximum: 76.04% of 1GB) since our production box was rebooted in May, it's curious that the V7.40x swap file would have grown to 30%.

Cheers - Bob

Hi Bob, this is all normal Linux Virtual Memory stuff, nothing Astaro specific.

When I see my swap file dramatically grow, its because of an active process using a lot of memory, or something that ran at night such as accounting, and the swap is left 'open' as the kernel sees fit.

Barry

I want to make a proposal to the dashboard memory usage display:

The swap usage meter could show both maximum and actual swap usage at the same time. For example the maximum usage is displayed in green (just as it is today) and the actual value in red at the same time. So everyone would see at first sight whether his system is actively swapping or only has swapped in some single heavy load situation.

Regards,
Bastian

I want to make a proposal to the dashboard memory usage display:

The swap usage meter could show both maximum and actual swap usage at the same time. For example the maximum usage is displayed in green (just as it is today) and the actual value in red at the same time. So everyone would see at first sight whether his system is actively swapping or only has swapped in some single heavy load situation.

Regards,
Bastian

Thanks, Barry, I figured as much.  It's just that Astaro sets the swappiness level.  Say, is there such thing as predictive swap?  I would think that even some low-priority tasks need to avoid being swapped, that they are used often, but just don't worry about tiny interruptions.  If someone's invented flags for "swappability" and "countdown" to facilitate more-intelligent swapping, then I'm less confused by Astaro's swappiness.

If something ran at night and needed lots of RAM, then why was the maximum RAM usage 76.04%?  And why was swap almost zero for several weeks?

Bob,
As Barry mentioned, there is nothing custom about Astaro's memory mangement. We use the memory management inherent in the kernel.  Also, there is no need to be predictive. the main reason you would want to keep items in physical ram is to avoid initial delay when moving an item from swap to physical memory. In some circumstances this matters, but in others it doesn't. 

For instance, if you sit down at your workstation, and maximize your browser, you expect it to pop up quickly. In this case, a delay of a few seconds due to swapping would be noticed, and might be annoying to the user. The initial delay as perceived by the user is the source of annoyance. You don't know what application the user is going to choose, so keeping as much data as possible in RAM, as William describes, makes some sense.

In a firewall environment, the most important factor is not UI responsiveness, but information throughput. Active traffic flows will not ever will not be idle in memory long enough to be swapped out, so long as there as physical memory free. When a program becomes active again, and has to access memory that has been swapped, then there will be a small delay on first access, but it will not be perceptible to anyone using the firewall.  If it takes a few seconds or even a minute longer to send the executive report, or to compile the latest dashboard statistics, you will never know.  however, if the system needs to swap to process a new traffic flow, then that swapping delay can cause a noticeable delay to the end user.

Thanks, Alan, that all makes sense.  It sounds like you are using some method that makes some processes "sticky" and others "swappy" instead.  I'm relieved to know that this isn't simply a Least-Recently-Used algorithm that swaps anything older than x milliseconds.

In his last post above, Barry commented, "When I see my swap file dramatically grow, its because of an active process using a lot of memory, or something that ran at night such as accounting, and the swap is left 'open' as the kernel sees fit."  If that's the only time, then I say, "no harm, no foul."

It's curious that the new "Current" for each period is the height of the previous peak; witness the attached most-recent monthly for my company.

Anyway, it appears that we've belled this cat, so on to the next mystery!

Cheers - Bob