I have one rule file, roughly 5 designer pages long. Those rules are mainly about light switches and lights. The basic priciple in all of them is:
MQTT message feeds switch item
Item update triggers rule
rule executes postUpdate commands to send MQTT messages to the lights
Let’s say, I have just started OPENHAB and the server is running for 10 minutes (everything is loaded, all should run smooth). I trigger f.ex. the sleeping room switch. The following happens:
switch is triggered, I can directly see the MQTT message
OPENHAB processes the information
2-5 sec later: first light MQTT message arrives
2-5 sec later: second light MQTT message arrives
2-5 sec later: third light MQTT message arrives
I now toggle the switch wait a little bit and trigger it again:
switch is triggered, I can directly see the MQTT message
OPENHAB processes the information
minimal time later: all light MQTT message arrives
This happens for all rules. I am using Mosquitto as an MQTT server and a Cubietruck board as hardware for OPENHAB and mosquitto.
My guess is that some (maybe most) of the delay is related to Java class loading, “just in time” (JIT) compilation and possibly some garbage collection (in decreasing order of suspected impact). The first time a specific execution path is exercised in Java it will trigger class loading for Java classes that haven’t already been loaded. Depending on the scenario, that could easily be hundreds of classes. After the classes are loaded, they are compiled to native instructions using JIT compilation. This can also require a significant amount of CPU cycles and wall clock time.
The class loading and JIT compilation is only (well, mostly, for JIT) done the first time an execution path is exercised in the code.
Do you have any startup rules that can “warm up” the execution path? Ideally it would not only execute a rule but do something with the bindings that will be used by the rules.
Is it in your case just the first time slow, or does the effect reoccur after some time?
I did have a similar issue with a complex voice rule. But there the effect was reoccurring after some time of not using the rule.
@Steve: I can think of such a rule at system start. But: When I recap the post of LarsK, it seems that all those classes are unloaded at some point, since after some time (>30 minutes perhaps) the same effect takes place.
In addition: When I am in room A, toggling a switch as described, it works fluent after some waiting (== to your startup rule idea). When I then go to room B and toggle a switch, I have the same delay effect as in room a.
Is there a mechanism that unloads classes/functions/rules if a certain system load is immanent (I have jumping CPU loads from 24 to 109% when idle while using 9% of RAM)?
Will more computing power help? The WAF is already low, and I only used OPENHAB for one floor.
Hmm, that’s interesting. Java wouldn’t unload classes except in very special circumstances. Virtual memory thrashing can cause performance patterns like you describe but if you are only using 9% of RAM then that doesn’t sounds like a likely cause either.FWIW, I have some rule-based scenes that control several lights over multiple protocols (Insteon, HTTP->ESP8266, HTTP->Hue/Zigbee) and it hasn’t been a problem. I’m running on an RPi 2 B.
To see what performance does, I removed my debugging Item files for my room clients (roughly 350 items that were bound to MQTT topics). The system is a lot less laggy and CPU is down to 18-31% Whereas MEM is at 8,1%.
I triggered all switches today until they were responsive, tomorrow I’ll see how these behave after a significant idle time.
I’m not 100% sure but I assume that the rules are evaluated just as xtend, which means that the xtend sources are first translated to java source code and then compiled to java byte code. This takes several seconds, depending on the hardware. Executing java byte code is pretty fast, but if the rules are changed, the byte code must be re-compiled first. I think this is done on first rule access. This would explain your observations, and I also experienced this bahavior.
as promised, I just toggled the switches with no changes to OH. The rules are executed as fast as yesterday. So trusting both your knowledge steve1 and paphko, I conclude:
The first slow execution of the rule is unavoidable and has to do with the compilation of the rule to something java can execute quickly
If there are performance issues later, they have to do with:
comupting power limitations (as in my case)
alternation of the rule which makes recompiling necessary
Well, I’ll give it a shot if necessary. We’ll see what happens when the full house is automated and more computing power is availabe. Might be an option to be considered at the end.
Well.
This sounds like the issue I had as well. The java environment seems to keep the memory usage per application to something around 20%. I guess to make sure other java application do have enough free memory as well.
But as in my case openHAB is the only java application permanently running, there is no reason to keep the usage so low…
Look here where I tried to explain my finding (on my Raspi 2)
Hi Lars.
Your solution to prevent the first time slow execution of rules after restart system sounds very nice.
Can i use this in OH 2.3? Can’t find the start.sh. OH2.3 is running on a Ubuntu System with a Intel Nuc.
Greetings,
Markus
Do think though that 650M is too much. Results in a peak process size of 1000MB on my Pi, but we still do need some RAM beyond Java for example for tmpfs on /tmp and further programs such as databases, mosquitto and the like.
Those 650M would also immediately trigger swapping which you should avoid as well as it’ll also slow down the Pi, and it aggravates SD corruption, too, at least for common Raspbian setups.
Hi Markus.
i am using a Intel Nuc with 8GB RAM. So i hope this should not be the problem. Is there a config for stronger server than a pi?
But my problem started after changing some rules. And i doen’t know what i have changed, after i recognised the problem.
One thing is that i have two rules wich both are triggered through the same group-item by “received command”. Before, it was on the one side “received command” and on the other side “changed to”.
Could this be the problem of lazy rules?
Greetings,
Markus
Then you should easily be able to pre-allocate 650M or even more.
On that rest of your post, please open a new thread as that’s unrelated to this one (and before you do: noone will be able to answer a question as generic as yours so I suggest to do some more investigations first and give details).
Okay. Thank you.
I will start a new thread.
But it was a generic question. Is it possible or not that i can start 2 rules by the same time with the same trigger Group-item. And i only wrote it because this are the rules which gives the same problems , like above in this thread.
Thanks for your help,
Markus
Your question does not make sense.
Either it’s the time that triggers a rule’s execution, or it’s an item to update/change/receive command. It’s never 2 conditions to match at the same time.
