[2.150][FIXED] High disk/cpu usage

Our ACC installation runs on a VMware ESXi 4 and it has a very high disk usage since we are on 2.2 Beta. CPU seems to be very high too.
It's the same machine as the old ACC was running on.

I've attached screenshots from the vShere Client for disk, CPU, and network. And also a output from top where you can see that accd is causing the high load.

The VM was up for over three days now, and nothing changed. A reboot does not help either.
  • Would it be possible to get access to the ACC via ssh as root? If so please send the login data to acc-support@astaro.com.
  • Can i send the login to the normal support@ address with a remark to forward it to you (because acc-support@ still has no GPG/PGP key)?


    Some more informations:
    In the time of high load, login is not possible. When logged in, it often shows the managed firewalls as offline because of the high load.
  • Hi,

    of course - you are very welcome to forward it via the regular address.

    Seems your problem is related or identical to the one Mario reported on his XEN system. We are currently checking if we can reproduce the issue on an VMware instance of our internal ESX server, but so far we did not have any luck.

    Will keep you posted, thanks for your report and help in this matter.

    Regards,
    Henning
  • OK, sent the mail to support@ . Hope it will be fine because gpg first had a strange error.

    Some news from my system:
    Just about an hour ago, the high load stopped (after ~3 hours of uptime). But, all firewalls are marked as offline now all the time.

    I don't reboot the system now because it may would be interesting for you. You can reboot it if needed, no problem.

    Urs
  • Hi Urs,

    thanks for providing us the opportunity to debug the system.

    The matter is closely related/identical to the one that Mario originally reported.
    Both virtual systems exhibit excessively high disk I/O which is caused by database processes trying to cleanup unused entries for devices which do not support certain features. These processes then collide with the database autovacuum functionality. 

    The final result can be that all ACC backend threads are used up and the system basically enters a vacation-state.

    We took preliminary bugfix actions directly on your ACC regarding the high-load issue. 

    Additionally we fixed an issue which is going to be addressed in the next Up2Date as well, pertaining to duplicate key errors within aggregated reporting.

    Lastly, I took the liberty to adjust the license subscription calculation - fix will also be included in the next Up2Date.

    We would need a bit more time tomorrow to fully investigate one last issue on your ACC. This is related to IPSec VPN deployment. If it is okay with you, we'd like to connect to your ACC again and maybe cause some more downtime.

    Thanks and regards,
    Henning
  • We would need a bit more time tomorrow to fully investigate one last issue on your ACC. This is related to IPSec VPN deployment. If it is okay with you, we'd like to connect to your ACC again and maybe cause some more downtime.

    If it does not affect established IPsec VPN connections, and the downtime only affects ACC, you can do it. But i'm not i the office tomorrow the whole day. So, if something goes wrong, i will have a lot of problems.
  • For generously allowing us to investigate the issue at hand on your precious system and your general assistance we'd like to award two additional points.

    Thanks and regards,
    Henning
  • Hi Urs,

    the issue has been isolated and fixed.

    We can offer to provide a hotfix RPM for the ACC backend or you can wait till the 2.160 Up2Date (scheduled for end of this week).

    Cheers,
    Henning
  • Hi Henning

    I will wait for the regular update.

    Thanks