Could it be? 2.2.2.125 Fixed the slowdown problem?

That sort of eliminates the use of panels, of which i have 3.

Lee

I don't know if the database size is related to slowdowns,
but my database is 11.7MB with 94 devices and I experience slowdowns.
I suppose it is possible size has something to do with it but my database is pretty small in comparison to what others are sharing.

24 GB!!!!! That 50 times my size and I would find that unlikely. I read mine as 47MB. That can't be right. I'll bet yours is actually 24MB.

LJ

I have done everything I can to limit logging but I haven't totally eliminated the text logging as I do use it to trouble shoot. I have also made a big effort to simplify rules, opting for a greater number of simple rules rather large complex ones which make a lot of decisions with many conditionals. I have tried to eliminate things like using changed triggers where ever possible.

LJ

Could you try an experiment and shut down your panels for a couple days and see if that improves things? My suspicion is that long running open dashboards are an issue, and your setup with all your performance metrics seems like a good way to test it.

LOL! That will be a question for my wife. That panel by her side of the bed is the biggest Wife Approval Factor in my whole setup. She doesn't like voice commands for some reason. Once she is prepared for it, and doesn't view it as another PITA failure of the technology investment, then I will try it. I will get back to you.

LJ

3 Likes

WAF?

5 Likes

:open_mouth: :laughing:

1 Like

My experience is the system is running out of memory/swap space (depending on the model)

My db's were initially 240MB and 190MB respectively (on 2 production hubs). I have been able to cut them down 57 MB and 82MB. This was some pretty aggressive actions on my part to get here.

After you trim it down, backup, software reset, and restore is not a bad idea (with backups off hub).

hopefully custom trimming of DB events will come as in my case, the current 1000 event trim down is still way too much in the db for me.

My view is bigger DB == more memory and/or swap consumption.

The DB alone is not 'the answer'. The system needs more virtual address space (swap). I think 1GB of memory is fine if there is 1GB of swap. Otherwise more memory is needed.

UPDATE: @gopher.ny @mark.cockcroft

Mark, Below is comparative data between Z-wave, Zigbee, and Virtual devices.

Victor and others, yesterday saw continued march toward slowdown after the morning restart. It was more rapid than the previous days and by 3PM it was almost constant across the system as shown here:

Then at about 3:20 PM ET it got so bad I chose to update the system to 2.2.2.129 and let it reboot. Since that time the system has been almost entirely clear of slowdowns and continues that way.

Were there more changes in this update aimed at addressing the slowdowns? Or, am I just seeing the results of the reboot and should expect that the slowdowns will return within 36 hours as before?

LJ

1 Like

It's the reboot. There are no performance focused changes between the two minor versions. We got more of those in the pipeline for 2.2.3, but they aren't live yet.

10 Likes

Thanks so much for the info. I really appreciate it.

LJ

Although I wasn't having any apparent slowdown issues, this update sure seems like it makes everything more "snappy" than it has been in a while. Everything just seems smoother and more responsive.

2 Likes

UPDATE: 36 Hours since last restart/reboot. Things were totally clear until about 3:30M ET. At that time it looks like Zigbee started to slow down and has continued to get worse, while Virtual and Z-wave still seem stable.

LJ

UPDATE: @gopher.ny OK, so some interesting observations. The system was reasonably stable through the day yesterday. there were a few increases in periodic slowdowns yesterday during the day but not enough to force an automated restart.

Then maintenance ran. I have Hub Watchdog set to stop during the maintenance period from 1:50 AM to 2:50 AM. That was always long enough and the restart and DB Stabilization period usually took about 10- 20 minutes. The watchdog shows that after the hour maintenance hold, the system continued to be in Slowdown and ultimately restarted the HE processes around 3 AM. The restart happened, and as you can see below, the system continues to be in a slowdown in Zwave, Zigbee, and Virtual watchdogs. it has not restarted but it is close.

I have suspected in the past that something in the maintenance may be triggering some slowdowns, but this 2.2.2.129 seems to be taking significantly longer to stabilize after maintenance than previous versions. Is it possible that nightly maintenance will be that much longer in this series of point releases? Is anyone else seeing this too?

LJ

1 Like

I also often suffer from this type of performance degradation at the nightly maintenance period. The fact the nightly process can so seriously affect hub performance like this is really ridiculous in my opinion. Many a time my lights just didn't respond at all. When someone breaks their neck falling down the stairs at night I wonder how the value proposition of "local, fast" will stand up. Hubitat really need to find a way to resolve this, and the absolute minimum should be to be able to select the time when this irritating service interruption occurs.

3 Likes

....this.

2 Likes

If you can let me know whether your burglar alarm is Z-Wave or Zigbee then I can work out if I have 28 minutes or 2.36 minutes to get in and back out with your stuff before your system responds and exactly at what time to make my attempt.

Thanks.

:sweat_smile:

4 Likes

I don't have an issue with a certain amount of slowdown during maintenance as it is understandably memory or CPu intensive. 10 - 15 minutes would seem acceptable. but not an hour or two.

Worse is that it seems to sometime never recover from the slowdown during maintenance until a restart is performed. That would seem to be unnecessary if things were all properly executing and completing. It seems like every 2 or 3 times maintenance runs it doesn't complete everything, or at least doesn't do anything to correct the slowdowns already happening, perhaps.

LJ

My alarm system is not dependant on HE and has multiple redundancies, but I can monitor it from HE. I guess I will need to keep my eye on YOU now! LOL :wink:

2 Likes