How big? Mine was 37MB
That' not very large, although if a device produces a lot of events, it will slow down queries for that device. That's where more cleanup on startup and throughout the day should help.
I see an occasional 5 second delay on my Hub Watchdog virtual switch on one hub, but it’s not something I’ve personally noticed. It seems to always be the same amount of delay, down to the tenth of a second. Is that from cleanup?
They’re only repeating for themselves and have been doing as good of a job as the Hue on the Hue bridge in this regard
Would help if folks would consistently include their hub version w/posts here. E.g.,
'My hub is really slow now."
vs.
"My C7 is really slow now."
1 Like
Keep that question open for comment long enough and the answer will include every UI page. 
My primary ones:
- Log
- Zwave details
- Zwave log
- Zigbee details
- Devices main page
I have a C5 hub and I agree since the latest update, it is running the fastest is has ever done, I did see the backup size is like 5 times smaller so maybe it is storing less data and keeping it fast.
That's just ONE of the changes that have been made over the past couple of months to 'peck away' at the "my hub is slow' set of problems... it happens to be a visible change but then again, for the specific set of users that have had to rewind to v2.2.2, the
think that is quite visible.
Mine are:
- Logs
- Device list
- Device specific
- Dashboard
in that order.
I reported this on another thread but the UI on my C5 'control' hub with the latest firmware locked up. Was able to access via diag and restore to earlier firmware. The only things running on that hub is Alexa, Maker, Lutron, groups and Zigbee/ZWave turned off..
Another C5 updated around the same time is running fine - that one has Zigbee & Zwave on with no Lutron.
Victor,
Quite a while back, someone came up with a Node-RED flow that measures the amount of time it takes to load the http://{hub_IP}/installedapp/list web page, as a sort of external benchmark for hub responsiveness. There are some users, like myself and @raidflex that still use this as a way of evaluating the impact of each new platform version, as well as slow degradation of hub performance over time.
Something seems to have greatly impacted this 'performance monitoring' technique with the last two platform versions, at least for my C-3 and C-4 hubs. I bought a C-7 recently to replaced a failed C-5 which I use as a development hub, so it has almost nothing installed nor running on it.
You can see before and after data from my screenshots in this post above...
1 Like
It sounds like I need to look for the performance hotspots against a C4 before anything else. Will keep you posted.
1 Like
Unless I’m changing or adding something, or having issues, I’m mostly just using Dashboards or Apple Home and that’s not that frequent. Most things are set up to take care of themselves.
Thanks for looking into the issue, if there is anything you need like logs or something I don;t mind helping out.
2 Likes
I have the 'my hub is fast then gets slow after a couple of days' problem; been trying to correlate virtual switch delay progression to my hubs app configuration since last Fall. Found I could make uptime increase an extra day by disabling RM 3 & 4, though disabling newly optimized WebCoRE and RM 2.5 didn't seem to make a difference. Four days is/was the longest I have ever managed since the good old days of C-3 in the early 2018 to early 2019 timeframe when it would stay up at least as long as the interval between firmware releases without needing a reboot.
With 2.2.3 I can't say that my hub is running the fastest it has ever; the minimum HubWatchdog VS delay I had previously observed was .026. With 2.2.3 it's typically .038. Subjectively, however, automations seem to run as quickly as ever, at least once the 34MB database got pruned by the first nightly maintenance.
Like @Ken_Fraleigh I also see periodic delay spikes in the 5.1s range (roughly 1 to 4 times an hour). Unlike previous firmwares which never showed delays exceeding even a half second until a day or two had elapsed, these delays happen even on a freshly booted hub. But I have not yet seen the inevitable progression to double-digit delays which were a predictor of slowdown issues (delayed/failed automations, extreme UI sluggishness, seemingly random groovy and database errors popping up in the log, etc.).
Interesting point about performance and database size. Looking at the sizes of my DB backup archives, in the first three months of my C-3 hub's ownership (Feb-May 2018) its database never exceeded 4MB. A year later (May 2019) with device migration from ST pretty much complete it was around 13MB. In the course of one month, Sept. to October 2019, its size ballooned from 15MB to 27MB; nothing I can recall would account for that huge delta. That's when I began to really notice diminished uptime. My physical device inventory had probably increased by fewer than a dozen devices in the last year, but I certainly added a lot of virtual devices and automations so I'm sure the event subscriptions started hammering the hub a lot harder.
For the record my single hub runs roughly 75 physical devices, 109 shadowed to ST via HubConnect; WebCoRE (107 pistons); 3 LAN devices, 59 virtual, 45 Simple Automation rules and a half dozen each of Motion Lighting and Button Controller instances. Performance has always super until it inevitably falls flat on its face.
So I'm approaching day two of uptime (on 2.2.3.118) since last reboot. If the hub makes it to day four and the measured maximum virtual switch delay never hits double digits, it will be very unusual.
1 Like
I am having the opposite, after 2.2.3.119, my hub seems to be exceptionally slow, even after a reboot. Nothing has changed, other than the update, so I have no idea what to do. My voice commands via alexa seem to fail 70% of the time, and when they do work it is delayed. Moving around the web interface is torture, sometimes dashboards don't even load.
This is on a C4 hub.
I wonder if you rolled back to the 2.2.2 firmware, and restored a backup from before the update, if you could then run http://yourHubIP/hub/advanced/event/limit/100 and try the update after the next nightly maintenance ran. Then you would be starting with a smaller database to begin with. Assuming everything went back to normal after the rollback.
I did revert back to 2.2.2.129 and everything is back to normal. I didn't revert to an older DB restore, I just a version switch via the 8081 maintenance section.
I really think you should be putting such activity as a low priority or background task (although the latter I understand is not possible on the current architecture). The idea that my motion lighting will hiccup time by time while you are running cleanup arbitrarily through the day is somewhat annoying. Motion sensing and lights should be absolutely prioritised on the hub.
5 Likes
Odd no file size reduction upon new version.
I have 3 C5 hubs, 1 crashes nearly every other day (screen shot is not that hub). All three hubs, the logs have remained the same size.
Funny though, my logs are as you can see around 20MB, not the 30-40 some of you where reporting pre 2.2.3.
Should the paring down of the logs take time?
