I should not have to go through 150 devices and almost 100 automations, considering everything was fine before the update. I noticed in the update notes that was "performance and stability improvements" but there was no details. This really doesn't help when trying to diagnose issues that may be related to those changes.
I would prefer more details too.
However, if it is all back end database stuff (which I expect it is) there isn't really any user troubleshooting that can be done anyway. You can't see the H2 database structure, queries, or maintenance tasks.
So all you can really do is report the regression, and live with it or roll back to 2.2.2 - which is what you did.
I just wonder what it is about this update that has made some hubs so much faster, but apparently is causing serious problems for others. I haven’t rebooted since the .118 update I did on the 13th and my Watchdog times have remained between 0.05 & 0.08. I shut off my reboot rule, which otherwise would have run Sunday morning. I know it’s premature to say this has eliminated the slowdown issue, but I’m feeling pretty hopeful after almost 4 days.
Don't know.
My hubs (all 4) are blazingly fast on 2.2.3... But I know/acknowledge that I am not a "representative" user, as I have almost zero apps and basically no logic in the hub at all.
Mine should all be fast - always. lol. They are essentially only doing "z" devices and maker api.
I'm running a C5 and after the update my bench tests show a 37% improvement in command execution. I used to reboot the hub every three days because of performance drop off. If I didn't reboot by day five performance would be at a near standstill. I am on day four and performance is still blazing fast. If the hub can make it a week without rebooting I'll declare my hub slowdown issues resolved. Fingers crossed.
What’s funny (strange, not haha), is that the faster of my 2 hubs has always been the one with most of the rules, and all of the end-devices. The one with all the zigbee bulbs, zwave plus dimmers, and very few rules, is also the one that needs rebooted twice a week. They actually have a similar number of devices.
Can you give us a general idea of what your load is?
My guess would be the zigbee bulbs...
Smart bulbs are the devil (my opinion).
+1
My setup consists of 26 zwave, 57 zigbee and 11 virtual devices.
List of Apps; (If it isn't listed, its not installed)
Device Watchdog
Hubitat Package Manager
Hubitat Dashboard (with 5 dashboards)
Maker API (used by Node-Red)
NOAA Weather Alerts
Tile Master 2
webCoRE with 94 pistons
My system is pretty active with a lot of SmartThings multi-sensors chattering their temperatures and threeAxis (vibration). I have a Lux sensor that updates once per minute and four outdoor motion detectors that sometimes go nuts depending on the sun angle. I make a fair amount of http GETs collecting weather data from my PWS every minute and wunderground every 15 minutes. Other HTTP GETs are used to determine if the hub is connected to the internet.
Overall I don't think I'm pounding the crap out of my hub but it is probably busier than most.
@raidflex - Are you using the Node-RED to InfluxDB performance monitor flow? I believe this tracks the load time of the Apps page, correct?
I have the same/similar Node-RED flow collecting data on my hubs and I have also noticed a significant increase in variability of the load times of the Apps page. However, nowhere near the times your graph shows.
Even with this increased in response time, my automations seem to be running smoothly and quickly. If they sacrificed UI performance in favor of automation performance, I'd be alright with that trade-off.
Are you seeing automation performance negative impacts as well as UI impacts?
Here is what my hubs used to look like
And here is what 2.2.3.119 looks like today
That’s my experience as well. Actually I’ve removed all my Z-wave and almost all Zigbee devices and went with Shelly WiFi instead. Haven’t had a slowdown in weeks after that and the web UI is faster then ever. Currently on 2.2.2 but I it’s been rock solid on earlier releases ever since I made that move.
This is correct, that is what I am using.
I noticed slow downs with my automation's after the update and that was when I looked into the issue further and and checked my graphs to find these very erratic response times.
I suspect its something with Z-Wave or Zigbee, but I have nothing noticeable in my logs. The problem is I need somewhere to start, I can't be bothered by blindly going through every single device/app to find the problem and I don't think I should have to.
I had a lot of issues. My hub was crawling. Had to roll back.
I am curious if anyone with a C7 hub is experiencing issues. I know there were many changes to the C7 and I wonder if one of the changes is causing issues on the older hardware, in my case I have a C4.
The cleanup job now runs at low priority. To think of it, backup job should, too.
To sum it up, here's the big picture that emerges:
- Users with relatively large database experience slowdown when moving to 2.2.3.
- There impact seems to be more pronounced for users with C4 hubs, although it could also be that C4 users have more devices/app/rules/whatever.
And these are changes I'm thinking of in response:
- Do a database cleanup on hub startup. This means 1-2 minute extra on the first startup of 2.2.3. But 2.2.3 doesn't like to deal with a large number of events/states, much more so than 2.2.2.
- Run backup at low priority.
- Give users who care about event history an option to set per device event history policy. This way if someone wants to monitor, say, electricity use on an outside plug, they can keep 2,000 events. Keep default number low - it is good for overall performance.
- Run cleanup more than once a day. This means a few seconds of relative slowdown in exchange for better performance the rest of the time.
Finally, a question. What UI pages are being routinely used or monitored? If we know, we can focus on them.
Mine as well. Wondering if it has something to do with log files growing to large? Even the web ui is much faster now.
Zigbee bulbs make bad repeaters and cause issues.