On my Raspberry Pi’s with either Zulu JVM or Oracle JVM the Java process running OH seems to use 2 of the available 4 cores. Does this scale with extra virtual CPU’s, so for example on an Intel i7 with 4 Cores and 8 threads courtesy of hyper threading, under Linux will OH use 2 or 4 or 8 of the virtual cores? Can it be configured to use more of the available resources?
OH uses as many cores as Java and OS setup allow it to, which is all 4 on a Pi.
You will NOT noticeably benefit from more cores, though, as except for a short period during startup, OH’s performance is not limited by the number of cores but by a single core’s speed, and as I already wrote in another thread, bad performance (if you have it) is no HW issue anyway but a software one that will not go away by exchanging HW.
1 Like
Thanks for the info - my biggest annoyance with OH is reloading rules files takes so long, and changing a single item in an items file takes up to 10 minutes for the system to become usable again, with the CPU sticking at slightly over 100%, Performance when it is stable is fine.
I can mitigate the rules part a little by splitting my many rules into smaller files - I have doubled this to 12 on my main system and 11 on my backend system, but a change to the items means rebooting as its usually quicker.
If I understand correctly, if I change hardware I need to find the highest clocked CPU at the expense of extra cores? Obviously Linux compatibility, stability and storage life are considerations
You shouldn’t be editing rules files ‘live’, that’s the biggest problem. Create a copy, edit it, copy it back only when really done. Yes split rules into multiple files, editing a single one shouldn’t result in too much delay when just that one is processed.
Note there is a bug that locks the UI while processing changed rules, but it’s just the UI, rules in the background are fine.
Now if booting is quicker than reloading, that’s a software issue, too. Open a Github issue for this.
OK, will do some time tests when I have spare time on the reloading issue to see what the actual difference is, and open an issue
@mstormi I’m pretty sure I’ve found at least 1 bug with editing items and not rebooting, but it will be a couple of weeks before I can confirm. Earlier today I edited 3 of my items files, and it caused an average to stop being calculated. I just tried it again, this time editing only one of the items files and it didn’t fail. Then I edited a few others and the average worked, but a lot of my other ON/OFF items were uninitialised, so I had to reboot it anyway to get things back to normal.
To explain the average fault further:
In my default.items I have all my groups defined including one average group
Group:Number:AVG gPoolHeating "Pool Heating Average Temperature"
In another Items File I have
Number PoolHeatingSpirals (gPoolHeating) { mqtt="<[mosquitto:ToEmon/Pool/SpiralsTemp:state:default]" }
Number PoolHeatingShed (gPoolHeating) { mqtt="<[mosquitto:ToEmon/Pool/ShedTemp:state:default]" }
Number PoolHeatingTopDeck (gPoolHeating) { mqtt="<[mosquitto:ToEmon/Pool/TopDeckTemp:state:default]" }
After editing a different item in the last file I found the average stopped working and was set to null. A reboot fixed it
Now first, that’s obviously something unrelated to the original topic. Please stay with that or open a new thread.
Second, you should enable logging Try at least DEBUG on org.openhab.core, org.openhab.model.script.rules, org.openhab.model.script.engine, org.apache.karaf.
You’ll see whenever updating an items file triggers re-processing of rules.
Next, averages cannot be calculated if (I believe) any of a group’s items is still NULL/uninitialized.
Reboot is always a bad idea, this being one of the reasons.
Do you have persistence on all these items in question?
The items in the average update every few seconds via mqtt, and I noticed the problem a long time after editing the files so that shouldn’t have been the problem.
Thanks for the pointers I’ll open a new thread once I have something reproducible.