EricHigdon / OctoPrint-RGB_status

Adds RGB LED support to OctoPrint with the ability to choose effects based on the current status of your printer
33 stars 12 forks source link

Constant 40% CPU Load when Plugin is running while OP is idle #59

Open redeye86 opened 4 years ago

redeye86 commented 4 years ago

Hi,

I recently upgraded to octoprint 1.4 and do not know if the problem existed before, but on my raspberry pi 3 I see a relatively constant cpu usage of around 40% for one sub-process when octoprint is running (printer not connected and not even powered).

I straced this process and I think I see repeated polling of the system clock

clock_gettime(CLOCK_MONOTONIC_RAW, {tv_sec=264694, tv_nsec=40990121}) = 0 poll([{fd=31, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC_RAW, {tv_sec=264694, tv_nsec=43771423}) = 0 ioctl(29, SPI_IOC_MESSAGE(32), 0x716fcf88) = 744 clock_gettime(CLOCK_MONOTONIC_RAW, {tv_sec=264694, tv_nsec=46912621}) = 0 poll([{fd=31, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout) clock_gettime(CLOCK_MONOTONIC_RAW, {tv_sec=264694, tv_nsec=49997360}) = 0 ioctl(29, SPI_IOC_MESSAGE(32), 0x716fcf88) = 744

I remembered that there are some frequency related settings required for this plugin. So I disabled it and I no longer see this process. Unfortunately I do not see anything else in the logs so my report is a bit vague. But at least maybe others can confirm that behaviour? Is it normal?

dd871 commented 4 years ago

I can see exactly the same behaviour and had to unfortunately disable the plugin completely.

@EricHigdon, would you know if there is anything I can try to avoid the high cpu usage in idle? I suppose this should not be normal behaviour?

EricHigdon commented 4 years ago

Can you share some details about your setup? How many leds do you have, what effect is running, at what speed when you see this?

dd871 commented 4 years ago

Thanks for the quick reply and also let me say that your plugin is really fantastic and has all the features I was looking for.

My setup is: 20 leds, connected via BCM pin 10 (MOSI). All plugin settings pretty much at the default value. SPI etc. is enabled.

I tested it a bit more and it is actually really strange, the moment the plugin is 'active' in the plugin manager, the CPU goes crazy. Even if at idle (solid color) or not even connected to the printer (no color / no light). Also, if I use the RGB icon in Octoprint to switch off, it stays at the same high CPU usage.

I tested it with the Adafruit python library separately, there I only see spikes if I use heavy effects like the rainbow, solid colors are negligible in terms of CPU usage.

dd871 commented 4 years ago

Not sure if it helps, but the only real error I can find anywhere in logs is from journalctl, related to 'queues':

Jun 21 11:49:00 octopi octoprint[32718]: 2020-06-21 11:49:00,342 - octoprint.plugins.rgb_status - INFO - flipswitch command called
Jun 21 11:49:00 octopi octoprint[32718]: 2020-06-21 11:49:00,365 - octoprint.plugins.rgb_status - INFO - Starting Idle Effect
Jun 21 11:49:00 octopi octoprint[32718]: 2020-06-21 11:49:00,397 - octoprint.plugins.rgb_status - INFO - Putting KILL code in queue
Jun 21 11:49:00 octopi octoprint[32718]: Traceback (most recent call last):
Jun 21 11:49:00 octopi octoprint[32718]:   File "/usr/lib/python2.7/multiprocessing/queues.py", line 268, in _feed
Jun 21 11:49:00 octopi octoprint[32718]: 2020-06-21 11:49:00,420 - octoprint.plugins.rgb_status - INFO - Joining Effect process
Jun 21 11:49:00 octopi octoprint[32718]:     send(obj)
Jun 21 11:49:00 octopi octoprint[32718]: IOError: [Errno 32] Broken pipe
Jun 21 11:49:00 octopi octoprint[32718]: 2020-06-21 11:49:00,475 - octoprint.plugins.rgb_status - INFO - Killed effect: Solid Color
Jun 21 11:49:00 octopi octoprint[32718]: 2020-06-21 11:49:00,499 - octoprint.plugins.rgb_status - INFO - Starting new effect Solid Color
Jun 21 11:49:00 octopi octoprint[32718]: 2020-06-21 11:49:00,535 - octoprint.plugins.rgb_status - INFO - Started new effect <Process(Solid Color, start
dd871 commented 4 years ago

I was able to fix the above IOError by adding a short sleep into your code after the update to the queue (relevant code snippet below - based on https://stackoverflow.com/questions/10607553/python-multiprocessing-queue-what-to-do-when-the-receiving-process-quits).

Unfortunately, this did not resolve the issue. As I am not seeing any other errors I am probably giving up now and will try to find a different plugin (or code a very simplified version myself).

                self._logger.info('Putting KILL code in queue')
                self._queue.put('KILL')
    ++  time.sleep(0.01)