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

multiple rrdtool high (100%) cpu usage

Since 02:20 this morning 3 seperate systems I look after for friends have shown this problem.

Each is running at 100% CPU load and the FW is slow

After SSH'ing in I found that there are many (20+) instances of rrdtools running.

This problem looks identical to  rrdtool high cpu usage

I have tried what is suggested there which kills the rrdtool task but after a while the instances start again so I have commented out the lines in /etc/crontab.rrd for now

What is the permanent solution to this ?

Jeff



This thread was automatically locked due to age.
Parents
  • Hello Community,

    This is being investigated under NUTM-14089.

    The issue has been identified, and the fixed version has been set for the next release (9.716). No ETA at the moment.

    The current workaround is to change your time zone to "ETC/UTC" (Any other than IST/BST) and reboot your device.

    If the issue persists after this, please open a case with support and mention NUTM-14089 so it can be investigated further.

    Regards,


     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • This is being investigated under NUTM-14089.

    The issue has been identified, and the fixed version has been set for the next release (9.716). No ETA at the moment.

    The current workaround is to change your time zone to "ETC/UTC" (Any other than IST/BST) and reboot your device.

    If the issue persists after this, please open a case with support and mention NUTM-14089 so it can be investigated further.


    Are we any closer to a permanent fix for this please? All that has been mentioned so far are workarounds.

Reply
  • This is being investigated under NUTM-14089.

    The issue has been identified, and the fixed version has been set for the next release (9.716). No ETA at the moment.

    The current workaround is to change your time zone to "ETC/UTC" (Any other than IST/BST) and reboot your device.

    If the issue persists after this, please open a case with support and mention NUTM-14089 so it can be investigated further.


    Are we any closer to a permanent fix for this please? All that has been mentioned so far are workarounds.

Children