Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 57 replies
  • Subscribers 1 subscriber
  • Views 39086 views
  • Users 0 members are here
Options
Suggested
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

UTM Performance Crashes with A/V Scanning, but CPU only at 12%

THXEngineer
I'm having an issue with Sophos UTM 9.307 that when it performs A/V scanning on large file (300 MB) downloads, my entire network comes to a screeching halt, with several machines dropping network connection or freezing up.  BTW, I'm using the dual A/V scan.

My UTM installation is on a home-built machine using an Intel i7-4790k CPU @ 4.0 GHz, hyperthreaded with 8 cores, 8 GB RAM and a 60 GB SSD, Z97 chipset.  NIC's are a single Intel i-350, 4 port (only 2 used - one WAN, one LAN) and an Intel NIC built onto the motherboard.  I wouldn't think I'd be potentially hardware limited with this setup.

Per posts here on the Sophos BBS, I've disabled Intel's "Enhanced SpeedStep" and "Turbo Boost" options in BIOS, along with the enhanced "C states".  I've also performed BarryG's recommendation at the console:

echo "performance" >/sys/devices/system/cpu/cpuN/cpufreq/scaling_governor

for each logical CPU 0-7.

The maximum CPU usage I've ever recorded in Sophos UTM during normal operation is around 12% when performing a scan on a single 300 MB download.  Note that this 12% corresponds to about 100% loading of one logical CPU core.  I was able to get around 17% CPU usage once when I tried the same download and scan operations on 2 machines (real machines, not VM's) simultaneously, but that completely locked up the network and I only had a few other machines running.  When not performing A/V scanning, my CPU hovers around 1-2%, since we don't have that much network traffic right now.

It seems like the UTM isn't taking full advantage of all the CPU horsepower that is available.  I could understand one of the connections / scans being tied to a logical CPU (with SNORT, etc) and locking it up, but it seems like the UTM would transfer other connections to other logical CPU's and not lock up the entire network.

BTW, the dual A/V scan of the 300 MB file took a couple of minutes.  Does this sound reasonable given the hardware?

It's almost as if the UTM is only using one of the available 8 logical cores to do almost all of the work in my system.

I'm aware that hyperthreading could be an issue due to the way the OS assigns the logical cores, such that logical core 0 and 1 are essentially the same physical core.  I could see this as being a problem when core 0 is at 100% load and the OS tries to give work to the next logical core (1 in this case), which is really already at 100%, but I thought that the underlying OS was "smart" enough to realize this.

Should I disable hyperthreading?  If so, will this corrupt my current Sophos UTM installation that expects to see 8 CPU's?

Does anyone have any other suggestions on setting, etc that would enable the full potential of this hardware setup or is this "normal" / to be expected?  

Thanks in advance,

- Ben


This thread was automatically locked due to age.
Parents
  • 0
    William, thanks for the insights.  I have been slowly making my way through your posts and research on the effects of multi-threading, snort, etc.  Great stuff!  Thanks for taking the time to compile it all.

    One question I have concerning going to 32 GB ram.  Even with the 300 MB dual A/V scan and everything else my small test network can throw at the UTM, my max RAM usage has never exceeded 36 % (I currently have 8 GB installed).  It doesn’t seem like I’m taking advantage of all the RAM I currently have.  For my situation, where I probably can’t generate enough network traffic under normal loading to fully saturate the CPU / RAM, etc, would I see any benefit to going to larger amounts of RAM?  Or is there something going on “behind the scenes” that I’m not seeing?

    When I spec’d out the hardware for my testbench UTM, there was a little method to the madness.  I eventually decided to go the i7-4790k CPU, because the multiplier is unlocked so that I can easily overclock or UNDERCLOCK the CPU, if I determined that 4.0 GHz wasn’t necessary and/or if I wanted to turn on/off Hyperthreading to test the effects of having different logical cores.  This CPU provided the best versatility for a true test bench system where I could experiment with the best combination of raw GHz speed, CPU cores, thermal performance and energy efficiency.  The MB BIOS will allow me to run cores at different speeds as well as under / over volt and clock the CPU as needed.  I know that GHz is king, but do you see a scenario with light network traffic loading, but with high IPS loading, where UNDERCLOCKING a CPU so that you’re maxing out a single core “faster”, could actually improve overall performance?  This kind of gets back to the “too much” CPU discussion.

    Everything I’ve set in BIOS and at the Linux console has all 8 CPU cores fixed at 4.0 GHz, which I’ve verified.  However, when I do load up one of the CPU’s with a good SNORT scan, my total system draw jumps up from around 43 watts at idle to around 55-60 watts under load (measured with my "kill-a-watt" meter), so it does look like there’s some energy savings still being performed by the CPU / BIOS / OS, with the system at idle / light loading.

    Assuming that the 8 logical, hyperthreaded cores are configured as 0&1, 2&3, 4&5, 6&7 representing physical cores 0, 1, 2, 3 and 4, respectively; is there anything from your research that would indicate that it’s possible to dedicate the IPS to use, for example, ONLY logical cores 4 and 6 for IPS; disable logical cores 5 & 7; and allocate logical cores 0, 1, 2 & 3 to normal firewall and other UTM functions?

    What this would do is effectively give IPS 2 physical, non-hyperthreaded cores to do strictly IPS scanning and 2 hypertheaded cores (4 logical CPU’s ) to handle all the other UTM tasks.  I know there’s a Linux console command to limit IPS to “N” number of cores, but I could see a scenario, where this command could actually get you into trouble if the underlying OS isn’t “smart” enough to distinguish between a hyperthreaded core vs a “real” core.  If the underlying OS does distinguish between real vs hyperthreaded cores, then of course this becomes a moot point.

    Sorry for rambling on.  I’m only on my 2nd cup of coffee [:D] !

    Thanks,

    - Ben
Reply
  • 0
    William, thanks for the insights.  I have been slowly making my way through your posts and research on the effects of multi-threading, snort, etc.  Great stuff!  Thanks for taking the time to compile it all.

    One question I have concerning going to 32 GB ram.  Even with the 300 MB dual A/V scan and everything else my small test network can throw at the UTM, my max RAM usage has never exceeded 36 % (I currently have 8 GB installed).  It doesn’t seem like I’m taking advantage of all the RAM I currently have.  For my situation, where I probably can’t generate enough network traffic under normal loading to fully saturate the CPU / RAM, etc, would I see any benefit to going to larger amounts of RAM?  Or is there something going on “behind the scenes” that I’m not seeing?

    When I spec’d out the hardware for my testbench UTM, there was a little method to the madness.  I eventually decided to go the i7-4790k CPU, because the multiplier is unlocked so that I can easily overclock or UNDERCLOCK the CPU, if I determined that 4.0 GHz wasn’t necessary and/or if I wanted to turn on/off Hyperthreading to test the effects of having different logical cores.  This CPU provided the best versatility for a true test bench system where I could experiment with the best combination of raw GHz speed, CPU cores, thermal performance and energy efficiency.  The MB BIOS will allow me to run cores at different speeds as well as under / over volt and clock the CPU as needed.  I know that GHz is king, but do you see a scenario with light network traffic loading, but with high IPS loading, where UNDERCLOCKING a CPU so that you’re maxing out a single core “faster”, could actually improve overall performance?  This kind of gets back to the “too much” CPU discussion.

    Everything I’ve set in BIOS and at the Linux console has all 8 CPU cores fixed at 4.0 GHz, which I’ve verified.  However, when I do load up one of the CPU’s with a good SNORT scan, my total system draw jumps up from around 43 watts at idle to around 55-60 watts under load (measured with my "kill-a-watt" meter), so it does look like there’s some energy savings still being performed by the CPU / BIOS / OS, with the system at idle / light loading.

    Assuming that the 8 logical, hyperthreaded cores are configured as 0&1, 2&3, 4&5, 6&7 representing physical cores 0, 1, 2, 3 and 4, respectively; is there anything from your research that would indicate that it’s possible to dedicate the IPS to use, for example, ONLY logical cores 4 and 6 for IPS; disable logical cores 5 & 7; and allocate logical cores 0, 1, 2 & 3 to normal firewall and other UTM functions?

    What this would do is effectively give IPS 2 physical, non-hyperthreaded cores to do strictly IPS scanning and 2 hypertheaded cores (4 logical CPU’s ) to handle all the other UTM tasks.  I know there’s a Linux console command to limit IPS to “N” number of cores, but I could see a scenario, where this command could actually get you into trouble if the underlying OS isn’t “smart” enough to distinguish between a hyperthreaded core vs a “real” core.  If the underlying OS does distinguish between real vs hyperthreaded cores, then of course this becomes a moot point.

    Sorry for rambling on.  I’m only on my 2nd cup of coffee [:D] !

    Thanks,

    - Ben
Children
No Data