Высокая нагрузка на процесс escalator

[bga83]

Изначально было замечено, что уведомления о проблемах/восстановлении несколько запаздывают несмотря на то что в действиях выставлена немедленная реакция.
В итоге нашел, что процесс escalator постоянно нагружен на 100%(на графике из вложения видно). Если по ряду остальных типов процессов все понятно как снижается на них нагрузка(путем изменения количества запускаемых процессов того или иного типа в конфиге сервера) то с escalator не понятно как поступать.
Собственно вопросы:
- есть идеи как попытаться снизить снизить его нагрузку
- может ли ли быть такое поведение вызвано большой нагрузкой на хаускипер


Система развернута на CentOS 6.5 + Mysql 5.6.19 +Zabbix Server 2.2.1

[yukra]

Изначально было замечено, что уведомления о проблемах/восстановлении несколько запаздывают несмотря на то что в действиях выставлена немедленная реакция.
В итоге нашел, что процесс escalator постоянно нагружен на 100%(на графике из вложения видно). Если по ряду остальных типов процессов все понятно как снижается на них нагрузка(путем изменения количества запускаемых процессов того или иного типа в конфиге сервера) то с escalator не понятно как поступать.
Собственно вопросы:
- есть идеи как попытаться снизить снизить его нагрузку
- может ли ли быть такое поведение вызвано большой нагрузкой на хаускипер


Система развернута на CentOS 6.5 + Mysql 5.6.19 +Zabbix Server 2.2.1

Че как эскалируете? почта или свои скрипты? если почта, то через локальный MTA или внешний? если внешний, то через свой или сторонний? А если сделать

strace -p `ps aux | grep '[z]abbix_server: escalator' | awk '{print $2}'`

так??

[ableev]

Эскалации обрабатываются последовательно. Учитывайте, если хотите рассылать кучу писем/смс.

Селектить из базы умеете?
Тогда рекомендую посмотреть, где затык:

SELECT COUNT(*), ac.name AS action_name, mt.description AS media_type FROM alerts al
JOIN actions ac ON al.actionid = ac.actionid
JOIN media_type mt ON al.mediatypeid = mt.mediatypeid
WHERE al.status = 0
GROUP BY ac.name, mt.description
ORDER BY 1 DESC;

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

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

Поэтому, если у вас именно проблема в обработке большого количества информации, то советую пересмотреть их нужность таким образом.

По поводу хаускипера – сомневаюсь. У самого хаускипер подолгу работает, проблем с нотификациями нет.

В общем, начните с того, что же у вас накапливается.

[bga83]

в общем нашел причину, может кому в будущем поможет. Помогла именно идея с strace. Оказалось, что база в мускуле размещалась не в системном raw-тейбспейсе, а была активна опция innodb_file_per_table., и таблицы оказались на более медленном разделе. Сейчас картинка следующая:

И проблем с уведомлениями больше нет, во всяком случае пока. Вылез правда и отрицательный момент - почему-то подрос iowait, в среднем сейчас ~18%, по видимых минусов не дает