Zabbix Documentation 1.8

3.04.04.4 (current)| In development:5.0 (devel)| Unsupported:1.82.02.22.43.23.44.2Guidelines

User Tools

Site Tools


Sidebar

manual:performance_tuning

18 Performance Tuning

4 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, one 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 600×2=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.

2009/08/17 06:45

2 Performance tuning

It is very important to have Zabbix system properly tuned for maximum performance.

2.1 Hardware

General advices on hardware:

  • Use fastest processor available
  • SCSI or SAS is better than IDE (performance of IDE disks may be significantly improved by using utility hdparm) and SATA
  • 15K RPM is better than 10K RPM which is better than 7200 RPM
  • User fast RAID storage
  • Use fast Ethernet adapter
  • Having more memory is always better

2.2 Operating System

  • Use latest (stable!) version of OS
  • Exclude unnecessary functionality from kernel
  • Tune kernel parameters

2.3 Zabbix configuration parameters

Many parameters may be tuned to get optimal performance.

2.3.1 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 the fastest and the most secure way.

2.4 Database Engine

This is probably most important part of Zabbix tuning. Zabbix heavily depends on availability and performance of 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.
  • tuning the database server for the best performance is highly recommended.
  • keep database tables on different hard disks
  • 'history', 'history_str, 'items' 'functions', triggers', and 'trends' are most heavily used tables.
  • for large installations, keeping of MySQL temporary files in tmpfs is recommended

2.5 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 overload Zabbix
  • tune parameters for default templates
  • tune housekeeping parameters
  • do not monitor parameters which 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).
2009/08/17 07:23