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

[8.306 - ASG220] Random 100% CPU spikes

Hello,

We have noticed that lately, the whole network seems to just "bog down" real hard for a few seconds, fairly randomly.  Looking at our ASG220's reports, it seems that the CPU is spiking pretty hard and out-of-nowhere.  Attached a is pic of what I'm seeing, but I'm still pretty new to Astaro's interface, therefor I'm not sure what else to post up to pitch in more ideas of what's going on.

I don't see anything that would be causing this.  It is definitely noticeable when it does spike, but hasn't been an issue until, what seems, is the update to 8.306.  Nothing else has really changed on the network since.

Where would I look to find more information on what could be spiking the CPU usage like this?

Thanks for any and all help offered.


This thread was automatically locked due to age.
  • 8.306 came with a new IPS engine ... and I've noticed RAM and CPU usage increases on older appliances running this version.  Do you have IPS enabled?

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • I turned off IPS, which lowered the average ram usage... but the CPU spikes still occur.  See attached, red line roughly when turned off.
  • Hi, if you can get a Process List during one of the spikes, it should show the offending processes.

    Barry
  • Hi, if you can get a Process List during one of the spikes, it should show the offending processes.
    Barry

    Sadly, this doesn't even look like 100% usage, but it sure is peaked. [:(]  Well, I tried to paste in my log, but I can't put more than 1,000 letters in this forum, it says.  Only two were even over 2%...

    postgres 22637 27.7 26.7 320940 274736 ?       Ds   06:40   3:55  \_ postgres: reporting reporting [local] REINDEX
    root     23590 25.0  0.0   2616   936 ?        R    06:54   0:00      |   \_ ps auxwf
  • Hi, it's normal for the database (postgres) to reindex and use some CPU.

    Your SWAP memory usage is still high; I was just working on another system with high swap and ram usage, and found that it was contributing to network problems.

    Maybe you can reduce memory usage by switching to single-scan anti-virus, etc.

    Barry
  • Hi to all,

    at first: I can confirm the issue of high CPU usage on ASG 220 with IPS on.

    We got the same thing here after update to 8.306.
    I talked to our sales support and was given two advices
    - under "Logging and Reporting" set a shorter period for report settings
    as reports are stored in the database and may put unnecessary load to it when getting too big
    - switch of IPS if not really needed

    This one (mainly the last point) worked and the ASG is back to normal

    I still wonder why this new IPS-Pattern was released for the ASG 220 ?
    If IPS were of urgent need for us and we were not able to switch it off, it would have rendered the ASG 220 real useless.

    We have some persistent VPN-Tunnels and some "roadwarriors" which connect from time to time.
    When the CPU was pushed by IPS all VPNs broke and internet services were unusable.
    In summary this update was more trouble than help ...

    Regards

    OU
  • # sudo su -
    # /etc/init.d/postgresql rebuild


    Resolving Spikes CPU Graphs...
  • We have updated the Astaro ASG220 to 8.307 and rebuild the database  and we still having some cpu spikes.
  • I've got the same problem with an ASG120, (8.307, Base,Net,Web Security, UTM9 still not offered for DL). 
    I do not have 100% CPU peaks but frequent 50% peaks which appear every 15min (see screenshot).

    I also had the same ideas to

    • disable IPS
    • deactivate automatic Firmware download
    • bigger intervals of pattern download (15 to 30min)
    • single AV engine was already chosen


    I did not rebuild the postgreSQL DB because I want to try to solve it without the shell.

    Does anybody have more ideas?

    ---