Alert - Your database is growing

Get Help
#1

Hi all, I upgraded to 2.2.6.137 a few days ago, and noticed the new alert when logged into the homepage of my hub.
image

When I click on the alert, it says the following:

image
image1447×430 31.7 KB

My event and state history have been '100' ever since that was an option several months ago. Looking into my logs, however, I see that many devices are ignoring this event history. (column marked 1 is events, 2 is states)

image
image1455×257 20.4 KB

When I go to the device driver for one of those devices, such as 'Fireplace R' the event and state history are set to 100 (and, again, it has been set to 100 for several months)

image
image1011×674 36 KB

But when I click on "Events" for this device, I see 613 events dating all the way back to when I installed the device in 2019.

image
image1501×1107 108 KB

I am seeing this behavior across all of my devices - Zigbee, Z-Wave, LAN, and across built in drivers and custom drivers.

What might be causing my hub to ignore my setting of 100 events stored in the logs for all of my devices?

Troubleshooting C7 Hub Slow Down issue?
Hub Issues
Database size, corruption, and cloud backup concerns
#2

It’s 100 per attribute. So for example, 10 attributes would equal 1000 stored events total.

1 Like
#3

Ok, that makes sense. I'll drop it down to 10 then. Thanks!

#4

Just to make sure. What difference does it make to set event history and state history size to 10? I'm getting alert "your db is 93ms and growing" and size setting is 100 now. What db ms size I should be worried of...over 100ms... over 200ms... where should that db ms be by default?

#5

The alert seems to show up at ~50M.

#6

It seem irrelevant when u have lots of device's u always will get that alert.

1 Like
#7

I don't know about that... I have 65 devices on one hub and 95 on the other and have never seen it. :man_shrugging:

Guess it depends on your definition of "lots".

Really it probably more depends on how many "chatty" devices you have as well as multi-attribute devices. For instance a weather station device with 20-30 attributes that update frequently can take more database size than 30 individual single function devices.

In scenarios where there are a ton of attributes, or they are really chatty, reducing the retention settings definitely helps.

2 Likes
#8

I'm confused what does that alert even means. Is it something that needs to take care of or just let it be. After couple of hours my db increased to 113ms.. and it's still growing..
What then?

#9

Here's a quote from a staff member.

If you want to reduce the size of your database you can decrease the event and state history sizes globally with the following commands.

hubIPaddress/hub/advanced/event/limit/<desiredSize,1-1000> ,
hub IP address/hub/advanced/deviceStateHistorySize/<desiredSize,1-1000>

I've set both of mine to 5 and noticed a significant decrease in the size of my database.

Sonos is killing my Hub
#10

Event History is the most useful, for me. I have a lot of acquired knowledge of how often I look at a device's Event log/history. Some devices get a visit quite often, other's probably never. Presence is one I visit a lot. BUT, I don't need to look back to 2019 :smiley: If I can see only the most recent 10, I'm good. So I set the default pretty low... about 3 ( I have 7 hubs so I haven't taken the time to make this match on all.) Then I hit the devices I need more than 3 and set them to a more comfortable value.

State History is a bit more mysterious to me, but certain Drivers (weather and statistics) tend to have a dozen or more attributes, setting them low makes the multiplication work out better, DB size wise.

4 Likes
#11

OK. So my database is at 61m and growing.

(Yes, I have now reduced the registers to 50 from the initial 100.)

But... is 61m really too much?

Does m stand for Megabytes?

When will the memory overflow, or saturate, if it does?

Are there any consequences?

Does a high number imply the hub will run slower?

I used to be happy ignoring this (hahaha).

#12

By attributes per device would that mean, for example, for Inovelli Red dimmers each of the many possible settings is a separate attribute whether it is used and set or not. That would make each Inovelli Red dimmer take up as much space in the database as, say, twenty Sonoff motion sensors without temperature.

Am I understanding that correctly?

#13

Generally, yes.

If there's no visible slowdown, no.

If things work as expected, keep ignoring the alert :slight_smile:

3 Likes
#14

Hum, I did all that (set to 5) and turned off all possible debug logging. Then rebooted hub and still I get alert at same level as before these changes.

image

#15

So if you click on the r eview runtime statistics link you should be able to determine what’s causing your database to grow.

#16

That alert will disappear in 24h I would say..

#17

Hmmm…. 747m is really high. Mine has never been above 75m with almost 300 devices.

image
image2468×1120 216 KB

#18

Yeah.. 747m is absolutely huge. I've never seen someone report something that high. For reference I think it might start alerting at 50mb.

#19

That's the point, I reviewed them in detail and turned off logging (specifically Webcore) and other non-essential items, reduced the state size and history size, rebooted the hub. Yet, the baseline number (prior to reboot/alterations) remains the same and continues to grow.

Even if the action taken presented any change the baseline db stats should of changed. Yes, there were major differences (before/after) in the runtime stats for both apps and devices.

Is there a manual way to reset the database status which causes the alert as with all others, a refresh if you will?

I suppose from @Jani response there is an internal, non user accessible clean up routine that cycles every 24 hrs or some period.

#20

Yes, I would think so from what Ive sampled in comments. However, the hub runs perfectly fine. Only some (slow) devices have any noticeable effects. All my automations (exclusively in Webcore) run perfectly. All my dashboards are fine, even the ones produced with Hubigraphs (resource hog).

Matter of fact, I had no idea what my database size was nor any reason for concern until after the upgrade that enabled the feature. It is good to have more visibility into the hub (stats), but sometimes ignorance is indeed bliss. LOL

1 Like

Download the Hubitat app