I noticed a continuously increasing number of tasks when checking the systemctl status of my running OH3.
After restarting the OH service I see an average of 350 tasks plus/minus 10. The number increases day by day somehow at the same time by 25 for the next 24h. The average number remains stable during the day and jumps up again 24h later.
There are no rules running at the time when the jump happens.
When the average number of tasks is >2000 after some weeks I notice longer scripts in rules becoming slowly.
I run 90 things, 760 items, 190 rules. I use timers instead of “thread::sleep” and avoid cron rules running at the same time.
No error messages show up in the OH and system logs.
Restarting the OH service solves the issue for the next round.
What does the RAM look like when the scripts and rules start to run slowly?
No ideas here to the root cause but there are some memory leaks and the like that have been found and fixed in 4.0, 4.1 and in 4.2 so far. Any one of these fixes might be related to what you are seeing. If not and the problem persists in 4.2, any fix for it will at best be back ported to 4.1 if it gets back ported at all. So no matter what, you’ll need to upgrade to see if it’s still a problem and if so to get a fix.
Short of that, all I can recommend is disabling rules one by one to see if that’s a cause for the growth and/or removing add-ons one-by-one to see if one of those is the cause.
as previous statement you can eliminate things and rules one by one but that will be daunting for sure given the number of things and rules and items you have in your instance. Or if as you say it occurs at exactly the same time every day look at what environmental changes happen at that time. Doors open lights turn on or anything that you know always happen repeatedly on a daily basis. also, would be good to know if that 24 hour reoccurrence time changes if restart your Rpi meaning it was happening at 8:30 am every day before but today you restart at 11:30 am now it happens at 11:30 daily. If it is a memory leak and the leak is related to a device changing state or some rule that runs and never exits, then the first day after the restart you will likely see a change in the pattern.
Other option would be load it up in eclipse or enable something like JMC and do a flight recorder session to see what exactly those new 25 tasks that start actually are.
Regardless some debugging will need to happen. Also, since looking at your previous posts and history you may be seeing unexpected behaviors based on your work around with shelly devices so do not discount the fact you are forcing some devices to be seen as other device types. Question everything ignore nothing and be sure you look under every rock. I even sorta recall a lot of chatter recent past around shelly devices and some kind of firmware hiccup that was inducing weirdness with session closing or something along the lines of a memory leak /abandoned session. so look there as well.
The “workaround” shelly devices can be moved to MQTT to disable them from the binding.
I recently added some devices via MQTT broker but I wouldn’t expect trouble to come from there. MQTT is supposed to be a rather simple way to link items, isn’t it?
Before winter I also added some Shelly TRV controlling my heating system. It could be coming from them. It was a bit “tricky” to get them up and running as I wanted it, I guess due to the battery power saving behaviour.
I didn’t observe the number of tasks in the past but I’d swear it was always about 500 before adding the TRV. I can temporary disable the TRV soon. For the moment I’d like to have it warm here…
