mcsMQTT using 100% CPU forever

[dhod]

I've had this problem before when I was adding a wink relay to Homeseer with mcsMQTT and I ended up having to uninstall, and delete all files related to mcsMQTT and reinstall and reconfigure everything all over again to stop it from using 100% CPU on the homeseer computer.

Now I've just finished installing the wink hub and configuring it as well as 2 sonoff S31 plugs and the homeseer server is using 100% CPU and when i break down the process it shows HSPI_MCSMQTT is using 90-98% CPU constantly.

Any suggestions on debugging this and what would be causing it?

[dhod]

Well I disabled the plugin, restarted HS4, it downloaded a HS4 update, I installed it, and then restarted the mcsMQTT plugin 2-3 more times because the broker failed to connect the first two times but now it seems like the broker has come back up, the cpu usage is now between 0-0.5% and stabilized.

No idea what causes it to sometimes go into a 100% cpu usage cycle until restarted.

If theres some logging I can get or some way to tell whats causing the high cpu usage I can check it next time it happens.

[Michael McSharry]

CPU use is high during initialization to cache everything from the database and HS. If the database is large and/or many devices in HS then this could take a few minutes. After this the primary driver is the number of accesses to HS that are made. The debug log provides a good record of what mcsMQTT is doing over time.

[dhod]

Ok I will monitor then if it happens again. In the past it has been days at 100% cpu that I saw it. Today it was just a few mins I think and I restarted it. Didn't wait it out this time to see if it would stop.

[brientim]

Please see attached powershell script. Change .txt to PS1. This will monitor the HSPI_MCSMQTT process and CPU usage. You can set the threshold (set at 50 in the attached) and if the average CPU usage over 30 seconds exceed the threshold, it will stop and then start the service

[dhod]

Still having a problem with this. it starts taking 100% CPU out of no where after a few days of running. I restart the plugin and it uses 100% cpu for 5+ minutes, i restart it again and back to 1-5% idle usage.

I enabled debug log this time and looked at it so far but see nothing to indicate any issue so far.

I did notice when its restarted and at 100% cpu the statistics tab shows no connection to the broker. disconnecting from the broker and reconnecting still doesnt reconnect it to the broker. restarting the plugin again got the broker up and running and cpu use went down and statistics tab showed a connection to the broker and topics coming in.

[Michael McSharry]

If you provide the debug via post or email to mcsSolutions at CenturyTel dot net then there may be something there that I will recognize that is not obvious to others.

[Richel]

Still having a problem with this. it starts taking 100% CPU out of no where after a few days of running. I restart the plugin and it uses 100% cpu for 5+ minutes, i restart it again and back to 1-5% idle usage.

I enabled debug log this time and looked at it so far but see nothing to indicate any issue so far.

I did notice when its restarted and at 100% cpu the statistics tab shows no connection to the broker. disconnecting from the broker and reconnecting still doesnt reconnect it to the broker. restarting the plugin again got the broker up and running and cpu use went down and statistics tab showed a connection to the broker and topics coming in.

I see this thread has gone cold, so I guess others are not having an issue. I was trying to figure out why I was having very high load for HS4 and, so, I systematically disabled and re-enabled plugins. When I disabled mcsMQTT version 5.15.11.0, load came down on the "About" page and the Windows performance monitor showed HS4 using less CPU and power. The reverse occurred when I re-enabled the plugin. Are there any settings that I can disable within the plugin to improve performance? I really like this plugin and want to keep using it. Thanks. Elliott

[Michael McSharry]

The plugin does many things so it depends upon what you are doing with it. A good place to start is with the plugin's debug file (enabled from General tab, top) at \data\mcsMQTT\mcsMQTT Debug.txt to see what repeated activity is occurring.

CPU use will be high during initialization. You can disable MQTT traffic by disconnecting from broker on General tab checkbox as a diagnostic. Beyond this there needs to be more visibility into what you the plugin doing.

[Richel]

The plugin does many things so it depends upon what you are doing with it. A good place to start is with the plugin's debug file (enabled from General tab, top) at \data\mcsMQTT\mcsMQTT Debug.txt to see what repeated activity is occurring.

CPU use will be high during initialization. You can disable MQTT traffic by disconnecting from broker on General tab checkbox as a diagnostic. Beyond this there needs to be more visibility into what you the plugin doing.

Michael: Thanks for the quick response. I will get a debug file for you. Presently, I am only using Voice Monkey and BLE. If I disconnect from broker, will this affect any of these functions (my guess is "no")? Elliott

[Richel]

Michael: Thanks for the quick response. I will get a debug file for you. Presently, I am only using Voice Monkey and BLE. If I disconnect from broker, will this affect any of these functions (my guess is "no")? Elliott

So, the functionality (Voice Monkey and BLE) is not affected by disconnecting from the broker. However, neither is the CPU usage. Debug file to follow.

[Richel]

Attached is the debug file. Disconnecting the broker didn't seem to make any difference, so toward the end of the file, is where I reconnected it. I hope this helps.

[Michael McSharry]

Nothing much in the debug. Individually remove the setup of the two functions you are using. Restart plugin each time.

Voice Monkey is pretty beneign with no recurring activity. BLE is servicing callbacks from the OS so has the potential to be busy. At one time I had debug for it, but likely removed as the function has been released fir awhile.

The setup for mcsMQTT is in config\mcsMQTT.ini. If you rename this file when the plugin is disabled then the CPU should approach 0. I suggest doing this first to confirm that it can idle without issue.

[Richel]

Nothing much in the debug. Individually remove the setup of the two functions you are using. Restart plugin each time.

Voice Monkey is pretty beneign with no recurring activity. BLE is servicing callbacks from the OS so has the potential to be busy. At one time I had debug for it, but likely removed as the function has been released fir awhile.

The setup for mcsMQTT is in config\mcsMQTT.ini. If you rename this file when the plugin is disabled then the CPU should approach 0. I suggest doing this first to confirm that it can idle without issue.

Michael: With the new .ini file, it doesn't get quite to zero, but the load generally stays low. Adding back Voice Monkey, it stays low most of the time. Adding back BLE, it goes to 100% and stays there for a long time. Take a look at this new debug file. In BLE I have to select the middle button shown, because when I select the top button, my already discovered and associated devices are not detected when in range:

The debug file was obtained with the setting as shown. So, it is capturing everything around the receiver. Might this cause the increase in load?

[Michael McSharry]

You are getting about 30 beacon updates per second from Windows including multiple reports of the same beacon in this one second.

The likely reason you are not seeing updates with the radio in the top position is because of the CPU backlog caused by trying to add all the new beacons. These are likely smartphones etc. that randomize their MAC address for security so they cannot be used for tracking location.

If you look at the MQTT Page Association tab there will be a large number of beacons shown. There should only be a couple beacons that you are actually tracking. These should be Associated with HS devices. All the other beacons should be obsoleted so mcsMQTT does not need to carry the overhead of managing them. Of course the radio should remain in the middle position so the existing ones will be tracked.

I can look tomorrow about the efficiency of the code that services each advertisement report from Windows.