size of database in zabbix

[janssenreis]

in the manual of version 1.8.2, on topic 2.2.6 refers "Zabbix database, depending on database type, requires about 128 bytes per each total. Suppose we would like to keep trend data for 5 years. 3000 values will require (3000/1800)*(24*3600*365)* 128 = 6.3GB per year, or 31.5GB for 5 years."

what's this 1800? I'm mix up!!!
Can someone explain to me?

[James Wells]

Greetings,

in the manual of version 1.8.2, on topic 2.2.6 refers "Zabbix database, depending on database type, requires about 128 bytes per each total. Suppose we would like to keep trend data for 5 years. 3000 values will require (3000/1800)*(24*3600*365)* 128 = 6.3GB per year, or 31.5GB for 5 years."

Trending takes item historical data and "compresses" it in 30 minute intervals. If your item delay is greater than 30 minutes then trending loses value, becoming nothing more than another history table.

The next part is the values that actually get stored for trends. This might be where the confusion comes in as a trend row is actually multiple entries per row;

• min -- Stores the minimum value over the trend period
• max -- Stores the maximum value over the trend period
• avg -- Stores the average of all values received over the trend period
• count -- Stores the number of datapoints collected over the trend period
• itemid -- Self explanatory
• clock -- The Unix EPOCH time of the last trend update on the item.

So each day will require 6 x 48 x <RowSize>. RowSize varies based on the type of value you are trending, but a safe guesstimate it that each row will need 6 x 8 bytes or 48 bytes (Plus usual DB overhead of course) per row or 2304 bytes per day.

Now, the trick is that you will almost never need all 48 bytes per row as the DB backend will only use the space it actually needs to store the data. As such, your usage will vary on a per item basis and then again on a per item value type basis. To help simplify the math, a good round number to use is 1800 bytes per day, per item.

[richlv]

i do have a bad suspicion here that documentation is slightly outdated...
trends are calculated on hourly basis, the 1800 figure might refer to some old version (1.0 or 1.1, if my fuzzy memories are ti be trusted at least a bit).

i'd love to verify it before docs get updated, though

[James Wells]

trends are calculated on hourly basis

You are correct sir. I just checked the C code and trends were moved to 3600 seconds from the old 1800 seconds.

I wonder if that may be another reason for the 1800 in the calculation that is shown in chapter 2.2.6 in the documentation. I remember a discussion with I had with Alexei during the 1.4 days when we were talking about my temporal displacement triggers. I had originally written them to use history tables, and Alexei asked me to rewrite them to use trends and in that discussion he explained that trends were generated every 1800 seconds.

And yeah, row sizes exploded as well. Almost triple the length they were previously.

[janssenreis]

Since the trends were transferred to 3600 seconds, then in the formula would be the case I replace the 1800?

And why the items are divided by seconds? why every time a number of items are inserted into the table?