My Openhab system is getting rather large and I’d like to allocate more resources to it. After startup, using top, the Java process sits at around 100% cpu usage, but that is only on one of the 4 cores, it also is pretty unresponsive for the first 5 minutes or so, and I have to copy the rule files in with 45 second gaps to avoid stack dumps. Once it eventually settles cpu sits around 5-15% suggesting it’s only a starting problem.
Is there any way of getting Java / Openhab to use more cpu cores or allocate more memory to it?
That seems strange that startup is so resource intensive. Is there any point in looking specifically at your addons, rules and other configuration for possible optimizations? It doesn’t seem right that the CPU is under such load for minutes after startup. Which Java are you using?
java -version
java version "1.7.0_60"
Java™ SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot™ Client VM (build 24.60-b09, mixed mode)
I’m really pushing it with the amount of rules and items.
I’ve recently added another 98 setpoint items plus rules to combine them into string items, and this is likely the problem, Although I do copy that rule in last of all.
It may be that I have to move a lot of the rules to my second Pi which is running openhab and slaved off the first using MQTT, but as it seems to work OK once its settled I wonder if I can just give it more resources to use. I’m running a pi3 so it should have plenty of power
According to top the memory is
KiB Mem: 948016 total, 530880 used, 417136 free, 6412 buffers
I wonder if Java/openhab has its memory / cpu cores restricted
Any interest in upgrading to Oracle Java 1.8 to see what the impact is on performance? This is on my Pi2:
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) Client VM (build 25.0-b70, mixed mode)
Done, now sporting
java version "1.8.0_65"
Java™ SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot™ Client VM (build 25.65-b01, mixed mode)
I discovered a slight unintentional bug in my startup rule which I corrected, then I did some detailed before and after tests. Loading my large “populate setpoint items from string on startup” rule gave the following.
V 1.7 and rule took 34.2 seconds
V 1.8 and rule took 31 seconds
Crucially under Java V1.8 the CPU occasionally peaks at 200% suggesting its using 2 of the 4 cores, now openhab seems to continue to run whilst that one rule is hogging one of the cores which is a big improvement on startup when it was unresponsive on Java V1.7.
Once everything is loaded, CPU is sat at around 15% and memory is sat at around 13.5%, so it looks like my many items aren’t taxing the Pi3 that much.
I wonder how I can tell Java / Openhab to use all 4 cores?
Assuming there is no bug, Java will run threads on available cores without you having to configure anything. Code has to be written to maximize the benefits of concurrent execution, however. Here is a book about it.
1 Like
I have been seeing the same type of problem for a long time. Startup is serialized to 1 CPU core. Loads one rule after another, and the items next, that altogether being the major reason why it’s taking so long.
Already-loaded rules are executed meanwhile, java CPU usage increasing to somewhere between 100 and 200 percent.
The most annoying “non-parallelization” impact actually is that while parsing rules, the UI is blocked, that’s why button presses can take a minute to have effect (until the current load/parse rule operation finishes) just because you used to change a rule.
So @watou, are you sure there’s nothing that can be tuned ?
2 Likes