У нас есть сервер CentOS 6.9 с 4-ядерным процессором и 32 ГБ оперативной памяти.
Ежедневно примерно в одно и то же время средняя нагрузка постепенно меняется с 0.0 вплоть до 11 когда нам, наконец, придется перезапустить сервер.
CPU: Иногда всплески, когда такие процессы, как spamd, fail2ban, занимают несколько секунд, чтобы что-то сделать. В противном случае это около 1%. Некоторое время php тоже занимает> 50% ЦП. Большую часть времени он простаивает не менее 70%.
I/O : Операций ввода-вывода не так много, но иногда mysqld занимает 99,5% операций ввода-вывода.
RAM: всегда в допустимом диапазоне.
Bandwidth : мало что меняется с течением времени. Приемлемый диапазон.
Disk Space: Более 1 ТБ свободного места.
AV: Выполнил clamd и другие инструменты, некоторые из которых были обнаружены в установке WordPress. Сейчас удалено.
Даже при низком уровне средняя нагрузка продолжает расти, сервер становится слишком медленным, чтобы что-либо делать, и мы вынуждены перезапускаться. Потом дела идут нормально.
Это не проблема cronjob, как я тоже думал из-за обычной процедуры, это должен быть cron. Так что я использовал service crond stop и остановил его за несколько часов до начала лага. Лаги все равно случаются.
Во время высокой средней нагрузки выполняется множество процессов. Некоторые из них: несколько mysqld, ../bin/suexec 501 501 php5, /bin/php, /fail2ban процессы
Я также получаю много писем с сервера, в которых говорится System Load Alert 1 for mysite.com
Поскольку это происходит регулярно в одно и то же время, проблема с оборудованием не кажется причиной.
Мой вопрос: что еще я могу проверить, чтобы решить эту проблему? Я ставил все свои фишки на cronjob.
Обновление 1: пространство подкачки: проверено с помощью sar -W -f /var/log/sa/sa15 Все значения равны 0. free -h получил
total used free shared buffers cached
Mem: 16G 2.9G 13G 18M 0B 1.4G
-/+ buffers/cache: 1.4G 14G
Swap: 0B 0B 0B
Получается, что места для подкачки нет, но с таким объемом свободной оперативной памяти я сомневаюсь, что он нам действительно нужен.
Обновление 2: проверено с помощью iotop скорость записи / чтения увеличилась до 250 КБ / с за несколько секунд, вот и все.
Результат операции ввода / вывода во время замедления с использованием iotop -aoP :
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1508 be/4 root 7.88 M 24.00 K 0.00 % 1.32 % perl -T -w /usr/local/cpanel/3rdparty/bin/spamd --max-spare=1 --~llowed-ips=127.0.0.1,::1 --pidfile=/var/run/spamd.pid --listen=5
9288 be/4 root 248.00 K 16.00 K 0.00 % 2.42 % tailwatchd - chkservd - spamd check
1714 be/4 root 0.00 B 4.00 K 0.00 % 0.24 % queueprocd - wait to process a task
5610 be/4 root 8.00 K 152.00 K 0.00 % 0.03 % tailwatchd
1446 be/4 mysql 8.79 M 256.00 K 0.00 % 0.02 % mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr~0 --pid-file=/var/lib/mysql/..
Результат find /proc/*/task/. -name stat -exec grep ' D ' {} \; сильно разнится, иногда нет ничего, иногда разные процессы. Я опубликую те, которые случаются, когда средняя загрузка действительно высока, около 18:
1585 (fail2ban-server) D 1 1575 1575 0 -1
16943 (cpsrvd (SSL) - ) D 1 16943 16942 0 -1
17221 (tailwatchd) D 1 17220 17220 0 -1
17255 (nginx) D 17253 17253 17253 0 -1
18102 (mysqld) D 17491 17479 12176 3482 0 -1
18355 (mysqld) D 17491 17479 12176 3482 0 -1
18099 (httpd) D 18087 18087 18087 0 -1
18127 (httpd) D 18087 18087 18087 0 -1
18312 (exim) D 1 17295 17295 0 -1
18375 (php) D 18096 18087 18087 0 -1
18379 (exim) D 18368 18368 18368 0 -1
18408 (find) D 18144 18107 18107 0 -1
18410 (suexec) D 18095 18087 18087 0 -1
В моем случае в качестве сервера раньше были вредоносные файлы. Может копия кеша осталась.
Очистка веб-сайта и кеширования сервера решила проблему.