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?
The alert seems to show up at ~50M.
It seem irrelevant when u have lots of device's u always will get that alert.
I don't know about that... I have 65 devices on one hub and 95 on the other and have never seen it.
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.
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..
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.
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.
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 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.
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).
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?
If there's no visible slowdown, no.
If things work as expected, keep ignoring the alert
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.
So if you click on the r eview runtime statistics link you should be able to determine what’s causing your database to grow.
That alert will disappear in 24h I would say..
Yeah.. 747m is absolutely huge. I've never seen someone report something that high. For reference I think it might start alerting at 50mb.
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.
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
You might want to contact support to see if they have any suggestions.
If I remember right... after adjusting limits.. error still stays there. Then if you click alert button it does not open configuration page anymore like it is supposed to do if error is still existing. That is what happened here and I decided to wait if error disappears and it was gone next day.
I suppose if nothing else, it prompted me to do a little house keeping. My logs have never looked cleaner!