When should I worry about swap usage?

Angelo, are you repeating what "they" say, or can you name processes where you've seen this yourself?  William's scientific method looks sound to me, so it might be worth "challenging" the developers with this thread.

I had used william's method for tweaking squid a little till they changed to in house proxy. I think swappiness has been talked about extensively and even the original linux developers are not really sure which way they like it, thats why they left it for us to decide[:O] 

I had tried the swappiness value of 0 when astaro default was 60 but really didn't see any major improvement over default. Most linux admins and admins in general don't like swapping period. If you can afford the cheap ram why would you want to swap. But I think the problem is with the astaro kernel itself. It likes to swap. I have 1gb ram and even if I only run a few services, in a few days, I will have a couple of megs swapped out with swappiness at 0. I can run almost all services (light load at home) and the swap behavior doesn't chage much and the swap usage still goes up to only a couple of megs. 

All in all, on a server, with a fast enough processor and a few megs of swap, you probably won't notice the difference as much as you would on a workstation so I just quit obsessing about it. Otherwise at one time, I was taking drastic measures by running swapoff/swapon as cron jobs right before everybody got to the office just to load the swap back in memory[:D] I know not the best idea but it does work. By the way here is my top and as you can see after 16 days, its still only swapping around 2megs with IPS, single AV http proxy, mail av proxy, and vpn.

Obviously the orignial poster's memory usage does not agree with mine and hence you are hearing william talk about it passionately. By the way welcome back william, hadn't seen you in a while.

Sure we can chat about this. First however the difference must be understood between "allocated" swap and swap which is actually being called upon and actively used. This is one of the biggest things that isn't grasped by many.

For example attached is a box with 1.5GB of ram which i injected massive gigabytes of logfiles into, causing the reporters to work like crazy, and needing some swap (just a few hundred megabytes, which is pretty good considering what I gave it to eat). I attached a screenshot of it.

Now, long after the job is "done" the swap in webadmin still shows around 430Mb-ish of usage. However, if I go to the command line and use a command like vmstat, I see that for the swap file, there is ZERO paging happening (as indicated by the si and so values under ---swap-  (Attached as well). So while the disk is allocated to swap, its not actively doing anything or costing me performance.

The key is to get that there is a difference between a block of disk space that the kernel needed at some point to be swap, and swapping which is actually happening right now and slowing down your system. When the system has had to use swap for whatever reason, it now has a nice piece of hard disk that it can keep and use later should swapping be required in the future, call it good planning on behalf of the kernel. 

I'll post a bit more about swappiness after the fires die down today.

why would you want to keep hrad disk allocated when it's an order of magnitude slower than ram?  heading to the disk is always slower than keeping it in ram..jsut the access tiems between hdd and ram potrays this to be true.  vm.swappiness=0 keeps the system away form the hdd as much as you can without seriously digging into the kernel code.  
 
either way youa vhe not answered the basic question..which processes are slowed down with swappiness set to zero?

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

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.