in version 4.2.0 there has been a new executor added, which will lower the number of threads for the rule engine. But this has been disabled by default to have a chance of testing before enabling this for a wide range of users.
Enabling the new executor will use a pool of threads instead of one thread per rule. This might significant reduce the number of idling threads and less memory consumption, depending on the number of rules.
The executor can be enabled by adding these lines to the /etc/openhab/services/runtime.cfg file:
org.openhab.threadpool:events=3
org.openhab.threadpool:rules=6
This will set the minimal pool size for events to 3 and for rules to 6, i am currently running this with ~ 40 rules and ~ 100 items in my local installation without any problems. This is only the minimal number of threads to keep in the pool, if more threads are needed they will be automatically started and timeout later.
Would be great if somebody could give it a try too and keep an eye on these points:
are rules and events running promptly, without a delay?
does the total number of threads reduce?
does the total number of memory reduce?
If you have any issues or everything is working fine, a small reply would be great with the number of rules / items you have and what your overall experience is.
I had read about that and appreciate your efforts.
However, and sorry to be frank about that, I have not understood what that is good for.
What’s wrong with an idling thread ? A thread (!= process) AFAIK by definition means it’s just another instance to share and execute code that all threads have in common so unless activated/run and filled with working data that differs from the other threads, it should not cost any memory.
The risk of reducing thread numbers meanwhile is quite obvious, so I wonder what the benefit is that makes it worth go for this.
You are right this will not save a lot memory on heap, but some native memory should get released. e.g. the size of the stack for each thread. Enabling this might help small boxes to not hit " /proc/sys/kernel/threads-max.
I got java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits on my pi (3a+, 64bit) as soon as i was trying to use the zigbee binding. When looking into this i found some threads that could be avoided, e.g. PR #3874, PR #3884, PR #4136.
But i still had to increase /proc/sys/kernel/threads-max, due to the number of rules i had in the past. This can now be avoided when the thread pool based executor is enabled.
PS: the new executor can be disabled by setting the config to 0
org.openhab.threadpool:events=0
org.openhab.threadpool:rules=0
All my entries in the /etc/openhab/services/runtime.cfg file are commented out.
Is this normal?
When I want to test the “new executor”, whre can I check if this is active?
BR
