Getting Maximum Performance from ZABBIX
Real world configuration
Server with ZABBIX 1.0 installed (RedHat Linux 8.0, kernel 2.4.18-14, MySQL/MyISAM 3.23.54a-4, Pentium IV 1.5Ghz,
256Mb, IDE) is able to collect more than 200 parameters per second from servers being monitored (assuming no
network delays).
How many servers can be monitored by ZABBIX on the hardware, you may ask? It depends on number of
monitored parameters and how often ZABBIX should acquire these parameters. Suppose, each server you monitor has ten
parameters to watch for. You want to update these parameters once in 30 seconds. Doing simple calculation, we see that
ZABBIX is able to handle 600 servers (or 6000 checks). In case if these parameters need to be updated once in a minute,
the hardware configuration will be able to handle 600x2=1200 servers. These calculations made in assumption that
all monitored values are retrieved as soon as required (latency is 0). If this is not a requirement, then number of
monitored servers can be increased even up to 5x-10x times.
Performance tuning
Performance of ZABBIX can be significantly improved by tuning:
Hardware
- Use fastest processor available
- SCSI is better than IDE (performance of IDE disks may be significantly improved by using utility hdparm)
- Use fast Ethernet adapter
- Having more memory is always better
Operating System
- Use latest (stable!) version of OS
- Exclude unnecessary functionality from kernel
- Tune kernel parameters
ZABBIX configuration parameters
Many parameters may be tuned to get optimal performance.
zabbix_server
- StartPollers
General rule - keep value of this parameter as low as possible. Every additional instance of zabbix_server adds
known overhead, in the same time, parallelism is increased. Optimal number of instances is achieved when
queue, on average, contains minimum number of parameters (ideally, 0 at any given moment). This value can
be monitored by using internal check zabbix[queue].
- DebugLevel
Optimal value is 3.
- DBSocket
MySQL only. It is recommended to use DBSocket for connection to the database. That is fastest and most secure way.
Database Engine
- use fastest database engine, i.e. MySQL
- use stable release of a database engine
- rebuild MySQL or PostgreSQL from sources to get maximum performance
- follow performance tuning instructions taken from MySQL or PostgreSQL documentation
- for MySQL, use InnoDB table structure
ZABBIX works at least 1.5 times faster (comparing to MyISAM) if InnoDB is used. This
is because of increased parallelism. However, InnoDB requires more CPU power.
- keep database tables on differend hard disks
'history', 'history_str, 'items' 'functions', triggers', and 'trends' are most heavily used tables.
General advices
- monitor required parameters only
- tune ‘Update interval’ for all items. Keeping small update interval may be good for nice graphs, however, this may
over load ZABBIX
- tune parameters for default templates
- tune housekeeping parameters
- do not monitor parameters wich return same information.
Example: why use system[procload],system[procload5] andsystem[procload15] if system[procload] contains all.
- avoid use of triggers with long period given as function argument. For example, max(3600) will be calculated
significantly slower than max(60).
| 
Advanced