Can I trust values stored?

[cybaspace]

The 'values stored' change everytime I hit the refresh. The stored values can change by millions in a matter of seconds.

For example:
First time: 67950191
Second time: 69870958
third time: 73047477

Is this normal behaviour?

[dantheman]

it depends on how many items you are collecting and how often. if you have many many items being collected at short intervals, this very well could be the case.

[cybaspace]

We are collecting quite some values but it changes a few million values every second. I don't think that the amount of values stored have such big changes ;-)

First values stored: 81852282
five seconds later: 77799808
15 seconds later: 75350198
30 seconds later: 78086276

[James Wells]

Greetings,

The 'values stored' change everytime I hit the refresh. The stored values can change by millions in a matter of seconds. ... Is this normal behaviour?

Yes it is. Zabbix will occasionally write temporary values, do something with them, then write out the final value. When it does this you can see the "values stored' increase and decrease rapdily. I should also note that when I wrote the code to show the values stored, I used a DB side procedure that does a point in time look. This procedure doesn't take into account committed actions or temporary actions.

[peter_field]

It seems screwy to me

OK, I have stopped zabbix_server and zabbix_agentd and the values on the status screen are still jumping by millions in seconds. Nothing should be writing to the database, unless the web interface is doing it, but why would the web interface write 3 million values in 1 second????

I think this is broken.

[den_crane]

...

I think this is broken.

it's mysql

See Any Mysql Faq: "The number of records for InnoDB tables is not correct".

IMHO: Zabbix uses a quick method to get the row count, and this method only returns an approximate count in the case of InnoDB tables. Exact row count could have a serious impact on performance.

On my zabbix mysql db, query SELECT count( * ) FROM `history` (exact row count), execute 10 ~ 50 sec, but I had a small db, history table ~ 440Mb.

[James Wells]

IMHO: Zabbix uses a quick method to get the row count, and this method only returns an approximate count in the case of InnoDB tables. Exact row count could have a serious impact on performance.

On my zabbix mysql db, query SELECT count( * ) FROM `history` (exact row count), execute 10 ~ 50 sec, but I had a small db, history table ~ 440Mb.

Correct. That is why I used this method in the code. At one time I had over 8 million items in history and another 2 million items in trends. What I found, and a number of other people at the time, was that any time I hit the reports page, it would take roughly 15 minutes to render the reports. By changing it to use this, it cut the time down to miliseconds, but the value may not always be completely accurate.

[peter_field]

It becomes clear now

That makes sense, thanks guys. I also just found this in the manual:

From http://www.zabbix.com/manual/v1.1/co...tems_types.php

zabbix[history] Number of values stored in table HISTORY Integer Do not use if PostgreSQ L or MySQL InnoDB is used!
zabbix[history_str] Number of values stored in table HISTORY_STR Integer Do not use if P ostgreSQL or MySQL InnoDB is used!
zabbix[trends] Number of values stored in table TRENDS Integer Do not use if PostgreSQL or MySQL InnoBD is used!

What your saying explains all this.