Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 97 replies
  • Subscribers 0 subscribers
  • Views 43902 views
  • Users 0 members are here
Options
Suggested

[8.970] UTM9 Beta Performance Tweak

William Warren
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
  • 0
    @William:

    just to check whether you have a real performance problem because of swap usage, may I suggest that you run the command below, wait for 24 hours for the command to complete and then take a look at the [FONT="Courier New"]/tmp/vmstat.txt[/FONT] file? While waiting, please log out from the SSH shell, and don't use the webadmin to constantly look at your memory.  

     nohup vmstat -n 179 482 /tmp/vmstat.txt 2>&1 & 



    A short explanation for the rest of you guys following this thread. Let me first quote some text from the `vmstat` manual page: 
    vmstat  reports  information about processes, memory, paging, block IO, traps, disks and cpu activity


    So, the command `vmstat 179 482` above prints one line of statistics every ~3 minutes into a file named /tmp/vmstat.txt. It does so 482 times, which is ~ 24 hours. The `nohup` and all the other stuff are just to make sure that the process runs in the background, even after you close your SSH session and log out.

    Cheers,
    Kai
Reply
  • 0
    @William:

    just to check whether you have a real performance problem because of swap usage, may I suggest that you run the command below, wait for 24 hours for the command to complete and then take a look at the [FONT="Courier New"]/tmp/vmstat.txt[/FONT] file? While waiting, please log out from the SSH shell, and don't use the webadmin to constantly look at your memory.  

     nohup vmstat -n 179 482 /tmp/vmstat.txt 2>&1 & 



    A short explanation for the rest of you guys following this thread. Let me first quote some text from the `vmstat` manual page: 
    vmstat  reports  information about processes, memory, paging, block IO, traps, disks and cpu activity


    So, the command `vmstat 179 482` above prints one line of statistics every ~3 minutes into a file named /tmp/vmstat.txt. It does so 482 times, which is ~ 24 hours. The `nohup` and all the other stuff are just to make sure that the process runs in the background, even after you close your SSH session and log out.

    Cheers,
    Kai
Children
  • 0 in reply to kbr
    @William:

    just to check whether you have a real performance problem because of swap usage, may I suggest that you run the command below, wait for 24 hours for the command to complete and then take a look at the [FONT="Courier New"]/tmp/vmstat.txt[/FONT] file? While waiting, please log out from the SSH shell, and don't use the webadmin to constantly look at your memory.  

     nohup vmstat -n 179 482 /tmp/vmstat.txt 2>&1 & 



    A short explanation for the rest of you guys following this thread. Let me first quote some text from the `vmstat` manual page: 

    So, the command `vmstat 179 482` above prints one line of statistics every ~3 minutes into a file named /tmp/vmstat.txt. It does so 482 times, which is ~ 24 hours. The `nohup` and all the other stuff are just to make sure that the process runs in the background, even after you close your SSH session and log out.

    Cheers,
    Kai


    i don't use webadmin to check memory..i use ssh only..[:)]  I'm not saying i'm having performance problems now..but you will.  since v9 has been soft-released i've terminated my testing.  Let's lock this thread now and we'll see if when these appliances start 1. being sold with v9 or 2. begin getting upgraded if the issues come forth or not.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

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

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 0 in reply to kbr
    ...While waiting, please log out from the SSH shell, and don't use the webadmin to constantly look at your memory....

    I am running the command right now and will probably have similar numbers to Mark. However I don't agree with the testing methodology. In a regularly used system, there would not only be webadmin logins, there will also be user portals that will become active at certain times. Depending on how the sytem is setup, a lot of users might log in at the same time. I also think it would be normal for an admin to look at user activity using webadmin to tweak certain settings or allow access to certain blocked pages.

    Just because all the core daemons are finished swapping doesn't mean that there won't be any additional paging by admin while using webadmin for thing like configuration changes, creating reports and alike. As I mentioned before, I am fairly satisfied with this final version, however measuring the paging without using webadmin at all is not really a true representation of how much paging is going to take place if multiple admins log into webadmin and start tinkering with the system.

    Regards
    Bill
  • 0 in reply to Billybob
    Hi Bill,

    However I don't agree with the testing methodology...


    I probably should have been more clear: what I meant is that you don't sit in front of the webadmin refreshing the dashboard every second while at the same time constantly checking every section of the reporting and looking at the traffic monitor on your third monitor. You wouldn't get paid for that on your real day job too, right? Just normal usage, and if this includes the Portal and checking the logs once or twice a day, I'm fine. 

    Cheers,
    Kai
  • 0 in reply to kbr
    Thanks for the clarification. Here are my results and I had the max so of 58KB during one interval as my system load is very low. This looks good on my machine, lets see how it does when we put it in production under heavy loads[;)]
    Regards
    Bill
Unfiltered HTML