У меня есть сервер NagiosXi, который отслеживает 631 службу на 63 хостах. Каждые семь часов нагрузка на сервер увеличивается до 20, а затем постепенно падает почти до нуля.
Задания cron не выполняются каждые 7 часов.
Сервер имеет 8 ядер и 2 ГБ оперативной памяти. Оперативная память не является проблемой, во время всплесков она по-прежнему составляет 1 ГБ, и увеличение ее до 4 ГБ не имеет значения. Сервер также был перенесен на новый хост около недели назад без изменений.
Мы также запланировали простои на 17 отслеживаемых хостах, поэтому они отслеживаются только с 6:00 до 18:00 с понедельника по пятницу, это, кажется, не имеет никакого значения для скачков нагрузки.
Большинство проверок выполняется на серверах Windows с использованием check_wmi_plus.
Во время скачков нагрузки я обычно вижу 5-8 случаев check_wmi_plus.pl с использованием 2-3% ЦП, и несколько процессов httpd, использующих то же самое, но ничто не выделяется, как использование большого количества ЦП. Эти процессы также переносятся довольно быстро, поэтому они не зависают и не занимают необычно долгое время. Время выполнения проверки службы в NagiosXi Performance Monitor имеет тенденцию к пику ~ 5,5 с, в среднем около 1 с.
Может ли кто-нибудь предложить возможную причину или как я могу решить эту проблему?
Высокая нагрузка НЕ обязательно означает, что вы используете высокие уровни ЦП, только она обеспечивает только количество процессов в моментальном снимке, которые готовы к запуску и получению времени ЦП, но не его количество.
Nagios действительно быстро запускает множество процессов в зависимости от того, как вы установили его расписания мониторинга, и иногда вызывает всплеск, поскольку он запускает множество процессов, выполняющихся как можно быстрее, но они могут не требовать очень много ЦП или немедленно переходить в состояние сна / ожидания.
Кстати, если вы отключите УВЕДОМЛЕНИЯ в Nagios, это не остановит его от продолжения мониторинга данного хоста или службы.
это связано с тем, как ядро рассчитывает нагрузку. см. источник: https://github.com/torvalds/linux/blob/master/include/linux/sched/loadavg.h и вы получите что-то вроде этого:
#define LOAD_FREQ (5*HZ+1)
LOAD_FREQ - это интервал, в течение которого ядро собирает нагрузку на процессор. Обратите внимание, что есть небольшой сдвиг со значением 0,001 с. Таким образом, для возврата к кратному 5 секундам требуется 5 * 1000 * 5,001 секунды. 25005/3600 - около 7 часов.
поэтому я готов поспорить, что система периодически формирует короткие задачи и просто "ловится" ядром каждые 7 часов.
Уменьшите настройки prefork по умолчанию для rhel / centos по умолчанию /etc/httpd/conf/httpd.conf к чему-то более реалистичному.
Используйте такие инструменты, как apachebuddy.pl и apachetuner.sh, чтобы вычислить память для каждой вилки процесса. разрешить больше памяти для других процессов в системе (mysql / postgresql / php) и уменьшить MaxClient и MaxRequestChild.
Я испытал это после обновления до 2014R1.1 с 2012R2.9. не уверен, требует ли последняя версия XI2014 дополнительных ресурсов для веб-интерфейса.
Этим утром, снизив свои настройки, я заметил, что мои скачки нагрузки стали меньше, и при навигации по интерфейсу у меня не появляется серое несчастное лицо, использующее кнопки вперед и назад в браузере. кажется ли эта странность в интерфейсе похожей?
Последний пункт, на который я сейчас обращаю внимание, - это то, какие модули rhel необходимы в этом файле httpd.conf по умолчанию. Не вижу смысла загружать модули по умолчанию, если они не нужны. Этот сервер является корпоративным сервером PROD в моем офисе с тысячами проверок, поэтому он должен быть надежным.
ОБНОВИТЬ:
бегать
\# service mysqld stop
\# sh /usr/local/nagiosxi/scripts/repair_databases.sh
\# service mysqld start
или оптимизируйте таблицы в режиме онлайн с помощью
\# mysql -u root -p
mysql> use nagios;
перечислите свои столы
mysql> show tables;
затем
mysql> optimize table $TABLENAME;
mysql> optimize table $TABLENAME;
mysql> optimize table $TABLENAME;
...
mysql> use nagiosql;
**list your tables**
mysql> show tables;
затем
mysql> optimize table $TABLENAME;
mysql> optimize table $TABLENAME;
mysql> optimize table $TABLENAME;
...
сделайте это для всех таблиц.
Если вы можете остановить службу на пару минут, сделайте это через скрипт nagiosxi. если вы не можете сделать это позже ... сделайте это онлайн, но ожидайте, что интерфейс будет немного медленным, пока запросы не будут выполнены повторно. Также может быть полезно очистить кеш запросов
mysql> FLUSH QUERY CACHE;
http://assets.nagios.com/downloads/nagiosxi/docs/Repairing_The_Nagios_XI_Database.pdf