При апгрейде до 7.0.9 нагружается cpu некоторых машин

[avolokitin]

Приветствую!
Тестирую апгрейд версии имеющегося сервера 5.0, попробовал на тестовом сервере поэтапный переход 5.0->6.0->7.0, наткнулся на значительное увеличение нагрузки на CPU опрашиваемого хоста при переходе с 6.0 на 7.0.
Проблема ярко проявляется на конкретном хосте, всего хостов ~250. На проблемном хосте размещается десяток сервисов, которые опрашиваются python-скриптом через userparameter с интервалом в 1m, на сервер летит ~35 метрик от каждого сервиса. Параметры хоста: cpu xeon e3-1230 4c/8t, 32G ram.
При использовании версии сервера 6.0.38 load average ~4 на проблемном хосте, при апгрейде сервера до 7.0.9 load average проблемного хоста постепенно уходит в облака, вероятно, по причине использования асинхронного поллинга и формирования бесконечной очереди задач.
В конфиге сервера выставлены StartPollers=100 Timeout=20.
Numder of items: ~200k. Number of triggers: ~55k. New values per second при апгрейде увеличивается с ~800 до ~2900.
Агент zabbix_agent2 6.0.29, отдаёт данные на оба сервера.
Понятно, что скрипты почти наверняка работают не оптимально, но вопрос их оптимизации хотелось бы вынести за рамки апгрейда версии сервера.
Пока попробовал указать в конфиге сервера MaxConcurrentChecksPerPoller=20. Это позволяет получить la ~6 на проблемном хосте, при этом last check со временем растёт за пределы 10 минут. Если поднимать MaxConcurrentChecksPerPoller, то на проблемном хосте (и ещё ряде машин с похожей схемой опроса сервисов скриптами) заканчивается cpu, а если MaxConcurrentChecksPerPoller снижать, то задержки обновления метрик растут вплоть до объявления сервисов упавшими, агентов недоступными и т.д.
Как действовать, чтобы добиться от версии сервера 7.0 политики опроса без повышенной нагрузки на cpu опрашиваемого хоста, подобно 6.0?

[PavelZ]

Не вполне логичиная схема складывается.
Как раньше сервер успевал опрашивать, но при этом не генерировал нагрузку ?

New values per second при апгрейде увеличивается с ~800 до ~2900.

А это, как вы догадываетесь, подразумевает что итемов просто добавилось. Может бы Auto discovery включился после обновления вручную каких-то шаблонов. Или обычных итемов в шаблонах обновилось.

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

[avolokitin]

Я тоже удивился.
Для ясности: 315 метрик, получаемых через запуск python-скрипта, в случае сервера 5.0.16 и 6.0.38 приходят без задержек и не оказывают заметной нагрузки на хост. Опрос ведётся двумя серверами одновременно, продовым и тестовым.
Если тестовому серверу апгрейднуть версию до 7.0.9, то цпу опрашиваемого хоста постепенно погружается в аут через бесконечный рост la. При ограничении конкурентных проверок на уровне 20 нагрузка на цпу тоже вырастает (на ~20-25%), но при этом на сервере растёт задержка получения данных с остального парка.
Иначе говоря, до 7.0 LTS проблемы нет, а с ним она появляется.
Пока нужды в прокси не возникало, но рассмотрю такой вариант, спасибо.
Хотелось бы удостовериться, что нет иных вариантов решения.
P.S. кол-во итемов/триггеров не меняется с апгрейдом, только nvps растёт почти втрое.

[Kos]

Как я понимаю, проверки у вас имеют тип "Zabbix агент (пассивный)"? Не пробовали переводить их на активный режим?
Zabbix агент (традиционный, вариант 1) использует один фоновый процесс для всех активных проверок на один Zabbix сервер, т.е. активные проверки от одного сервера всегда выполняются последовательно (не одновременно); про Zabbix агент 2 не уверен (там были некоторые отличия в архитектуре).