Я использую сервер WHM / cPanel на CentOS 6.6 с Apache 2.4 и PHP 5.5. Каждую неделю или около того загрузка ЦП будет увеличиваться до 100% на всех шести ядрах и оставаться на этом уровне до перезапуска Apache, после чего все возвращается в норму. Интересно, что Apache server-status страница не знает, что эти процессы существуют:
Верхний:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25901 nobody 20 0 1973m 28m 276 R 74.8 0.4 3:39.30 httpd
24861 nobody 20 0 1973m 28m 280 R 74.1 0.4 12:05.31 httpd
25076 nobody 20 0 1973m 28m 276 R 65.8 0.4 10:09.38 httpd
24727 nobody 20 0 1973m 28m 280 R 64.5 0.4 14:37.09 httpd
25874 nobody 20 0 1973m 28m 276 R 64.5 0.4 3:57.69 httpd
24747 nobody 20 0 1973m 28m 276 R 64.1 0.4 15:06.89 httpd
25998 nobody 20 0 1973m 28m 276 R 63.8 0.4 2:40.92 httpd
25624 nobody 20 0 1973m 28m 276 R 61.8 0.4 5:28.76 httpd
25646 nobody 20 0 1973m 28m 276 R 58.8 0.4 5:07.88 httpd
Страница статуса:
Server Version: Apache/2.4.12 (Unix) OpenSSL/1.0.1e-fips mod_bwlimited/1.4
Server MPM: event
Server Built: Mar 27 2015 11:20:11
Current Time: Tuesday, 09-Jun-2015 09:21:07 CDT
Restart Time: Tuesday, 02-Jun-2015 11:38:37 CDT
Parent Server Config. Generation: 12
Parent Server MPM Generation: 11
Server uptime: 6 days 21 hours 42 minutes 30 seconds
Server load: 8.17 7.35 10.46
Total accesses: 461541 - Total Traffic: 10.7 GB
CPU Usage: u111.81 s369.94 cu305989 cs438.15 - 51.4% CPU load
.774 requests/sec - 18.7 kB/second - 24.2 kB/request
7 requests currently being processed, 118 idle workers
PID Connections Threads Async connections
total accepting busy idle writing keep-alive closing
21715 1 yes 1 24 0 1 0
4766 0 yes 0 25 0 0 0
10222 0 yes 0 25 0 0 0
10278 6 yes 6 19 0 0 0
10194 0 yes 0 25 0 0 0
Sum 7 7 118 0 1 0
_____________________W__________________________________________
_____________W__W____W____W_W___W___.........................___
______________________
Ни один из запросов, представленных на странице состояния Apache, не представляет интереса, что имеет смысл, поскольку не указаны никакие PID, загружающие процессор. Использование памяти, дисковый ввод-вывод и сетевой трафик остаются относительно стабильными, и проблема не возникает в определенное время суток. На этом сервере есть десятки небольших сайтов, что затрудняет ручной поиск в журналах доступа.
Что может быть причиной этого? Я просто неправильно понимаю, как Apache сообщает данные? Есть ли лучший способ отследить ответственный процесс и увидеть, что он на самом деле делает?
Вы можете использовать утилиту отладки "strace" с PID, перегружающим процессор, чтобы увидеть причину этого. Это может указать вам на проблему, strace -p <PID>
Возможны 2 причины:
Резервное копирование - процесс резервного копирования cPanel немного тяжелый, поэтому сначала проверьте, начинается ли загрузка Apache через секунды / минуты после запуска процесса резервного копирования.
Массовые обновления - более вероятно; Каждый день и каждую неделю cPanel загружает огромное количество различных обновлений и проверок, а во время обновлений запускает множество странных внутренних тяжелых программ, включая верификатор лицензий, что иногда вызывает проблемы у некоторых пользователей.
К сожалению, Apache cPanel привязан к тяжелым сценариям cPanel CGI, которые выполняют некоторые части этих обновлений и проверок. Исходя из моего опыта cPanel, я уверен, что именно эти сценарии CGI несут ответственность за ваши проблемы Apache из-за тупиковых ситуаций, вызванных взаимодействием между ними и заданиями cron.
Чтобы проверить обе эти причины, отключите задания cron одно за другим, запустив его от имени пользователя root:
crontab -e
Попробуйте отключить сразу только одну службу и подождите неделю, пока не увидите следующую высокую загрузку ЦП или не найдете проблемную.
Вы пробовали установить LogLevel debug и проверить файлы {access, error} _log на наличие подсказок?
Недавно мне пришлось что-то отлаживать и в apache2. Мне помогло остановить службу apache2 и запустить ее вручную, используя:
# strace -f -s 1024 -o /tmp/httpd.strace /usr/local/apache/bin/httpd -k start -DSSL -X
Я взял полную командную строку из вашего JSFiddle и просто добавил -X возможность включить режим отладки.
Как только вы попадете в ту же ситуацию, вы можете посмотреть на /tmp/httpd.strace для подсказок. Может быть полезно использовать strace-graph /tmp/httpd.strace чтобы увидеть, какие подпроцессы были вызваны во время выполнения strace.
используйте PPID ошибочных процессов, чтобы отследить родителя. Я подозреваю, что у вас работает два разных демона apache. Кажется вероятным, что CPanel может делать это для того, чтобы иметь возможность делать что-то от имени пользователя root, но я заметил, что процессы не являются пользователем. Может быть, у вас есть облегченный apache, который обрабатывает входящие запросы и передает их второму apache, выполняющему более тяжелые процессы mod_php? Возможно, здесь что-то еще происходит, но ваша первая задача - выяснить, что это за процессы apache. Вы видите две отдельные конфигурации apache?
lsof может пригодиться. Вы получите информацию о том, какие файлы журналов открыты данным процессом apache и какие номера портов он прослушивает.
Предполагая, что я прав в этом, вероятно, прослушивание на другом порту, может быть полезно настроить что-то для захвата трафика на этом порту, чтобы вы могли видеть, что вызывает ситуацию с высокой загрузкой процессора. Скорее всего, нет ничего страшного в том, чтобы просто оставить tcpdump записывать весь этот трафик в файл, хотя вам следует контролировать дисковое пространство на случай, если оно окажется неожиданно большим.
Интересно, что перезапуск apache действительно работает. МАЙБЕ, я ошибаюсь в том, что есть два apache, или, возможно, между экземплярами apache могут быть перенаправлены запросы.
sudo netstat -plnt может быть интересно. Он покажет вам, какие процессы и pid связаны с каждым портом прослушивания. Если есть два апача, ты их там найдешь. ps wwuaxf или pstree также покажет вам процессы apache, сгруппированные по родительскому процессу. Вы увидите аргументы командной строки
РЕДАКТИРОВАТЬ: дополнительно после комментария от OP.
Потомки процесса init - это либо отдельные запущенные экземпляры apache, либо, возможно, зомби-процессы, которые по какой-то причине не собираются. В этом случае родительский процесс умер, но дети не смогли быть остановлены и были перемещены в процесс init в качестве родительского.
Высокий процессор может быть чем-то вроде повторяющихся попыток поговорить с отсутствующим родительским процессом, хотя в этом случае он, вероятно, появится с помощью strace. Я бы внимательно посмотрел, что происходит при перезапуске apache.
Остались ли запущенными какие-то старые процессы? Есть ли у вас хорошие записи, когда включается высокая загрузка процессора? (возможно, используйте sar, munin, и kSar хорошо сочетается с sar, в противном случае на выходе будут только текстовые таблицы). Можете ли вы соотнести это с перезапуском apache? (Например, перенос журнала за ночь или ручные действия). Возможно, вы сможете определить связь, когда что-то еще происходит в вашей системе. Если это происходит каждый раз в одно и то же время, это очень полезно для отслеживания вещей.