Has anyone been noticing the Physical Memory and Virtual Memory for HSPI_JowiHue.exe increasing at an alarming rate? I setup a process monitor using Jon00's plugin to track this. Attached is a screen shot of HSPI_JowiHue.exe after 14 hours. The Plugin starts in the mid-30's and high-40's respectively and has climbed to over 200MB in that time frame. This graph is with a RaspBee using deCONZ and 4 ZigBee devices. The plugin works fine and all the devices perform as expected. There are no anomalies in the logs.
I originally started with a Philips Hue Bridge with polling at 2 second intervals and the memory consumption was even higher (>600MB). CPU utilization was >40%. I then changed the polling frequency to 300 seconds (5 minutes) and the rate of increase dropped significantly (as did CPU utilization), but it was continuing to increase. It took about 4 days to get to ~200MB. That is what prompted me to try a RaspBee/deCONZ solution.
Best as I can tell is that something that happens during polling is causing more memory to be consumed and then not being released when the polling is complete. And the more frequent the polling, the greater the rate of increase. All the while the plugin is working fine, the devices respond appropriately and there are no anomalies in the log files.
Disabling and then re-enabling the plugin frees up all the memory but the cycle begins again once polling starts. To prevent the system from running out of memory, I setup an Event to disable and re-enable the JowiHue plugin once every 24 hours.
I'd be curious if anyone else is seeing this and what, if anything, they have learned and are doing about it.
Thanks,
Craig
I originally started with a Philips Hue Bridge with polling at 2 second intervals and the memory consumption was even higher (>600MB). CPU utilization was >40%. I then changed the polling frequency to 300 seconds (5 minutes) and the rate of increase dropped significantly (as did CPU utilization), but it was continuing to increase. It took about 4 days to get to ~200MB. That is what prompted me to try a RaspBee/deCONZ solution.
Best as I can tell is that something that happens during polling is causing more memory to be consumed and then not being released when the polling is complete. And the more frequent the polling, the greater the rate of increase. All the while the plugin is working fine, the devices respond appropriately and there are no anomalies in the log files.
Disabling and then re-enabling the plugin frees up all the memory but the cycle begins again once polling starts. To prevent the system from running out of memory, I setup an Event to disable and re-enable the JowiHue plugin once every 24 hours.
I'd be curious if anyone else is seeing this and what, if anything, they have learned and are doing about it.
Thanks,
Craig
Comment