Резкий рост нагрузки на HistorySyncer при добавлении

[samosvat]

Привет!

Появилась проблема:
Добавляю в заббикс 50 хостов (на каждом по 80...100 эл. данных) и заббикс начинает "тормозить" при работе с таблицей history_unit.
Хосты мониторятся через прокси.
Длятся тормоза примерно 30 минут - 1 час.
Через час работа заббикса восстанавливается, но часто исторические данные за диапазон времени, когда были "фризы", оказываются рваные (пропуски на графиках).
Так-же в этот диапазон времени срабатывают триггеры, которые считают значния исходя из времени: bla-bla.avg(10m)<100.
Каких либо других тормозов нет - любые другие данные, которые завязаны на другие таблицы заббикс отдает без задержек (события, списки хостов...).
Но вот последние данные или графики - как будто отрезало в этот момент времени. А когда все восстанавливается - данные дорисовываются.

Как я понимаю проблема в том что заббикс не успевает вовремя записать данные в БД: нагрузка на хистори-синкер вырастает на 100% в это время. А через время нагрузка на него возвращается в норму.
Судя по статистике в утилите innotop - работа в БД идет в основном с таблицами history_unit.
На аппаратную составляющую не грешу - сервера должно вполне хватать:
SSD 700GB x 2 шт в Raid1
256Gb RAM
60 ядер cpu
БД 30Гб с партиционированием по дням, в том числе партиционирована и history_unit.

Конфиги БД и Сервера ниже.

Вопрос - куда копать, чтобы заббикс успевал писать в базу при пиковых нагрузках.

[samosvat]

/etc/my.cnf

# Percona Server template configuration

[mysqld]

collation-server = utf8_bin
init-connect='SET NAMES utf8'
character-set-server = utf8

datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
slow-query-log = 1
slow-query-log-file = /var/log/mysql_sq.log
long_query_time = 2000
skip-name-resolve

#innodb_flush_method = O_DIRECT
innodb_flush_method = O_DIRECT_NO_FSYNC
#sync_binlog = 0
query_cache_size=32M
query_cache_type=1

innodb_file_format = Barracuda
innodb_file_per_table = 1
innodb_buffer_pool_size=200G
innodb_page_cleaners = 8
#innodb_buffer_pool_instances = 8
tmp_table_size = 256M

#innodb_tmpdir=/var/lib/mysql-tmp
#tmpdir=/var/lib/mysql-tmp

innodb_log_file_size=256M
max_allowed_packet=256M
default_password_lifetime=0
bind-address = 0.0.0.0

#enforce-gtid-consistency
#gtid-mode=ON
#log-bin = mysql-bin
#server-id = 1
innodb_flush_log_at_trx_commit = 0
#expire_logs_days = 10
event_scheduler = on

max_connections = 10000

# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M

/etc/zabbix/zabbix_server.conf

LogFile=/var/log/zabbix/zabbix_server.log
LogFileSize=100
DebugLevel=3
PidFile=/var/run/zabbix/zabbix_server.pid
DBSocket=/var/lib/mysql/mysql.sock
DBName=zabbix
DBUser=zabbix
DBPassword=PASSWD
StartPollers=16
StartIPMIPollers=1
StartPollersUnreachable=8
StartTrappers=16
StartPingers=4
StartDiscoverers=2
StartHTTPPollers=4
SNMPTrapperFile=/var/log/snmptrap/snmptrap.log
HousekeepingFrequency=0
CacheSize=1024M
HistoryCacheSize=1024M
HistoryIndexCacheSize=32M
TrendCacheSize=32M
ValueCacheSize=1024M
Timeout=30
AlertScriptsPath=/usr/lib/zabbix/alertscripts
ExternalScripts=/usr/lib/zabbix/externalscripts

Количество узлов сети (активированных/деактивированных/шаблонов)                621      301/220/100
Количество элементов данных (активированных/деактивированных/неподдерживаемых)  25818    19415/6009/394
Количество триггеров (активированных/деактивированных [проблема/ок])            13525    13356/169[154/13202]
Количество пользователей (в сети)                                               65       4
Требуемое быстродействие сервера, новые значения в секунду                      237.72

[samosvat]

Скриншоты сюда прикладывать не удобно, мелкие шибко. Вот ссылки на них:

1. Запросы в момент очередного фриза: https://www.dropbox.com/s/rmvderqzk5...56.27.png?dl=0
2. InnoDB i/o: https://www.dropbox.com/s/79qk0vd5y0...56.39.png?dl=0
3. Открытые таблицы: https://www.dropbox.com/s/e3xbteb5ov...56.56.png?dl=0
4. Хистори синкер: https://www.dropbox.com/s/snp51dkexm...03.12.png?dl=0
5. Запросов к БД: https://www.dropbox.com/s/1rw9fz81s7...03.28.png?dl=0
6. Нагрузка на сервер (Zabbix+DB+Front): https://www.dropbox.com/s/hc5lp5ezr6...26.45.png?dl=0

[glebs.ivanovskis]

Как выглядит использование value cache? Этот график должен быть в стандартных шаблонах.

Я вижу запросы данных из базы за неделю. Обычно сервер старается не читать данные из базы, а хранить их в памяти. Исключение - при нехватке места в value cache он переходит в low memory mode, и это очень сильно сказывается на производительности.

Процесс history syncer не только пишет исторические данные в базу, но и считает на их основе триггеры. Копайте в сторону того, какие данные провоцируют фриз (много данных по одним и тем же элементам данных, пересчёт большого числа триггеров, переполнение value cache...)

[samosvat]

По тем 3 запросам, которые висят при "фризе":
1 запрос - это метрика (itemid = 237823) которая формируется через LLD на одном из добавляемых хостов. Всего хостов 50..100, метрик у каждого 50...100 (в том числе и LLD). Итого в сумме добавляю от 2500 до 10 тыс метрик.

Метрика:

https://www.dropbox.com/s/5mexbdyhs2lphrz/item.PNG?dl=0

триггеры этой метрики (выделено):
https://www.dropbox.com/s/tg5wac8b4t...ggers.PNG?dl=0

Остальные 2 аналогичные. В триггерах вроде "криминала" нет.

[samosvat]

Value cache
Добавление хостов было в диапазоне (примерно) с пол первого до часа ночи, на графиках видны отклонения в это время.. но вот как их интерпретировать?

Zabbix value cache, % free

https://www.dropbox.com/s/3jesdvgzomtlk7g/value_cache.PNG?dl=0

Zabbix value cache hits

https://www.dropbox.com/s/v19a210hm5s1aen/value_cache_hits.PNG?dl=0

Zabbix value cache misses

https://www.dropbox.com/s/0dft2uickdbogdb/value_cache_miss.PNG?dl=0

Zabbix value cache operating mode

https://www.dropbox.com/s/v4f2974ulroqst3/value_cache_mode.PNG?dl=0

[samosvat]

Я вижу запросы данных из базы за неделю. Обычно сервер старается не читать данные из базы, а хранить их в памяти. Исключение - при нехватке места в value cache он переходит в low memory mode, и это очень сильно сказывается на производительности.

Странно что он запрашивает историю по элементам данных за неделю, тогда как этих элементов данных вроде в базе быть не должно, это свежие с пылу с жару lld-метрики.

Процесс history syncer не только пишет исторические данные в базу, но и считает на их основе триггеры. Копайте в сторону того, какие данные провоцируют фриз (много данных по одним и тем же элементам данных, пересчёт большого числа триггеров, переполнение value cache...)

Может раскрыть мысль по подробнее, не до конца понял: что значит "много данных по одним и тем же элементам данных"

Спасибо!

[glebs.ivanovskis]

Value cache
Добавление хостов было в диапазоне (примерно) с пол первого до часа ночи, на графиках видны отклонения в это время.. но вот как их интерпретировать?

Zabbix value cache, % free

https://www.dropbox.com/s/3jesdvgzomtlk7g/value_cache.PNG?dl=0

Zabbix value cache hits

https://www.dropbox.com/s/v19a210hm5s1aen/value_cache_hits.PNG?dl=0

Zabbix value cache misses

https://www.dropbox.com/s/0dft2uickdbogdb/value_cache_miss.PNG?dl=0

Zabbix value cache operating mode
https://www.dropbox.com/s/v4f2974ulr..._mode.PNG?dl=0

Это интересные графики. Обращения к value cache происходят при вычислении триггерных функций. Hits - данные уже были в памяти, misses - данных в памяти не было и пришлось обратиться к базе данных. Время "затыка" history syncer'а совпадает с началом периода с большим числом misses. Процесс пересчёта триггеров получается долгим и это тормозит весь процесс синхронизации истории.

Странно что он запрашивает историю по элементам данных за неделю, тогда как этих элементов данных вроде в базе быть не должно, это свежие с пылу с жару lld-метрики.



Может раскрыть мысль по подробнее, не до конца понял: что значит "много данных по одним и тем же элементам данных"

Спасибо!

Если в триггерной функции стоит недельный интервал, то и запрос будет про неделю. Случай новых метрик никак отдельно не обрабатывается. И насколько я знаю логику работы value cache, если в памяти данных за период не нашлось, он будет обязан обратиться к базе. (Может данных в памяти нет по причине недавнего рестарта?) Кстати, по графикам видно, что как только Zabbix "разобрался" в ситуации, следует пик value cache hits и падает загруженность history syncer'ов.

Возможно такая логика работы value cache не идеальна, смело пишите ZBX/ZBXNEXT с жалобами/предложениями и описанием ситуации. А как временное решение проблемы я бы посоветовал не создавать 50 хостов сразу, растяните этот процесс, чтобы не создавать пиковую нагрузку. Если Вы не жалуетесь на быстродействие базы данных, то увеличение числа history syncer'ов тоже может помочь.

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