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

[9.200] high httpproxy cpu usage

Since the update to 9.200, I've seen httpproxy causing 100% cpu usage a few times a day, the proxy becomes unresponsive (webadmin, etc seem to be still OK, though). Restarting just the proxy alleviates the problem, plus I've seen it restart on its own if left long enough. 

 
Normally, httpproxy only consumes between 50 and 150% CPU on 4 cores. I'm Running the software version on VMWare.

Any thoughts?


This thread was automatically locked due to age.
  • Hi addrockk,

    Would it be possible to get access to your box so we can investigate directly?  Please PM me to arrange this and I'll have a developer look into it.
  • I have a ticket open with escalation now, so someone from Sophos already has access to the box. Can I just raise the issues with him, or will I need to go through the process of opening a new ticket, etc?
  • Also, I'm seeing a lot of messages like this:

    2014:03:12-09:40:39 gateway httpproxy[2934]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0x48300880" function="match_exception_domainlist" file="profile.c" line="611" message="exception Advanced Academics exceeded pcre limit on http://fw.adsafeprotected.com/rfw/dc/23789/1925785/adi/N7140.274397.DSTILLERY.COM/B7992813.4;sz=300x250;dcopt=;ord=1394631633609;click0=http://ad.media6degrees.com/adserv/clk?tId=14688636371681828|cId=24848|cb=1394631632|envType=WEB|notifyPort=8080|exId=20|tId=14688636371681828|tpInvId=2062|ec=1|secId=57|price=UyBj0AALF5UKNCrNAABHOYZtVRlAWWXWoKUgkA|pubId=1196|advId=1739|is_anon=0|notifyServer=asd246.sd.pl.pvt|bdie=1f5tau56dmgtq|spId=93265|adType=iframe|invId=5706|bms=d2VhdGhlci5jb20=|bid=3.31|ctrack=http://adclick.g.doubleclick.net/aclk%3Fsa%3Dl%26ai%3DCUskB0GMgU5WvLM3V0AG5joHQAa_UzbEE3-G0uHbAjbcBEAEgAFCAx-HEBGDJzqCLwKTcD4IBF2NhLXB1Yi05ODY3OTk1NzI2MjA0NTI0oAGLgMjrA8gBCeACAKgDAaoE3AFP0POnMToxCPzGQGEWbDop-gCUzmbUWJpH6A6CTJIQVK98WlbuAzYufX9Xl3M9FR4KuKBFhKA3fEQHBFUbsGSTpyokWjbYkWO9KkQxxfAew6nNa4JnEcUcAu7QpKTGNgRs86ZwP-e9JwJCLpaX02KNo67XMxeGHgGFuKuOTaFFJrCeG5ci7t3Tz7vzO-rXsdAdB8qc4o5sSPR8acsEznfbPNfP7Mxizq8509gsP7UY4Ie8r1S-EIT4jPAmum5HNryukrmvm6VEQiv5MOAPnmBU_3VNjooKRNRlrZSD4AQBgAbP2-fB7PHxraIBoAYh%26num%3D1%26sig%3DAOD64_2bF2Q4Ori2TTK2ucRJO7cl-mBsmA%26client%3Dca-pub-9867995726204524%26adurl%3D&adsafe_preview=0&adsafe_url=http%3A%2F%2Fwww.weather.com%2Fweather%2Fmap%2Finteractive%2F13790%3A4%3Fzoom%3D7%26interactiveMapLayer%3Dradar%26animation%3Dtrue&adsafe_pb=http://creative.media6degrees.com/adsafe_psa_2013/blank_300x250.jpg&adsafe_jsinfo=,c:6DpRWD,sl:na,em:true,fr:false,pt:1-5-15,br:i,fv:11.9.900.117,bv:10,dm:10,abv:10.0.9200.16576,id:e43e8d44-a9eb-11e3-806e-00259036a24a,fm[:$]yiMeqJ+11|12|131|1321|1411*.23789-1925785|142|15|16|17,ex:n15,rpx:0,fc:0,rt:0,cb:0,np:1,uf:1,tt:jsi,et:127,uid:a82f00918ff1a6678f75cd4557668a,v:7.1,sp:0,ct:na,ov:0"


    It looks like this might be back. (If it was ever fixed, that is). I'm seeing it quite a lot.
  • That message occurs when you have inefficient RegEx and a very long URL.  It is not an error per se and can be ignored.

    In that thread/mantis we updated some RegEx that we wrote, however any RegEx that are customer written need to be updated by customers.

    You have an Exception called "Advanced Academics".  The regex probably looks something like:
    ^https?://(.*\.)?site\.com/

    You should change it to
    ^https?://([A-Za-z0-9.-]*\.)?site\.com/

    The difference is that .* will match any character and therefore the entire long URL is checked for site.com.  The character group [A-Za-z0-9.-]* does not match a / therefore the site.com will only match if it occurs before the first slash - in other words it searches the domain only.

    Also try this tool:
    Quick RegEx for URLs | UTM Tools
  • As for Support, I don't know.

    We're in a transition right now.  The forums are for beta, support is for release.

    If you want the qa/devs who are working on Beta to look at the httpproxy high CPU then please contact me in IM.  This type of thing is less official but gets you to the experts faster, and you'll need to do this separate from any other contact.

    If you want Support to look at, then I would follow up with them on whether they need a separate ticket raised, etc.  If someone already has access to the box they may be able to take a look quicker and resolve it quickly (but if they agree it is an bigger issue it may take slightly longer to get it resolved as there is another link in the chain before it gets to devs).

    I'm a UBB forum guy, so you know what my preference would be.

  • You have an Exception called "Advanced Academics".  The regex probably looks something like:
    ^https?://(.*\.)?site\.com/

    You should change it to
    ^https?://([A-Za-z0-9.-]*\.)?site\.com/


    Indeed, they are like that. Thanks for the explanation. I guess I didn't think searching the whole URL was an issue, but I see how it could be. Does the "." in [A-Za-z0-9.-] become literal (instead of matching any character) when it's inside the brackets?
  • It is perl that is doing the regex for us, and there is a limit (which we can control) over how much memory (buffer) it can use to do a single lookup.  This limit is there because really bad regex can ruin a system (see Runaway Regular Expressions: Catastrophic Backtracking)

    How much buffer memory is needed for regex is a function of sting length and regex complexity.  Suffice it to say that any regex that must search the entire string will use more buffer.  The buffer that we have for a long time is unchanged in 9.2.  It only runs out of buffer if the regex includes a .* and the URL is roughly >1500 characters.  Long URLs are becoming more common as time goes on so we are seeing the poor regex exposed more.  Increasing buffer size only makes the problem occur later.

    Yes within a character set the . is literal.  More information can be found here Regexp Tutorial - Character Classes or Character Sets