Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 27 replies
  • Subscribers 2 subscribers
  • Views 13336 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

[9.201-25] httpproxy high CPU

Systemtechnik
Hi,
after the update from 9.111-7 to 9.201-25 do we have Problems with the Performance.
Hardware: HA two Sophos UTM9 ASG320
CPU is switching between 50 an 100%.
In the Process list i see the httpproxy is up to 61%

61.3 39.4 2010332 1586496 ?     Ssl  May28 1537:11 /var/chroot-http/usr/bin/httpproxy -f -c /var/chroot-http -u httpp

Swap is after the Update also on nearly 100%

We tried to go back on 9.111-7 via Backup restore, but it dosen´t work.
After the restore we have still the firmwar 9.201-25


This thread was automatically locked due to age.
Parents
  • 0
    This certainly sounds like something for support to sort out.

    Please share any interesting diagnostics and the resolution from your support ticket.
  • 0 in reply to teched_01
    Hi Systemtechnik,

    We have upgraded to 9.2 (using the full ISO install). With such a major revision using a full 9.2 iso will format and clear the partions and start fresh and is ideal if you can.

    However, one thing I did notice is that we use sc_local_db mem to keep the performance of the http proxy fast (with 600 users im sure you must be using this too) when we imported our existing config from 9.1 the setting transfered across and during out deployment phase we never let it fully download properly.

    You may need to force rebuild this as it may have become corrupt, also do it out of hours as until it fully downloads users wont be able to browse the internet.

    cc set http sc_local_db none

    /var/mdw/scripts/httpproxy restart


    /var/storage/chroot-http/var/pattern/sfcontrol # rm sfcontrol
    /var/storage/chroot-http/var/pattern/sfcontrol # ls

    cc set http sc_local_db mem

    /var/mdw/scripts/httpproxy restart

    https://www.astaro.org/gateway-products/web-protection-web-filtering-application-visibility-control/46373-force-rebuild-local-web-content-cache.html#post228428

    Another thing to note is to make sure your pattern updates are not set at 15 minutes, as it wont fully download if a pattern update comes down and will restart the download.

    I set mine for 2 hours, because every time a pattern update occurs it has to swap out the existing one and at that time creates a small delay for users.
  • 0 in reply to stealthmatt_01
    During one of the 9.x betas, Sophos changed their recommendation to use SXL instead of the local database. As I recall SXL caches category lookups and gives near-local-db performance. Sc_local_db needs to be set to none prior to enabling SXL.

    cc set http sc_local_db none
    cc set http use_sxl_urid 1

    One thing no one asked is the revision of your ASG320. The company I work for still has a few older ASG220s that only have 1GB of RAM. They struggle with UTM 9.1 even with most features disabled. The Sophos branded version of the ASG220 doubled the RAM which would help us.
Reply
  • 0 in reply to stealthmatt_01
    During one of the 9.x betas, Sophos changed their recommendation to use SXL instead of the local database. As I recall SXL caches category lookups and gives near-local-db performance. Sc_local_db needs to be set to none prior to enabling SXL.

    cc set http sc_local_db none
    cc set http use_sxl_urid 1

    One thing no one asked is the revision of your ASG320. The company I work for still has a few older ASG220s that only have 1GB of RAM. They struggle with UTM 9.1 even with most features disabled. The Sophos branded version of the ASG220 doubled the RAM which would help us.
Children
  • 0 in reply to crayd
    Hello,

    Thx for all your help, but it still dosen´t work.


    First we tryed this One on Node 2 (Master):

     cc set http sc_local_db None (came a 1 out)

     cc set http use_sxl_urid 1  (came a 1 out)

    After this the Node 2 shutdown himself

    Then we tested this, but we think it was on the Node 1 (first Slave now Master)

    cc set http sc_local_db none

     /var/mdw/scripts/httpproxy restart


     /var/storage/chroot-http/var/pattern/sfcontrol # rm sfcontrol
     /var/storage/chroot-http/var/pattern/sfcontrol # ls

     cc set http sc_local_db mem

     /var/mdw/scripts/httpproxy restart  

     
    Proxyhttp still bad and swap also.
    Then we saw that the Node 2 was down an restarted it and he snyc with Node 1.

    So i think the first type for SXL where overwrite  by syncing from Node 1 or not?