А АSaturday 31 October 2020

Zabbix performance tuning #2.

Всем привет.

Сегодня я хочу продолжить тему оптимизации производительности Zabbix. На это раз пройдемся по разделам книги «Zabbix Performance Tuning» от Luciano Alves, издательство Packt Publishing, 2015. Это материал подготовил Евгений Каменев три года тому. С тех пор ничего более подробного на эту тему я не встречал. Так что продолжим.


Zabbix - это платформа, которая состоит из трех компонентов:

1.Сервер Zabbix.

2.База данных Zabbix.

3.Фронтенд Zabbix.

Но в тему оптимизации следует включить еще два дополнительных пункта:

4.Оптимизация операционной системы Linux.

5. Мониторинг состояния Zabbix.


Далее рассмотрим каждый пункт последовательно.

1.Оптимизация Zabbix-сервера.

Использование активных Zabbix-agent проверок вместо пассивных Zabbix-agent проверок (уменьшает нагрузку на Zabbix-сервер и количество TCP-соединений).

При этом на Zabbix-агенте, возможно,есть смысл увеличить дефолтные значения параметров.

Ниже приведены дефолтные значения

BufferSend=5

BufferSize=100

На Zabbix-сервере необходимо увеличить количество процессов Zabbix-trapper, которые принимают входящие соединения активных агентов, Zabbix-sender и активных прокси.

Использование наименее дорогого с точки зрения чтения/записи базы данных типа элемента данных - (numeric(unsigned),numeric (float), character, text, log).

Каждый элемент данных записывается в отдельную таблицу history, в которой содержится разный тип и длина полей для хранения одного значения.

Использовать наименее дорогого с точки зрения нагрузки процессора триггера - (функции last(), nodata(), min(), max(), avg())

Например, функции min/max/avg сильнее нагружают процессор в отличии от функций last и nodata.

Время хранения данных в таблицах history,trends,events.

Уменьшаем время хранения истории с дефолтных 90 дней на 7 дней (при создании элемента данных)

Время хранения в таблице trends оставляем дефолтное 365 дней (при создании триггера)(если нет необходимости в просмотре информации за год,то сокращаем время хранения тенденций)

Время хранения событий, генерируемых триггерами, можно уменьшить с дефолтных 365 дней, чтобы не увеличивать размер таблицы events при частых колебаниях/срабатывании триггеров.


Оптимизация параметров Zabbix-кеша.

Проверяем результаты мониторинга Zabbix самого себя с помощью внутренних проверок.

И обращаем внимание на процент использования/свободного кеша.

При необходимости увеличиваем значение параметров в конфигурационном файле Zabbix-сервера:

CacheSize

HistoryCacheSize

TrendCacheSize

HistoryTextCacheSize

ValueCacheSize

  

2.Оптимизация базы данных Zabbix.

Например, используется MySQL в качестве СУБД и общий размер всех innodb-таблиц базы данных zabbix равен 1,8Gb)

innodb_buffer_pool_size = 2048M

innodb_buffer_pool_instances = 2

(один пул на каждый 1GB памяти в innodb_buffer_pool_size)

innodb_log_buffer_size = 16M

innodb_flush_log_at_trx_commit = 1

(если допускается потеря данных при аварийном прекращении работы MySQL, то для оптимизации производительности рекомендуется установить значение в 0)

innodb_flush_method = O_DIRECT

innodb_file_per_table = 1

innodb_log_file_size = 256M

Произведение innodb_log_file_size(256M) и innodb_log_files_in_group (2)должно бать примерно равно ¼ значения innodb_buffer_pool_size(2048M))

innodb_io_capacity=200 (дефолтное значение)

На SSD-дисках необходимо увеличить до 2000.

Отключение кеша:

Query_cache_type =0

query_cache_size=0

 

3.Оптимизация фронтенда Zabbix (GUI).

1) оптимизация Web-сервера Apache

Включение поддержки сжатия т.е. установить и активировать модули mod_deflate и/или mod_gzip:

Добавить в виртуальный хост Zabbix в Apache

AddOutputFilterByType DEFLATE text/plain

AddOutputFilterByType DEFLATE text/css

AddOutputFilterByType DEFLATE application/ x-javascript AddOutputFilterByType DEFLATE text/xml

AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xml+rss AddOutputFilterByType DEFLATE text/javascript

# Don't compress images

SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary

2) оптимизация Web-сервера Nginx

# nano /etc/nginx/nginx.conf

gzip on;

gzip_comp_level 5;

gzip_proxied any;

gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

3) включение поддержки PHP-кеширования средствами OpCache

# nano /etc/php5/mods-available/opcache.ini

; configuration for php ZendOpcache module

; priority=05

zend_extension=opcache.so


opcache.memory_consumption=128

opcache.interned_strings_buffer=8

opcache.max_accelerated_files=1000

opcache.revalidate_freq=0

opcache.fast_shutdown=1

opcache.enable_cli=1

 

4. Оптимизация операционной системы

Оптимизация файловой системы.

Для нагруженных Zabbix-серверов на уровне userspace (пользовательского пространства) проверить и увеличить лимит на количество открытых файлов для пользователя, под которым работает Zabbix-сервер (например для пользователя zabbix до 100000)

# su -l zabbix -s /bin/bash -c "ulimit -n" 1024

# nano /etc/security/limits.d/zabbix.conf

zabbix - nofile 100000

На уровне kernelspace (пространства ядра).

Проверить/увеличить лимит на кол-во открытых файлов

# sysctl -a | grep fs.file-max

# nano /etc/sysctl.conf

fs.file-max = 100000

# sysctl -p

Изменение политики использования SWAP.

Переменная ядра vm.swappiness, установка высоких значений будет приводить к более частому использованию SWAP-раздела/файла, в отличии от низких значений.

По умолчанию используется 60, т.е. операционная система выгружает данные при заполнении ОЗУ на 60%

# sysctl vm.swappiness

vm.swappiness = 60

Необходимо изменить до значения 5-10.

Так мы вынуждаем операционную систему использовать больше физической памяти прежде чем задействовать виртуальную память (swap-раздел/файл)

# nano /etc/sysctl.conf

vm.swappiness = 5

# sysctl –p

Два других параметра ядра должны быть оценены и, при необходимости, изменены для уменьшения тенденции свопинга. Эти значения напрямую влияют на ввод-вывод.

Эти параметры следующие:

vm.dirty_ratio

максимальный объем системной памяти, которую можно заполнить dirty pages;

vm.dirty_background_ratio

процент системной памяти, который можно заполнить dirty pages до того, как фоновые процессы pdflush/flush/kdmflush запишут их на диск;

vm.dirty_ratio = 5

vm.dirty_background_ratio = 20


Оптимизация сетевых параметров.

# sysctl -a | grep -E 'net.ipv4.tcp_max_syn_backlog|net.ipv4.tcp_rmem|net.ipv4.tcp_wmem|net.ipv4.tcp_fin_timeout|net.ipv4.tcp_keepalive_time|net.core.rmem_max|net.core.wmem_max'

  



5. Мониторинг состояния Zabbix.

Метрики как элементы данных для диагностики Zabbix-сервера





 

Метрики как элементы данных для диагностики производительности Zabbix-proxy

 


Метрики как элементы данных для диагностики производительности Zabbix-базы данных

1)Мониторинг медленных запросов

2)Мониторинг DELETE, INSERT, UPDATE, SELECT-запросов (для этого хорошо подходит встроенный в Zabbix шаблон Template App MySQL)


Дальнейшая оптимизация производительности Zabbix может быть связана с разделением некоторых  компонентов Zabbix-сервера и Zabbix-базы данных на отдельные сервера. Например, на одном сервере размещать Zabbix-сервер и GUI, а базу данных вынести на отдельный сервер. Также для разгрузки Zabbix-сервера и мониторинга териториально распределенных сетей есть смысл устанавливать и использовать Zabbix-proxy.



1 comment:

Anonymous said...

Считается, что для мониторинга сервиса достаточно следить всего за 4-мя параметрами:

Latency. Время, которое занимает обработка запроса. Неплохо бы разделять время для корректных ответов и ошибок.
Traffic. Количество запросов, приходящих к сервису. Например, rps для http-сервисов или bandwidth для стриминга.
Errors. Запросы, обработанные с ошибками.
Saturation. Насколько заполнен сервис. Например, для диска это общий объем и занятое место.

Post a Comment

А что вы думаете по этому поводу?

Версия на печать

Популярное