OH restarts every day. That doesn’t help. Also cache was deleted but never changed anything. I’m not sure about the 100 processes. I have 177 Things and over 600 Items. It could be that every thing has an own process but not sure.
Many thanks, today morning the CPU usage is normal. I will check it today every hour to figure out what the reason can be. I guess that something loops.
Now an update : it’s really not easy to figure out. Today the CPU Load is by 100 % for one CPU. After restart the service it works normal. To figure out I add an item for the CPU load and add it for the persistence group too. I’m not sure if it works and how but I hope that this allows to check the logs in the time after CPU load increase.
One problem what I have : there are a lot of Java processes but no ID to the whatever … item, rules, trigger, … for further version of OH it would help if there is a id which allow a conclusion for whta it is.
Assuming you’re on a local network and you have a Windows laptop you can try to add visualvm (included in jdk downloads) to the openhab Java process. That shows more detailed information.
I have a question about this. Is this a migrated installation from Buster to Bullseye ?
In case it is was that a 32 bit Buster installation ?
In case it was what is the output of command: uname -a after this migration ?
Actual it works for me. I figure out that I have a binding thats not compatible to OH 4 (in this case it was installed manually by myself). After I removed it the high CPU load was gone.
In my case is an upgrade, I am using a mini PC with Windows 10.
I have shutdown OH 3.4.4, installed Zulu Java 17, uninstalled Java 11 and perform a update of OH using command line bat (as I have done all.other times and upgrades).
Ruben
Edited: cache and temp folders cleared after first reboot, because I have problems after that (not before reboot). From then all is working correctly except for the high CPU usage. I have changed the 3 transformations that I use from JS to DSL inline, so don’t have to use JS binding.
Last update: After 36 hours and without any new intervention, CPU usage has been lowered to levels only a bit more than before 4.0.1. I don’t know what happened.
Have you seen this thread? There is a work around being tested, that link is the post with instructions to install patch. Report your issue in that thread or on git hub issue
Thanks so much I have tested and I reporting on the thread, it seems that is solved… I need a little more time to see that the results are consistents, but looks ok!