poller process 75%

[moydedushkarembo]

всем привет
постоянно крутится загрузка
Zabbix poller processes more than 75% busy
при этом остальные полеры имеют низкую загрузку


о моих настройках:

Скрин data gathering process by:

http://files.webfile.ru/60c1f932e7a416fbec99c3ed25647ab1

Требуемое быстродействие сервера, новые значения в секунду 529.8

в zabbix_server.conf:
StartPollers = 500 (уже сколько не добавляли, нагурзка все равно не падает)
StartPingers = 200
TimeOut = 30

[moydedushkarembo]

Скрин статуса базы из MySQL Workbench
Скачать2014-11-26_11-03.jpg

размер базы порядка 200мб

в my.conf
innodb_buffer_pool_size = 1300M

[sadman]

Можно предположить, что железки не успевают отвечать на запросы и пулеры подвисают. Я бы попереключал айтемы в режим активных проверок, снизил периоды проверки...

[moydedushkarembo]

Можно предположить, что железки не успевают отвечать на запросы и пулеры подвисают. Я бы попереключал айтемы в режим активных проверок, снизил периоды проверки...

не понял вот эту часть - попереключал айтемы в режим активных проверок...

[sadman]

Имеется в виду это.

https://www.zabbix.com/documentation/2.0/ru/manual/appendix/items/activepassive

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

[trv1171]

Такая же проблема, после перехода с 2.2.7 на 2.4.2.

Использую пассивные проверки: Опрос 1000+ устройств по SNMP. При тайм-ауте в 3 сек. Сыплются ошибки: became not supported: Invalid SNMP response: too few variable bindings
Зато поллер спокоен, как удав. Занятость выше 30% не поднимается. Если увеличиваю тайм-аут до 7-10 сек. занятость поллеров улетает в 100%. А то и вовсе перестает считываться.

В версии 2.2.7 - в конфиге была опция - EnableSNMPBulkRequests которую можно было выключить. В результате отключения BulkWalk занятость поллеров приходила в норму. Правда зверски росло количество соединений(у меня зашкаливало за 65536)

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

Теперь, собственно, вопрос: Существует ли возможность в версии 2.4.х отключить эту опцию глобально?

[sersad]

Уже писал

https://www.zabbix.com/forum/showpost.php?p=157616&postcount=17

[trv1171]

Грубо..

Хотелось бы как-нибудь поизящнее.. До такого безобразия я и сам дошел. Только через свою API-шную поделку. Она у меня еще и выборочно позволяет параметры менять..

Я понадеялся на како-нибудь более изящное решение.


А как, например, при автообнаружении отключать bulk? Также скриптом? По-умолчанию порт создается с установленным флагом, зараза.

[moydedushkarembo]

Можно предположить, что железки не успевают отвечать на запросы и пулеры подвисают. Я бы попереключал айтемы в режим активных проверок, снизил периоды проверки...

в основном у меня интервал обновления - 60 секунд. разве это много?

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

[trv1171]

В моем случае - массовое отключение BulkWalk принесло свои плоды. Загрузка поллеров упала до 18% (запущено 400). Железки не подвисают, это точно. Скорее всего железки в какие-то моменты времени просто задерживают отдачу bulk запроса. Это нормально, поскольку snmp не является высокоприоритетным процессом в железе. А вот поллерам этот тайм-аут оказывается смертельным. И, в случае короткого тайм-аута, получаем в лог вот такую заяву:
11385:20141126:172707.060 item "xxxxxxxxxxxx:ifAdminStateFE.[37]" became not supported: Invalid SNMP response: too few variable bindings.
А в случае длинного тайм-аута получаем лавинообразный прирост занятых поллеров. Куда ни потяни - одеяло короткое.

Выходом мне видится - либо отключение(Сокращение bulk запросов, в особенности на старое железо) либо установка различных периодов опроса железа, для исключения лавинообразного роста.

Возможна, конечно, проблема и с БД, но для этого существует мониторинг самого заббикс сервера. А также хорошая вещь - iotop.

Но это уже частности.

[sadman]

в основном у меня интервал обновления - 60 секунд. разве это много?

Для одного айтема - немного, а для сотни snmp без bulk request?

однако смущает то, что высокое значение только у одного типа полеров, а не у всех

Вообще-то, насколько я могу судить из кода, для опроса железок отдельно выделяются и форкаются только JAVA/IPMI/HTTP пулеры. Для всех остальных нужд (SSH, DB, Simple, вычисляемые (?), медленный SNMP, и т.д.), используется группа, задаваемая параметром StartPollers. Пингер не используют пулеры. Так что, как правильно заметили выше, медленный ответ по SNMP вполне может привести к резкому исчерпанию форкнутых тредов.

Впрочем, я не настоящий сварщик ))

Странно только то, что нагрузка не меняется при увеличении пулеров - тут и диск уже может не справляться, теоретически, при >500 значениях.

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

[svyaznoy]

Возникла аналогичная проблема. Я не понял одного момента. Может кто-нибудь на пальцах объяснить, что такое пуллеры и что в целом означает данное сообщение Zabbix poller processes more than 75% busy ?

[trv1171]

Пуллеры - это процессы запускаемые заббиксом для пассивных проверок( я так сам понял, и пусть меня поправят если я не прав) как то snmp опросы, внутренние проверки иТП. Далее все зависит от опрашиваемых железок и работы сети. Если опрашиваемое оборудование отвечает долго, а проверок много то количество занятых поллеров растет. Причем при этом нагрузки на процессор не будет. Так как фактически все запущенные процессы просто висят в ожидании ответов. Уменьшение тайм-аута ожидания снизит занятость поллеров но приведет к недополучению данных с устройств.

[Zentarim]

В моем случае - массовое отключение BulkWalk принесло свои плоды. Загрузка поллеров упала до 18% (запущено 400). Железки не подвисают, это точно. Скорее всего железки в какие-то моменты времени просто задерживают отдачу bulk запроса. Это нормально, поскольку snmp не является высокоприоритетным процессом в железе. А вот поллерам этот тайм-аут оказывается смертельным. И, в случае короткого тайм-аута, получаем в лог вот такую заяву:
11385:20141126:172707.060 item "xxxxxxxxxxxx:ifAdminStateFE.[37]" became not supported: Invalid SNMP response: too few variable bindings.
А в случае длинного тайм-аута получаем лавинообразный прирост занятых поллеров. Куда ни потяни - одеяло короткое.

Выходом мне видится - либо отключение(Сокращение bulk запросов, в особенности на старое железо) либо установка различных периодов опроса железа, для исключения лавинообразного роста.

Возможна, конечно, проблема и с БД, но для этого существует мониторинг самого заббикс сервера. А также хорошая вещь - iotop.

Но это уже частности.

БД тут не при чем. Если вам помогло отключение bulk - значит проблема в железках, и, скорее всего, в количестве значений, которое железо может обработать в одном запросе. Если вы оставите 5-10 элементов данных, то даже со включенным bulk у вас все должно обрабатываться нормально.

Кстати, что у вас за железо?

[trv1171]

Железо - в основном D-Link. Снятый с производства в 07 году... Нагрузку создавали именно они.
Мониторить меньше 50 значений с каждого не получается. А Bulk запросы, как я и говорил чуть выше, обрабатываются этим железом медленно. Естественно, если перестать мониторить чего-либо совсем, то нагрузка совсем в "0" упадет. Но Сервис мониторинга "самого себя" как-то не нужен.

В итоге, для решения проблемы высокой занятости поллеров необходимо, при переходе со старого zabbix на новый для всего старого железа снять bulkwalk. Либо, в zabbix версии 2.2.7 - отключать bulkwalk в конфигурации.

К разработчикам - хорошо было-бы автоматически отключать этот параметр при работе с snmp v1(Есть , оказывается и такое). Например в этом же форуме есть пост про многофункциональные датчики ERD.