18 Оптимизация производительности
1 Реальная конфигурация
Сервер с установленным Zabbix 1.0 (RedHat Linux 8.0, ядро 2.4.18-14, MySQL / MyISAM 3.23.54a-4, Pentium IV 1.5 ГГц, 256 Мб, IDE) может собирать более 200 параметров в секунду с наблюдаемых серверов (при условии отсутствия задержек в сети).
Вы можете спросить, сколько серверов можно контролировать с помощью Zabbix на моем оборудовании? Ответ зависит от количества контролируемых параметров и как часто Zabbix будет должен опрашивать эти параметры. Предположим, каждый сервер наблюдает десять параметров. Вы хотите обновлять эти параметры один раз в 30 секунд. Сделав простые расчеты, мы видим, что Zabbix способен обрабатывать 600 серверов (или 6000 проверок). В случае, если эти параметры должны быть обновлены один раз в минуту, аппаратная конфигурация сможет обрабатывать 600×2 = 1200 серверов. Эти расчеты сделаны в предположении, что все наблюдаемые значения получаются сразу как только будут запрошены (задержка 0). Если это не является обязательным требованием, то количество наблюдаемых серверов может быть увеличено вплоть до 5x-10x раз.
2 Оптимизация производительности
Очень важно, чтобы система Zabbix была оптимально настроена для получения максимальной производительности.
2.1 Аппаратное обеспечение
Общие советы по оборудованию:
-
Используйте самый быстрый процессор из доступных
-
SCSI или SAS лучше чем IDE (производительность IDE дисков может быть существенно улучшена с помощью утиллиты hdparm) и SATA
-
15K RPM лучше чем 10K RPM, что в свою очередь лучше чем 7200 RPM
-
Пользуйтесь быстрым хранилищем RAID
-
Используйте быстрый адаптер подключения к сети
-
Наличие дополнительной памяти это всегда хорошо.
2.2 Операционная система
-
Используйте последнюю (стабильную!) версию ОС
-
Выключите из ядра не требуемую функциональность
-
Оптимизируйте параметры ядра
2.3 Параметры настройки Zabbix
Много параметров могут быть оптимизированы для получения оптимальной производительности.
2.3.1 zabbix_server
StartPollers
Общее правило – удерживать значение этого параметра как можно более низким. Каждый дополнительный процесс zabbix_server добавляет определенные накладные расходы, в то же время, увеличивает параллелизм. Оптимальное количество процессов достигается тогда, когда очередь в среднем содержит минимальное количество параметров (в идеале, 0 в любой данный момент). Это значение может контролироваться с помощью внутренней метрики zabbix[queue].
DebugLevel
Оптимальное значение 3.
DBSocket
Только для MySQL. Рекомендуется использовать DBSocket для подключений к базе данных. Это самый быстрый и самый безопасный способ.
2.4 Движок базы данных
Это, вероятно, самая важная часть оптимизации Zabbix. Zabbix во многом зависит от доступности и производительности базы данных.
-
Используйте самый быстрый движок базы данных, т.е. MySQL))
-
Используйте стабильный релиз движка базы данных
-
Перекомпилируйте MySQL или PostgreSQL из исходных кодов для получения максимальной производительности
-
Следуйте инструкциям по оптимизации производительности из документации по MySQL или PostgreSQL
-
Для MySQL, используйте структуру таблиц InnoDB
-
Zabbix работает по крайней мере в 1.5 раза быстрее если используется InnoDB (при сравнении с MyISAM). Это происходит за счет увеличения параллелизма. Однако, InnoDB требует больших ресурсов процессора.
-
Очень рекомендуется оптимизация сервера баз данных для лучшей производительности.
-
Разнесите таблицы базы данных на разные жесткие диски
-
'history', 'history_str, 'items' 'functions', triggers', и 'trends' наиболее активно используемые таблицы.
-
Для больших установок, рекомендуется в MySQL для временных файлов использовать tmpfs
2.5 Общие советы
-
Наблюдать только нужные параметры
-
Оптимизируйте 'Интервал обновления' для всех элементов данных. Использование маленького интервала обновления может быть хорошо для красивых графиков, однако, это может чрезмерно нагружать Zabbix
-
Оптимизируйте параметры для шаблонов по умолчанию
-
Оптимизируйте параметры очистки истории
-
Не осуществляйте мониторинг за параметрами, которые возвращают одну и ту же информацию.
Пример: зачем использовать system.cpu.util[,user,avg1] и system.cpu.util[,user,avg5], если system.cpu.util[,user,avg1] уже содержит получаемые данные, причем более детальные.
-
Избегайте использования триггеров с большим периодом времени, переданным в качестве аргумента функции. Например, max(3600) будет высчитано значительно медленнее, чем max(60).
Data source: Zabbix