Extremely high CPU usage after upgrade

[mbowden]

I upgraded to the latest Nagiosxi yesterday and noticed a pretty big delay when applying configuration. This morning the machine continued to be taxed with top readings of 100+ I was then presented with the following screen;
Message: A database connection error has been detected, we are attempting to repair the server, if the repair does not resolve the issue, please contact Nagios support.

Run the following from the CLI as root to attempt to repair the DB

/usr/local/nagiosxi/scripts/repair_databases.sh

SQL: SQL Error [nagiosxi] : Database connection failed SQL: SQL Error [nagiosxi] : Database connection failed SQL: SQL Error [nagiosxi] : Database connection failedMessage: A database connection error has been detected, we are attempting to repair the server, if the repair does not resolve the issue, please contact Nagios support.

Run the following from the CLI as root to attempt to repair the DB

/usr/local/nagiosxi/scripts/repair_databases.sh

I ran the command and the box is so CPU bound at this point its useless. The machine functioned appropriately prior to the upgrade, no additional monitors have been added.

RHEL 5.7

[tmcdonald]

What version were you running prior to the upgrade?

If you're still able to use the interface, go to Configure -> Core Config Manager, then on the left under Tools click Write Config Files. Then click Delete, then Write, then Verify and post a screenshot.

[mbowden]

I will get your other screen shot momentarily, I thought I would share this one first

[mbowden]

And the find processes still keep coming

[mbowden]

requested screen shot, 16 find processes running now

[mbowden]

ok last find screenshot

[tgriep]

Can you run the following in a shell and post the output so we can see what the find command is running?

Code: Select all

ps aux --cols=300 |grep find

[mbowden]

I apologize about the delay in responding, The box basically continued spinning up find processes until it crashed. I rebooted and a minute or 2 later there was a single find process, then another..

[mbowden]

wrong screen shot

[mbowden]

The perfdata directory its looking at is 32G not sure if that is relevant or not

We don't necessarily care about the historical perfdata if that is the issue, we could dump it and start collecting data moving forward.