Zabbix /opt disk size constantly growing up - history* table

[Nyamka110]

Hello all;

We have Zabbix 2.2.1 with postgresql 9. 324 hosts, 8651 items and 4850 triggers are in our zabbix.

Also we have housekeeper that run every hour.

But our /opt disk size, in other word history* table size is constantly raising.
One month ago we truncated the history, history_uint, history_text tables. But now it has been raising.

relation | total_size
---------------------------+------------
public.history_uint | 21 GB
public.history | 11 GB
public.trends_uint | 1399 MB
public.history_text | 1038 MB
public.events | 573 MB
public.trends | 437 MB
public.alerts | 129 MB
public.history_str | 83 MB
public.history_log | 23 MB
public.auditlog | 8496 kB

Processor load is normal, so system performance is good enough i think.

please see attachment pictures and any advise is treasure for me, thank you.

[steveboyson]

Thats pretty normal. It depends on the intervall you've set for your items and the history settings. How many NVPS (new values per second) do you have?

Just some calculation:
1000 items with 60s interval:
=> 1000 new values per minute
=> 60000 items per hour

That sums up quite fast.

[Nyamka110]

Hi, thanks for your reply.

New values per second is 124.3, that means our new values per minute is 7458, right?
And 447480 item values per hour.

So does it means it will be growing up every second?

How people control this? any tuning tips..? pls

[steveboyson]

1) keep the history period for items as short as possible
2) also keep trends as short as possible (affects trends* tables)
3) avoid "text" and "char" items as often as possible (they are byte consuming!)
4) use partitioned tables in the database

for 4) I suggest a g00gle search since I have not been doing that so far.

[Nyamka110]

Thanks SteveBoyson. I found database partitioning is easy to control and delete old data and is very good idea. Your advice is great. I will do it.

I searched google and found this method doing this.
https://www.zabbix.org/wiki/Docs/how...l_partitioning.