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.
Dear Steve1 and Larsk,
@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. 
Thanks,
Christian
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.
Is this mechanism the same in OH2?
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
Thanks all,
Christian
I switched to python based rules using the JSR223 scripts extension. Things seemed much faster. YMMV.
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.
Thanks for sharing!
Christian
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)
2 Likes
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
Sorry have found this after searching a lot. 
I am right now not at home and not able to test in detail but following could be a try:
/etc/default/openhab2: EXTRA_JAVA_OPTS="-Xms650m -Xmx650m"These setting should be fine raspebrry pi installation, other platforms may have different values:
these all setting might be of interest:
-Xnoclassgc disable class garbage collection -Xms set initial Java heap size -Xmx set maximum Java heap size -Xss set java thread stack sizeWould be great if someone coukld test this, together with defining a rule for system start event to precompile rules.
Greetings,
Markus
1 Like
Interesting, I’ll add that to openHABian.
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.
- what is the right command to check how much is used right now?
- Is there a way to check what is the maximum size used by openhab in a given timeframe? (or since last reboot of the service)
There’s no command to display that that I’m aware of.
Can these settings be set by a script?
My whole setup is script based, and I prefer to have these changes be available for a new setup in a script. I could copy the whole openhab2 file, yet then that would not be compatible with a future openhab default changes
Be careful with this one. I tried this as a solution to slow rules execution and it made OpenHab start leaking memory and crashing regularly. My guess is some of the bindings (or maybe even the core) are relying on garbage collection in order to not leak memory.