Guest User!

You are not Sophos Staff.

[8.970] UTM9 Beta Performance Tweak

I've noticed that UTM9 just isn't up to par with what i'm going to call UTM8.  I've also noticed a ton of swapping being used even with vm.swappiness=0 set.  even with 3 gigs of ram installed I was still swapping 25% even though the system was caching more than 25% of physical ram.  I've seen this before in older kernels.  Back in 2.4 I filed a bug with centos and by extension redhat about a similar problem...it was later fixed in the next kernel patch.  

I decided to try something..something i did back in the 2.4x days....I disabled swap entirely.  I now have the latest beta running with 3 gigs of ram and zero swap(swapoff -a).  I've had this running for 24 hours:

 free
             total       used       free     shared    buffers     cached
Mem:       3087332    2730288     357044          0      94552     769160
-/+ buffers/cache:    1866576    1220756
Swap:            0          0          0

Within 24 hours i would have 10% swap...within 36 hours i would have 25% swap.  There's no reason for a system that is under ZERO memory pressure to be swapping to disk at a rate of 25% or higher when more than 30% of physical ram is unused.  I could go digging into the kernel deeper to find out why this is occurring but this is a development problem..not a partner/user problem.  V8 does NOT display this behavior.  I've noticed this since the first beta of UTM9.  I'm curious how many other performance regressions I've found might be addressed?  The testing begins..[:)]
Parents
  • For the folks using 1 gig of ram, you will have a bit more active swap than the 2 gig guys, as you can see from the various load figures posted in your findings in this thread.

    Whats probably more interesting that you are leaving out is the IO to the swap partition itself. As we've beat this horse to death on the issue of allocated swap vs. active swap. If your load is light, then your box won't actually be any slower when the swap figure is higher. We will however look to remove the swap "bar graph" from the dashboard in the next up2date, (while of course leaving it present in all hardware graphs and detailed reports as it is currently), since the swap figure routinely causes us to have to educate users on linux swap behaviour, particularly in support where customers ask why it is high without having any real performance issues. You will notice swap may 'grow' and actually be used during the nightly maintenance, as during this short window the system is under load while doing the log rotation and report crunching.


    I will see if we can get iostat added to the system so you can more closely tweak and see this. Keep in mind you will notice swap never goes "down" really, especially up and down like memory does. There is a reason for that. [:)]
  • For the folks using 1 gig of ram, you will have a bit more active swap than the 2 gig guys, as you can see from the various load figures posted in your findings in this thread.

    Whats probably more interesting that you are leaving out is the IO to the swap partition itself. As we've beat this horse to death on the issue of allocated swap vs. active swap. If your load is light, then your box won't actually be any slower when the swap figure is higher. We will however look to remove the swap "bar graph" from the dashboard in the next up2date, (while of course leaving it present in all hardware graphs and detailed reports as it is currently), since the swap figure routinely causes us to have to educate users on linux swap behaviour, particularly in support where customers ask why it is high without having any real performance issues. You will notice swap may 'grow' and actually be used during the nightly maintenance, as during this short window the system is under load while doing the log rotation and report crunching.


    I will see if we can get iostat added to the system so you can more closely tweak and see this. Keep in mind you will notice swap never goes "down" really, especially up and down like memory does. There is a reason for that. [:)]

    What's the reason for the swap going to over 50% in a nearly unloaded scenario in 4 gig machines?  I can only imagine the 2 gig scenario.  Is v9 that piggish on ram usage that even 4 gigs isn't able to contain it now?  if so why did you only spec the boxes at 2 gigs when it's obvious 4 is the bare minimum?  Posts are now coming out showing 4 gigs swapping at nearly 100%.  that's not normal and will lead to performance issues.  Is swap now the same as /tmp for the Astaro distribution?  The nonchalant attitude towards this behavior is a bit concerning as we partners will have to bear the brunt of customer ire and even those more knowledgeable than myself aren't going to be able to tweak things to get ram usage under control.  Are our choices effectively limited to buying 4xx and higher machines or build our own boxes with 8-16 gigs of ram to have a prayer of fending off performance issues that this crazy swap issue is going to introduce?

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

Reply
  • For the folks using 1 gig of ram, you will have a bit more active swap than the 2 gig guys, as you can see from the various load figures posted in your findings in this thread.

    Whats probably more interesting that you are leaving out is the IO to the swap partition itself. As we've beat this horse to death on the issue of allocated swap vs. active swap. If your load is light, then your box won't actually be any slower when the swap figure is higher. We will however look to remove the swap "bar graph" from the dashboard in the next up2date, (while of course leaving it present in all hardware graphs and detailed reports as it is currently), since the swap figure routinely causes us to have to educate users on linux swap behaviour, particularly in support where customers ask why it is high without having any real performance issues. You will notice swap may 'grow' and actually be used during the nightly maintenance, as during this short window the system is under load while doing the log rotation and report crunching.


    I will see if we can get iostat added to the system so you can more closely tweak and see this. Keep in mind you will notice swap never goes "down" really, especially up and down like memory does. There is a reason for that. [:)]

    What's the reason for the swap going to over 50% in a nearly unloaded scenario in 4 gig machines?  I can only imagine the 2 gig scenario.  Is v9 that piggish on ram usage that even 4 gigs isn't able to contain it now?  if so why did you only spec the boxes at 2 gigs when it's obvious 4 is the bare minimum?  Posts are now coming out showing 4 gigs swapping at nearly 100%.  that's not normal and will lead to performance issues.  Is swap now the same as /tmp for the Astaro distribution?  The nonchalant attitude towards this behavior is a bit concerning as we partners will have to bear the brunt of customer ire and even those more knowledgeable than myself aren't going to be able to tweak things to get ram usage under control.  Are our choices effectively limited to buying 4xx and higher machines or build our own boxes with 8-16 gigs of ram to have a prayer of fending off performance issues that this crazy swap issue is going to introduce?

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

Children
No Data