This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

When should I worry about swap usage?

I've installed two new ASG 220s with HA, IPS, and web and email security on.  For the first few days RAM hovered around 65% with no swap usage.  About 5 days in swap usage suddenly jumped to 10%.  About a week later swap jumped to 20%.  3 days later takes us to today, and my swap usage has jumped to 30%.  Over this time RAM usage has been fairly stable, hovering in the mid to high 60s and occasionally hitting low 70s.

Should I be worried about the increase in swap usage?


This thread was automatically locked due to age.
Parents
  • 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
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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
Reply
  • 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
Children
No Data