Hello everyone,
I recently upgraded my system from Debian Bullseye to Bookworm. Since the upgrade, I’ve noticed frequent occurrences of high CPU load.
I should mention that I never monitored the CPU usage through “top” on Bullseye since I didn’t experience any issues back then.
I would appreciate any input on whether others have observed similar behavior after the upgrade, and what steps I could take to identify the root cause.
Thanks in advance!
Especially for openHABian, we do not recommend to do an upgrade but a complete new innstall with backup and resrore of your openHAB config.
We had a lot information in the past, where OS upgrades failed completely.
Here I am again being unclear, sorry! 
That is exactly what I did. 
I did reboot the RPi and for several hours it was like this:
Now we’re back to CPU usage < 200%
I will restart again but rebooting the system two times a day cannot be the solution. 
Hmm, I have the exact oposite…
After the upgrade of openhab to 4.3.x I had some issues with processor load and temperature on a Pi 3B+. Especially Java and Javascript with the change from NashornJS to GraalJS. This mainly solved or got back to acceptable by the changes suggested by #rlkoshak and #mstormi. I don’t remember exactly what I did, but it had something to do with the amount of memory that was allowed to use for Java, before it “restarts” due to out of memory.
I think it’s to be set in $EXTRA_JAVA_OPTS, which is configured in /etc/defauts/openhab.
the setting that works well for me -Xms192m -Xmx384m, but thats for sure because of the only 1GB my Pi3B+ has… On a more modern Pi like a 4 or 5 you want to use more memory for it… I found suggestions here with up to -Xms1024m -Xmx2048m… But on that you may read here in the forum for your specific modell.
Those days I decided to upgrade to bookworm “manually”. The result: processor load and temperature are much lower and everything reacts better and faster…
Steps to do:
Get yourself a proper copy of your running system, that is bootable. You may want to reboot with the old state.
Upgrade openhab to the newest stable with the openhabian-config tool…
Make sure with the tool all the settings you want are applied, especially SMB and permissions.
Also make sure you are using NetworkManager already and not dhcpd anymore… This should be the case, but who knows…
Then I folowed those instructions:
in the section a better way to upgrade…
But be very careful with the “Kernelupgrade”. In general, you don’t need it and the apt upgrade process will give you a suitable kernel anyways. Second this description is lacking the instructions for 32-bit debian with a Pi3B+ as you’d need the kernel7 not the kernel7l as that would be for a Pi4 with 32-bit debian.
So follow the instructions till the sudo mount /boot/firmware… this point is not important for the system to work, but as mstormi’s scripts respekt the new layout of bookworm already, they will fail if you don’t change the mount point. Then skip the steps for firmware and do the reboot…
As u made sure, you use NetworkManager already before you started, you can skip those steps also…
Then you may install btop or not… I like it, but it’s not necessary…
After that and the system is running again, use the openhabian-config tool again and make sure the improvements are all applied (at least the ones you want and especially server mounts and fix permissions)
Last step:
Check your add-ons if they are all installed.
Check your rules, especially the rules created with blockly, by once opening and savng them again… It will autoinform you (at least for blockly) if there is something strange and needs to be fixed… Especially check if they use the newest aviable EMACS which also leads to performance issues, if you use several versions of EMACS. For whatever reason, I had still one rule that was outdated after the upgrade, even I was extremely sure, that I already worked on all scripts long before.
Result:
openhab 4.3.3 on Raspbian Bookworm running much more smoothly than ever before. Especially my CPU Temperatur now stays mainly good below 50°C without the ventilator running. It just runs now somewhere in the night, when I do the daily backups. (Yes I don’t use the automatic setting for the ventilator from Raspbian at 60°C, I use a own script in openhabian to control the ventilator and make sure the CU stays at 50°C).
And on CPU Usage… Before it was 65% with peaks up to 90% and now it’s about 60% with peeks up to 80%… The Pi doing exact the same as before… Just faster… Also the “recompile” of JScripts runs much faster and smoother than before… Before it was pain, to change something, as this “recompile” on the first run took a longlong time, now it still needs some time, but it’s seconds, not minutes anymore… So it’s fun a gain to change something and experiment with it.
And yes be aware to first do a flat copy of your running SD Card to another SD Card before you start!!!
Happy upgrading, without new installing… This is the idea of Linux… Reinstalling from scratch and then restorig some more or less complete backups is the windows way of doing things… And yes this instructions also contain reboots for the ease of doing it… In principle a Linux system should be updateable (except the Kernel and some very core things) without rebooting, if you know which services to stop and restart… But modern linux got to complex to everytime be aware, what to restart, that doing a reboot is sometimes just faster, especially if you do changes to the boot partition… (and makes sure, that you did the settings for boot right, cause it is possible to change things, make them run and on the next boot it will fail, cause it will boot something strange).
OFF-TOPIC:
You may use the scripts from openhabian-config for it… or do it yourself… On Linux I always suggest, read the script provided, try to understand what it does, then try to do exactly that manually and if successful use the script… Or even modify the provided script to your needs… It’s Linux, not some magic… If you like PM me, and I can explain how to use and modify the provided scripts from config with slight modifications to get a rsynced bootable copy of your SD Card every night (and every 6 month a real copy) and a diskdumped image of that backup SD-Card on your NAS… There are some things in it, you have to be aware of it… Like if you have a SD-Card in a USB SD-Card reader that has the same Disk-IDs as the one in the SD-Card slot of the Pi, it may (not necessarily) boot from the internal card, but then mount the external Card, which leads to strange behaviour. So executing the scripts properly is important as they change the ID properly, which is not that easy as you think.
Why dump this second SD-Card to a NAS… As this card is rewritten somehow every night, it will also fail at some point, then you are happy to have a image, that you can just can flash to a factory new SD Card and have a running system at the point of last night or the night before.
Why not dump the internal card directly to the NAS image? During the dump of the internal, at least if you are using zram, openhab is not running during that time. But a rsync is pretty fast (except twice a year). Then dumping the result to the NAS doesn’t interfere with openhab, as it restarts after the rsync and then you can happily do a raw copy of the backup SD-Card without interfering with the operation. Remeber that a rsync may miss something, while a raw copy copies everything.
Hello guys! Any update on the topic?
I have also high CPU load and a not responding frontend. I did also a fresh start with 64bit bookworm and all the stuff with backup and back…
This thread is a bad example for a post with a problem report.
It’s essentially lacking all of the information that anyone capable and willing to help would need at the very least to answer.
This is why there are no answers.
The used hardware is not mentioned. The used image is not named.
The old and the new OH version are not mentioned.
Neither the bindings used nor any other config details were given.
No proper description of the installation process.
No diagnostics whatsoever (to show ongoing I/O, ZRAM usage etc), no possibly relevant log entries. Screenshot instead of text.
RAM shortage is one of the prime reasons and depends on all of these inputs.
If you run a Pi 3 with just 1 GB of memory, you should not be using a 64 bit image.
But since high CPU load is a complex symptom with several potential causes and you want others to help you, you have to be helpful yourself first and provide comprehensive information upfront.
Please go read the official openHABian prerequisites and installation instructions, and check out the requirements on a proper forum post - notably #10 .
Then best practice is to create your own thread, and this time include all the requested information.
I agree!
Luckily this problem seems to have vanished.
Next time I will do better, I promise!
