Вопрос по загрузке poller'ов

[rahs]

Здравствуйте

Вопрос по графику занятости процесса сбора данных. Почему загрузка процессов регулярно прыгает до 100%? И нельзя ли настроить более равномерный сбор данных?

[yukra]

StartPollers в конфиге сервера увеличьте.

[sadman]

Не загрузка процессов, а количество занятых проверками пулеров. Пассивная проверка => занятый пулер. Много пассивных проверок - много занятых пулеров.

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

[rahs]

Не загрузка процессов, а количество занятых проверками пулеров

Да, точно. Думаю одно, пишу другое

Мониторятся в основном коммутаторы по snmp, так что активные проверки отпадают. Пулеров максимум, 255.

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

[sadman]

Да, точно. Думаю одно, пишу другое

Мониторятся в основном коммутаторы по snmp, так что активные проверки отпадают. Пулеров максимум, 255.

Хм...

### Option: StartPollers
#       Number of pre-forked instances of pollers.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartPollers=5

Судя по исходникам, 1000 - это искусственное ограничение. Переменные там типа int. Можно, наверное, прямо в server.c подправить. Единственный скользкий момент, который вижу с наскока:

 threads_num = CONFIG_CONFSYNCER_FORKS + CONFIG_WATCHDOG_FORKS + CONFIG_POLLER_FORKS
                        + CONFIG_UNREACHABLE_POLLER_FORKS + CONFIG_TRAPPER_FORKS + CONFIG_PINGER_FORKS
                        + CONFIG_ALERTER_FORKS + CONFIG_HOUSEKEEPER_FORKS + CONFIG_TIMER_FORKS
                        + CONFIG_NODEWATCHER_FORKS + CONFIG_HTTPPOLLER_FORKS + CONFIG_DISCOVERER_FORKS
                        + CONFIG_HISTSYNCER_FORKS + CONFIG_ESCALATOR_FORKS + CONFIG_IPMIPOLLER_FORKS
                        + CONFIG_JAVAPOLLER_FORKS + CONFIG_SNMPTRAPPER_FORKS + CONFIG_PROXYPOLLER_FORKS
                        + CONFIG_SELFMON_FORKS + CONFIG_VMWARE_FORKS;
        threads = zbx_calloc(threads, threads_num, sizeof(pid_t));

Т.е. threads_num тоже int, нужно это учитывать. Ну и следить, чтобы хватило ресурсов под треды.

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

В резонанс входит

Попробуйте на разные хосты задавать проверки через некруглые промежутки. Например - 38sec, 51sec, 125 sec. Мне кажется, что так должно размазать нагрузку на пулеры - они там в loop-е крутятся. Конечно за счет неравномерности времени проверок ваш график уже должен быть размазан, но на энтропию немножечко можно повлиять.

[rahs]

Хм...

### Option: StartPollers
#       Number of pre-forked instances of pollers.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartPollers=5

# Number of pre-forked instances of pollers
# Default value is 5
# This parameter must be between 0 and 255
StartPollers=255

Опять у меня конфиг устарел...

Попробуйте на разные хосты задавать проверки через некруглые промежутки. Например - 38sec, 51sec, 125 sec. Мне кажется, что так должно размазать нагрузку на пулеры - они там в loop-е крутятся. Конечно за счет неравномерности времени проверок ваш график уже должен быть размазан, но на энтропию немножечко можно повлиять.

Это как? Все коммутаторы к одному шаблону приделаны, а большинство итемов через lld находятся

И график не размазан.

[sadman]

Это как? Все коммутаторы к одному шаблону приделаны, а большинство итемов через lld находятся

Это на уровне гипотезы предположение. В реальности значимого выигрыша может и не быть. На вопрос "как" могу ответить предложением опрашивать fa0/1 через 31sec, fa0/2 через 32sec и т.д. Никакого способа сдвинуть проверку относительно некоего начала цикла, который прослеживается на графике, я не вижу.

[rahs]

Обновился до 2.2.7, указал в настройках EnableSNMPBulkRequests=0

Итог: