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

Unusually high CPU usage after update to 8.3

dbye
After updating to version 8.3 we have been experiencing higher than usual CPU usage and when I checked it this morning it is running at 99 - 100 percent.  When I check the running processes I noticed 2 processes that are hogging the CPU.

postgres  2178 91.4 21.2 913492 708968 ?       Rs   07:32   0:45  \_ postgres: reporting reporting [local] SELECT

postgres 30211 55.1  4.1 151692 139548 ?       Ss   06:40  29:12  \_ postgres: reporting reporting [local] VACUUM waiting

It seems that these are either stalled or not operating properly.  I only use the web interface for administration and have not had a need to use the shell, but is there a way to kill these processes so that the performance of the box can return to normal at least until the problem returns or I can open a ticket to support for help?

Thanks in advance!


This thread was automatically locked due to age.
  • 0
    i remember reading that thread.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 0
    I meant to post to that thread that it was finally resolved.  Support never really could tell me what was wrong but the fix has continued to work.  They were going to test it in a lab and get back with me, but I have not heard from them and the support engineer has not returned any of my emails.
  • 0
    When you ask your reseller to submit an issue to Astaro, they should be able to look at your system to confirm your issue.  In this case, if your reseller is familiar with your configuration, the pictures you posted would have been enough for your reseller to conclude that you needed Astaro Support.  You should hear from Astaro within a workday, so you might want to ask your reseller to send you the Case ID just to confirm that the case has been submitted.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to William Warren
    Yes - I would have to agree and concur with that experience - this past fall. Apparently a result of a series of occurences - the change in ticketing system that I guess was the result of Sophos 'moving in' and the corporate offices moving a little after that, and some techs on leave with apparently noone to cover their load or watch their queue while they were out, etc.
    We also considered dumping Astaro, and are still going to be considering alternatives before our next renewal.

    Anyway - on the offloading question - even if we do set it to send to remote syslog, or similar, doesn't that mean we are left to our own devices for developing the reports? Is there something that would make that a bit easier? That is not an additional cost?
  • 0
    twgage, like dbye, I think your issue is more with your reseller than with Astaro.  When Astaro moved, I had an issue for one customer that was only partially addressed in the regular time frame on Thursday/Friday, but the follow-up took until the following Tuesday afternoon/evening.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    BAlfson,  The problem was not with our reseller as they worked very hard to try to resolve our issue and I even sat in on some of the support calls between the reseller and Astaro.  Their explanation for the delay was that since the problem we were experiencing was related to an earlier support ticket that was still open they merged it with that support ticket.  The problem was that the support engineer that was responsible for the ticket left the company after the Sophos acquisition and all of his tickets were not reassigned or "checked".  My reseller was finally able to get in contact with someone who actually checked on the problem.  If it was not for our reseller we would be running another platform other than Astaro.

    I have had both good and bad support experiences with Astaro, with all the bad experiences after the Sophos acquisition.
  • 0
    Thanks, dbye, for your input - glad to know your reseller took care of you while Astaro was fumbling!

    Honestly, I've never found anyone at Astaro that wasn't willing to help, but, I must admit, I never communicate with them via phone; just via MyAstaro and email.  It did take a couple years to figure that out - even for those with Premium/Platinum support.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    When I am taking leave, I notify my customers to contact us via phone if their issue hasn't been looked into. I would highly recommend calling in if your issue has not been looked into in a reasonable time frame.
  • 0
    Update on our cpu usage issue:

    Our reseller advised us to contact Sophos/Astaro directly to open up a support ticket.  I must say that the phone support has been improved greatly!  In the past either my reseller or I would have to wait a minimum of 15 - 45 minutes before getting to a support technician, but now you can get through quite a bit quicker and my recent experience was under 5 minutes.  Thumbs up for this change!

    The root of the issue was with the reporting database being corrupted.  At first they tried to re-index it, but that didn't not solve the problem.  After support completely rebuilt the reporting database our cpu usage dropped.  Our daily average was around 50% with spikes during business hours up to 100% and now it is down to 10% with spikes during business hours up to 50%.

    Support responded to the issue and followed up multiple times to make sure our issue was resolved!
  • 0 in reply to dbye
    thanks for the update!
    looks like we're having exactly the same problem on a 320 active-passive cluster, do you or anybody else know whether this will/can be fixed with 8.301 (todays 8.301 softrelease notes aren't too detailed) or has it just "happened" through the 8.300 update and now can only be fixed manually?
Cookie Information Banner