In the early versions of Zabbix up to version 1.6, all Zabbix server interaction with data occurred directly via SQL statements in the database. For collecting an item, the flow was as follows:
delay
and last_clock
)last_clock
(time of the last valid sample collection) was greater than delay
(number of seconds between gathers), then the Zabbix server started a new collection for that itemINSERT
on the database and store the collected valuesThe entire collection stream involved querying and writing (insert and update) to the database. In an environment of a large organization, where we have thousands of hosts and tens of thousands of items, it is possible to understand that the bottleneck would undoubtedly be in the database.
For the purpose of comprehensiveness and understanding, we should add to that environment triggers and their functions, the housekeeper, the Zabbix frontend, users' actions, alerts and escalations, and so on. The important fact is that the database has ended up being the main point when talking about Zabbix's performance. Zabbix SIA came to the conclusion that Zabbix should minimize its interactions with the database, or have these interactions be executed in the background by new internal processes and structures (caches and buffers).
Zabbix version 1.8 introduced some caches and buffers, which kept evolving. Today, they are responsible for ensuring good performance. Currently, the main caches and buffers are as follows:
CacheSize
(configuration cache):CacheSize
, the Zabbix server will not launchHistoryCacheSize
(history cache):HistoryTextCacheSize
(history text cache):ValueCache
(value cache):0
disables ValueCache
) and a maximum value of 64 GB.TrendCacheSize
(trends cache):With these settings, we can eliminate much of direct access to the database.
The main point here is to establish adequate monitoring of these caches and buffers so that we know how they are behaving and whether they need some adjustments in the parameter values assigned. For example, if HistoryCache
and/or HistoryTextCache
fluctuate a lot, this indicates that the Zabbix server has difficulties in delivering data to the database. The bigger this cache, the longer the Zabbix server supports this fluctuation.
To learn more about internal items related to caches and buffers inside Zabbix, take a look at the Zabbix manual and stay up to date with new keys and parameters.
In short, we must understand and exploit Zabbix's caches and buffers so that we can manipulate data in the storage and minimize database access.