зависает заббикс-сервер

[pupkin.ivan]

Столкнулся с проблемой, которую не могу локализовать: периодически 1 процесс zabbix_server по top начинает есть 100 процессорного времени и работа всего сервера блокируется. strace -p показывает что этот процесс ничего не делает: строчек действий нет. Вэб-интерфейс рунается на недоступность сервера. В логах сервера чисто, никаких значений в конфиге поменять не предлагает. Вот этот процесс:

zabbix 24817 6.3 0.6 987404 108168 ? R May27 86:30 /usr/sbin/zabbix_server: history syncer #47 [synced 0 items in 0.0 00004 sec, syncing history]

Лечится только рестартом сервиса. Пробовал перенести основную нагрузку на zabbix proxy, помогло только в том что виснуть стал всего лишь раз в сутки вместо раз в 4-6 часов.

Как диагностировать лечить?

[pupkin.ivan]

версия последняя из репозитория для ubuntu 12.04 от zabbix.com.

[pupkin.ivan]

нашёл похожую безответную проблему

https://www.zabbix.com/forum/showthread.php?t=45338

ещё та есть ссылка на нерешённый баг: https://support.zabbix.com/browse/ZBX-7725

из смущающего, но вряд-ли влияющего: сейчас есть очередь из 99 вычисляемых более 10 минут элементов данных и она не падает и, я не уверен, что этого не было ранее.

Проблема проявилась как раз тогда, когда я добавил 500 хостов, которые пингуются, и каждый из них находится в соответствующей группе "рабочие часы с ХХ по УУ". Для этих групп созданы интервалы обслуживания, которые тушат триггера у этих хостов, продолжая собирать данные. Для этих узлов никаких вычисляемых элементов я не вводил. Они есть только у ранее добавленных 6000 узлов, у каждого из которых собирается 11 элементов. После добавления этих 6000 узлов никаких проблем не было месяц, проблемы начались только после добавления автоматически отключаемых вышеописанных 500 хостов.

[Jimson]

Не факт что "очередь" в веб-интерфейсе учитывает диапазоны опроса.
Скорее всего там просто идет выборка элементов у которых lasttime меньше чем (time - period) и если это так то такие элементы данных всегда будут показываться как "очередь".

[pupkin.ivan]

Не факт что "очередь" в веб-интерфейсе учитывает диапазоны опроса.
Скорее всего там просто идет выборка элементов у которых lasttime меньше чем (time - period) и если это так то такие элементы данных всегда будут показываться как "очередь".

очередь сейчас выглядит как во вложении и 2 часа назад опять пришлось рестартовать сервис по подобной проблеме. За что ухватиться не пойму.

[Jimson]

Я лишь хотел сказать что это по сути не очередь. Это кол-во элементов данных которые должны были получить новые данные X секунд назад. А вот почему они не получили данные уже другой вопрос.

В ссылках что вы дали описывается проблема с db syncer, у вас он тоже 100% busy?

[pupkin.ivan]

ситуация опять повторилась, опять history syncer:

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
zabbix 13088 43.6 0.5 987424 83528 ? R 13:28 80:36 /usr/sbin/zabbix_server: history syncer #7 [synced 26 items in 0.1 59208 sec, syncing history]


У меня DBSyncers 50 в конфиге и другие процессы history syncers не выходят на заметную нагрузку по cpu usage. База тоже не нагружена, 40 IOPS всего в устоявшемся режиме и 1000 при старте сервера минут на 30.

[Jimson]

А при нормальной работе загрузка db syncers по статистике забикса какая? 50 процессов оправданы?

[pupkin.ivan]

по графику "zabbix internal processes busy" загрузка не превышает 2%

[Jimson]

Информации ради. У меня на 2.0.3rc1 примерно месяц-полтора назад процессы history syncer начали кушать память. Откровенный mem leak, 4 процесса кушают примерно по 6 гиг в неделю.

В трекере куча репортов на эту тему, в том числе открытые на 2.2.2 и фиксеный на 2.0.3, вот только на сколько я вижу у меня ревизия (29519) должна быть уже пофиксена, а на деле течет.

[pzabortsev]

версия последняя из репозитория для ubuntu 12.04 от zabbix.com.

Можете сообщить номер версии?

[pupkin.ivan]

Zabbix 2.2.3

history syncer продолжает периодически вешаться, блокируя весь zabbix. strace -p <pid> показывает тишину.

Активно разглядывю графики загрузки внутренних процессов и ничего критичного нет, ресурсов существенно больше чем надо. History syncer за 10 минут набирает загрузку с 5 до 85% и вешает zabix. Всё это при отсутствии заметной нагрузки на базу и диски. В логах на максимальном дебаге ничего не указывает на проблему.

Я уже подумываю о даунгрейде на младшую версию, правда непонятно насколько это безболезненно для младшей версии.

[pupkin.ivan]

в логах сообщения вида:
25496:20140602:164700.295 History buffer is full. Sleeping for 1 second.
25372:20140602:164700.295 In DCvacuum_history() history_gap_num:0/926497
25372:20140602:164700.295 End of DCvacuum_history()
25372:20140602:164700.295 History buffer is full. Sleeping for 1 second.
25365:20140602:164700.296 In DCvacuum_history() history_gap_num:0/926497
25365:20140602:164700.296 End of DCvacuum_history()
25365:20140602:164700.296 History buffer is full. Sleeping for 1 second.
25624:20140602:164700.297 In DCvacuum_history() history_gap_num:0/926497
25624:20140602:164700.297 End of DCvacuum_history()
25624:20140602:164700.297 History buffer is full. Sleeping for 1 second.
25362:20140602:164700.297 In DCvacuum_history() history_gap_num:0/926497
25362:20140602:164700.297 End of DCvacuum_history()
25362:20140602:164700.297 History buffer is full. Sleeping for 1 second.
25634:20140602:164700.298 In DCvacuum_history() history_gap_num:0/926497
25634:20140602:164700.298 End of DCvacuum_history()
25634:20140602:164700.298 History buffer is full. Sleeping for 1 second.
25623:20140602:164700.298 In DCvacuum_history() history_gap_num:0/926497
25623:20140602:164700.298 End of DCvacuum_history()
25623:20140602:164700.298 History buffer is full. Sleeping for 1 second.
25580:20140602:164700.299 In DCvacuum_history() history_gap_num:0/926497
25580:20140602:164700.299 End of DCvacuum_history()
25580:20140602:164700.299 History buffer is full. Sleeping for 1 second.
25545:20140602:164700.299 In DCvacuum_history() history_gap_num:0/926497
25545:20140602:164700.299 End of DCvacuum_history()
25545:20140602:164700.299 History buffer is full. Sleeping for 1 second.
25529:20140602:164700.300 In DCvacuum_history() history_gap_num:0/926497
25529:20140602:164700.300 End of DCvacuum_history()
25529:20140602:164700.300 History buffer is full. Sleeping for 1 second.
25507:20140602:164700.300 In DCvacuum_history() history_gap_num:0/926497
25507:20140602:164700.300 End of DCvacuum_history()
25507:20140602:164700.300 History buffer is full. Sleeping for 1 second.
25736:20140602:164700.300 In DCvacuum_history() history_gap_num:0/926497
25736:20140602:164700.300 End of DCvacuum_history()

[pzabortsev]

Может стоит увеличить размеры буферов history?
Параметры HistoryCacheSize и HistoryTextCacheSize в конфиг файле

[pupkin.ivan]

это никоим образом не помогает.

Ситуацию меняет отключение множества периодов обслуживания, для каждого из которых привязана группа, в которой находятся хосты с соответствующим режимом работы. По-видимому ИТ-услугу доступности объектов по сети посчитать не получится при такой реакции timer-процесса. Смотрю на развитие событий с отключенными периодами.

Всего периодов 80 (восемьдесят) штук.
Все периоды заводились так:
Имя: "Рабочее время GMT+4 ПН-ВС 10:15-20:45"
Тип обслуживания: "со сбором данных"
Активно с 15/05/2014
Активно до 18/01/2038
Тип периода Запланировано Период Действие
Еженедельно At 00:00 on every Понедельник, Вторник, Среда, Четверг, Пятница, Суббота, Воскресенье of every week 10ч 14м
Еженедельно At 20:45 on every Понедельник, Вторник, Среда, Четверг, Пятница, Суббота, Воскресенье of every week 3ч 15м

Группы в обслуживании: "Рабочее время GMT+4 ПН-ВС 10:15-20:45"