Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 3 subscribers
  • Views 3758 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

High CPU - Postgres / HTTPD / Proxy, etc

Jayson
Howdy

Hopefully this information finds / helps some of you.

For the last year we have been dealing with daily outages of our UTMs in multiple locations. 

Sophos tech support hasn't been able to find the issue and therefore hasn't been too helpful. We also called in various third party support companies and had no luck there. Sophos in a last ditch effort replaced our hardware free of charge (The hardware they gave us was beaten to hell, so I wasn't happy about that)

Still the issue of super high CPU has continued daily for a year causing the units to lockup and fail every day. There have been a handful of ways to fix this issue including hard reboot, wait it out and hopefully get in via SSH and kill the run away process or use the postgresq192 rebuild trick. None of these are welcome work arounds when you have hundreds of employees trying to use the inet pipes.

Solution!

Today I can report we have found the cause. (at least for our issues) In a word, HTML5 proxy, okay, yes that's two works technically, but it doesn't change the fact that it's the cause of countless hard conversatoins with my bosses. 

Apparently when literally one person logs in to the HTML5 portal the resources just start slowly climbing until the unit flat out bricks. We have tested this in both directions. A person OUTSIDE the network using the HTML5 portal to access the internal node and a person INSIDE using the HTML5 portal at a branch location to access a node there. The result is the same in both cases. The resources start climibing and the systems eventually crash.

We have never been able to figure out why this problem is so damn random. It could happen in the middle of the night or a few times per day. We now understand why, people were logging in from home. 

So the solution for us is to obviously turn the HTML5 portal off. Maybe this will work for you if you're having a similar issue. 

-Jayson


This thread was automatically locked due to age.
  • 0
    You have major patience Jayson.  I would have lasted about a week before ditching the UTMs!  Thank god you figured it out.

    -Jim
  • 0
    it also depends on how loaded the box already is.  I have a couple of html5 vpn portals setup and don't have any issues.  I do have the boxes however built to handle the large cpu overheads of the http proxy, ips and html5 at the same time for the userloads.  How many users and which features are you using on your machine?  Also which utm series box is this?
  • 0
    Average load during "episodes" 10.+, 10.+, 10.+

    After turning off the portal so it couldn't be used any longer

    Average load (this moment) .5, .8, .8

    a couple of hundred users, web proxy [on], smtp proxy [on], snort [on], antivirus [single scan], etc, etc, etc. 

    This simply was never caught prior because the crashing has always been so random and the connections are poorly logged (in my opinion)

    As for WHY we kept with it even during the issues outlined. We have a pretty large investment in the Sophos UTM line and that wouldn't come up for renewal until next year. My boses have pretty much wrote the rollout as a failure and do not want to renew, but I think now that we have finally figured out the WHY, they may change their minds. I've personally been using it since it was Astaro in 2006. Love the offering, it just went downhill for us (again, I'm only outlining a fact) after Sophos took over and we upgraded to UTM 9.

    Edit

    This issue happens even with HA fail over as well as HA load balanced. 

    And only takes ONE (1) user using the HTML5 portal to bring it all crashing down.