Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 24 replies
  • Subscribers 2 subscribers
  • Views 6687 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
    If you do have corruption already in your reporting database, an up2date won't be able to fix it.  The steps to the process are quite simple to perform though on a standalone system.  https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/p/33301/112080#112080.

    @Admin Öpag:  It would be more involved if using HA as it would need to be done on both nodes, or you would would to do a factory reset on the passive node and rejoin it.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
  • 0
    If you're having the same problem, the only solution is to have Astaro Support re-initialize your Reporting databases.  Look at the list of Archived System Messages logs and see if they didn't become large when this problem started.  If so, then I bet postgres is registering lots of complaints.

    Cheers - Bob
    PS I don't think Scott's recommending that you do this yourself.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Bob,

    In our case the re-initialization of the Reporting database did not fix it and they had to rebuild the Reporting database.  The good news is that the logs are still intact, and the bad is that all Reporting data is gone after the rebuild.  If you need older reports you will have to pull the data from the logs manually and create reports yourself according to Astaro Support.
  • 0
    so here's how the story ended:

    in the end astaro support wanted to install 3.0.1 as it should fix my errors. Due to some circumstances [:@] I was able/had to install the update through the official up2date mechanism.

    -> everything is working again as it should! [:)]

    ng, Berndt
Cookie Information Banner