Zabbix 2.2.1 производительность

[br2t]

Добрый день, всем!
После обновления с 2.0.8 до 2.2.1 получили огрумную очередь в SNMPv2 и постоянно растущую загрузку CPU
На сервере постоянно в 100% busy poller. Увеличение поллеров не дает эффекта с очередью но load average взлетает.

На сервере сейчас:
Количество узлов сети (под наблюдением/без наблюдения/шаблоны) 3282 712 / 2457 / 113
Количество элементов данных (активных/деактивированых/не поддерживаются) 39058 37919 / 314 / 825
Количество триггеров (активированных/деактивированных) [проблема/ок] 9011 8496 / 515 [43 / 8453]
Количество пользователей (в сети) 18 2
Требуемое быстродействие сервера, новые значения в секунду 99.42

Подскажите пожалуйста в какую сторону копать, что проверять? Уже перепробовал много чего от настроек zabbix_server.conf до ковыряния mysql... вероятно не так копаю.

p.s. на 2.0.8 все было отлично с 70000 элементов данных

[ivanmfan]

У меня была похожая ситуация была проблема с очередью на SNMPv2, как только я установил Zabbix 2.2.1 на Freebsd, это при том что у меня элементов было 200шт.
Ошибка в логах появлялась постоянно
"SNMP agent item "ifOperStatus[...]" on host "..." failed: first network error, wait for 15 seconds"
Я просто удалил эти элементы, они не сильно мне важны. И я был не уверен в том что я все нормально настроил, т.к. имею впервые дело с Zabbix'ом.

[br2t]

подобные записи у меня часто встречались и 2.0.8, но на производительность это особо не влияло.
тут же у меня постоянно сервер как будто захлебывается, даже когда уменьшаю число итемов, то первые несколькоминут busy poller нормальный и load average нормальный, как через пару часов LA улетает в 100-150 и busy poller в 100%.
ощущение что данные не пишутся в БД, но как продиагностировать не пойму

[LynxChaus]

Мониторь чем занят SQL. Если висят кучи запросов вида "select clock,ns,value from %table where itemid=" - то отключай ValueCache. На данный момент его реализация достаточно странна и при большом количестве триггеров может забивать диск постоянным чтением ненужных данных из SQL.

[strobil]

Здравствуйте. У меня проблема аналогичная проблеме ТС.
Образовывается очередь SNMPv2, при этом Poller process занят на 30%.
Зависших запросов в MySQL нет, установка значения ValueCacheSize=0 не произвела никакого результата.

Zabbix server v2.2.1 (revision 40808) (09 December 2013)
Compilation time: Dec 11 2013 07:05:56

[root@zabbix ~]# cat /etc/redhat-release
CentOS release 6.5 (Final)

[root@zabbix ~]# uname -a
Linux zabbix 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Jan 3 21:39:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Прикрепляю графики нагрузки на Zabbix Сервер.

[strobil]

Заметил следующее:
На узлы сети у которых есть элементы данных которые создаются на основе динамических индексов постоянно идут запросы GetNextRequest.
Т.е. перестало работать кеширование динамических индексов. Возможно именно с этим связано образование очереди SNMPv2 при сравнительно небольшой нагрузке на сервер.

Ниже график загрузки CPU, на котором видно что после обновления Zabbix-сервера загрузка CPU выросла до 90%, и это не в ЧНН!
Как оказалось, высокая нагрузка на CPU как раз таки и связана с тем что Zabbix бесконечно пытается перестроить кеш динамических индексов.

[strobil]

Отрепортил баг https://support.zabbix.com/browse/ZBX-7690
Просьба проголосовать за него всех,у кого наблюдается данная проблема.

[LynxChaus]

Заметил следующее:
На узлы сети у которых есть элементы данных которые создаются на основе динамических индексов постоянно идут запросы getnextrequest.
Т.е. перестало работать кеширование динамических индексов. Возможно именно с этим связано образование очереди snmpv2 при сравнительно небольшой нагрузке на сервер.

Конфигурацию итема покажи?

[Jimson]

Отрепортил баг https://support.zabbix.com/browse/ZBX-7690
Просьба проголосовать за него всех,у кого наблюдается данная проблема.

Уж не знаю как там щас, но раньше этот кэш представлял из себя откровенный костыль. Когда я указал это в одном из репортов в документацию добавили приписку что этот кэш локален для каждого процесса пуллера. Вот только кроме того что он локален в нем так же небыло привязки к SNMP агенту с которого он взят, они добавили это?

Суть такая, у вас есть два коммутатора SW1 и SW2, у обоих есть интерфейс с ifDescr "FastEthernet0/1", но на SW1 индекс этого интерфейса 2, а на SW2 - 10002. Опрос будет происходить так:

- запрос на SW1.FastEthernet0/1
1) ищем в кэше FastEthernet0/1, не находим ничего
2) вычитываем через getnext() индекс ifDescr с SW1 и сохраняем его в кэше
3) получаем из кэша индекс для FastEthernet0/1, он равен 2
4) получаем значение итема через get()

- следом тот же пуллер получает запрос на SW2.FastEthernet0/1
1) ищем в кэше индекс для FastEthernet0/1, находим, он равен 2
2) пытаемся получить значение итема с SW2, в лучшем случае получим NOSUCHINSTANCE, в худшем получим значение элемента при индексе 2, те какую то пургу
3) есть нас послали (NOSUCH), идем вычитывать ifDescr с SW2 и заполнять кэш, теперь в кэше у нас FastEthernet0/1 будет соответсвовать индекс 10002
4) получаем значение

Ну вообщем как это будет работать я думаю понятно. Есть подозрения что на динамические индексы все давно забили (в плане использования) и перешли на LLD, хотя наверняка есть ситуации что индекс был бы удобнее и проще.

[strobil]

Уж не знаю как там щас, но раньше этот кэш представлял из себя откровенный костыль. Когда я указал это в одном из репортов в документацию добавили приписку что этот кэш локален для каждого процесса пуллера. Вот только кроме того что он локален в нем так же небыло привязки к snmp агенту с которого он взят, они добавили это?

Суть такая, у вас есть два коммутатора sw1 и sw2, у обоих есть интерфейс с ifdescr "fastethernet0/1", но на sw1 индекс этого интерфейса 2, а на sw2 - 10002. Опрос будет происходить так:

- запрос на sw1.fastethernet0/1
1) ищем в кэше fastethernet0/1, не находим ничего
2) вычитываем через getnext() индекс ifdescr с sw1 и сохраняем его в кэше
3) получаем из кэша индекс для fastethernet0/1, он равен 2
4) получаем значение итема через get()

- следом тот же пуллер получает запрос на sw2.fastethernet0/1
1) ищем в кэше индекс для fastethernet0/1, находим, он равен 2
2) пытаемся получить значение итема с sw2, в лучшем случае получим nosuchinstance, в худшем получим значение элемента при индексе 2, те какую то пургу
3) есть нас послали (nosuch), идем вычитывать ifdescr с sw2 и заполнять кэш, теперь в кэше у нас fastethernet0/1 будет соответсвовать индекс 10002
4) получаем значение

Ну вообщем как это будет работать я думаю понятно. Есть подозрения что на динамические индексы все давно забили (в плане использования) и перешли на lld, хотя наверняка есть ситуации что индекс был бы удобнее и проще.

Я не знаю как это работало в ветке 2.0, но такой проблемы у меня не было
А сейчас она есть. Пришлось откатиться пока-что обратно на 2.0.10

[LynxChaus]

Суть такая, у вас есть два коммутатора SW1 и SW2, у обоих есть интерфейс с ifDescr "FastEthernet0/1", но на SW1 индекс этого интерфейса 2, а на SW2 - 10002. Опрос будет происходить так:

- запрос на SW1.FastEthernet0/1
1) ищем в кэше FastEthernet0/1, не находим ничего
2) вычитываем через getnext() индекс ifDescr с SW1 и сохраняем его в кэше
3) получаем из кэша индекс для FastEthernet0/1, он равен 2
4) получаем значение итема через get()

- следом тот же пуллер получает запрос на SW2.FastEthernet0/1
1) ищем в кэше индекс для FastEthernet0/1, находим, он равен 2
2) пытаемся получить значение итема с SW2, в лучшем случае получим NOSUCHINSTANCE, в худшем получим значение элемента при индексе 2, те какую то пургу
3) есть нас послали (NOSUCH), идем вычитывать ifDescr с SW2 и заполнять кэш, теперь в кэше у нас FastEthernet0/1 будет соответсвовать индекс 10002
4) получаем значение

Не пиши фигню - кэш привязан к хосту. Но то, что любой из свободных поллеров получает запрос на опрос динамического итема, делает walk и строит свой собственный кэш на время опроса - вот это и дает нагрузку.

Остается только умножить количество поллеров на количество итемов и количество индексов у железки - вот и будет количество SNMP запросов. И время жизни у этого кэша слишком короткое. Так что кэш в такой реализации - бессмысленен и беспощаден.

Да - логика реализации кэша не менялась между 2.0.11 - 2.2.1. У автора видать что-то другое мешается.

[strobil]

Конфигурацию итема покажи?

[romanwhite]

Мониторю порядка восьмисот параметров на коммутаторе CISCO4705 по SNMP. После обновления с 2.0.8 на 2.2.1 выросла нагрузка на процессор коммутатора c 13% до 86%. В конфигурации элемента данных в поле SNMP OID прописано:

.1.3.6.1.2.1.31.1.1.1.6["index",".1.3.6.1.2.1.2.2.2.1.2","GigabitEther net2/1"]

Аналогично на других портах. На других коммутаторах (с жесткой конфигурацией) где в это поле прописаны OID без индексов нагрузка на коммутаторы осталась на прежнем уровне.

[strobil]

Баг исправлен.

Fixed in pre-2.2.2 r42127 and pre-2.3.0 (trunk) r42128.