StartDBSyncers in Zabbix

Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached.

We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today!

Profile image of Mattias Geniar

Mattias Geniar, November 27, 2014

Follow me on Twitter as @mattiasgeniar

Zabbix Server has a configuration setting called StartDBSyncers. By default, this value is set to 4. This may seem like a conservative setting, but increasing the value can do more harm than good – I’ll try to explain why.

In the Zabbix Server, there are a few parameters that control the size of the memory cache. The cache consists of the CacheSize (hosts, triggers and items), HistoryCacheSize (items received by the Zabbix server, but not yet synced to the database), TrendCacheSize (trending data calculated by the Zabbix Server, but not yet synced to the database) and HistoryTextCacheSize for text-values received by the server, but not synced to the database.

To process those different memory caches, zabbix starts a Database Syncer Process, the amount of which is controlled by the StartDBSyncers parameter.

Those DBSyncer processes periodically look into the different caches and move items from the cache into the backend database, either by updating values or inserting them as new values. If too many DBSyncers are started, the database can start to see many deadlocks as all processes try to acquire table locks at the same time. Since Zabbix uses a single table for generating unique IDs, these locks can start to add up and add considerable latency/delay to each request.

The end result is that the higher you increase the StartDBSyncers parameters, the slower your data is flushed to the database. This sounds controversial, as you would imagine that having more DBSyncers would cause more parallel syncing to the database, but it’s exactly because of those many database deadlocks that are being caused that each sync takes longer (waiting for the locks to be cleared) to complete.

As a rule of thumb, one DBSyncer can handle 1.000 New Values Per Second (NVPS), as long as your database can keep up with the write I/O. You can check the status of your DBSyncers by using the Zabbix Internal types to check the state of each process, and their busy times.



Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.