Узнайте, что на самом деле делает процесс Apache с высокой загрузкой процессора?


18

В настоящее время у нас есть несколько проблем с нашим сервером, из-за которых периодически появляются процессы apache, которые просто запускаются и работают, занимая 100% ЦП.

При запуске top мы видим следующее:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
20788 www-data  20   0  318m  18m 3984 R  100  0.0  40:29.21 /usr/sbin/apache2 -k start
23523 www-data  20   0  319m  20m 4684 R  100  0.0   4:12.36 /usr/sbin/apache2 -k start

Я хочу попытаться выяснить, что сценарий (или что-то еще) вызывает это, поэтому я попытался:

 strace -p 20788

Но это не показывает никакого вывода вообще (я оставил это в течение приблизительно 10 минут, и это ничего не показывает). Насколько я понимаю, это может означать, что он застрял в бесконечном цикле, и нет никаких «системных вызовов», чтобы показать.

Могу ли я еще что-нибудь сделать, чтобы показать, что происходит?

Благодарность

Изменить - Забыл упомянуть, это живой сервер с несколькими сотнями пользователей одновременно! Поэтому я не могу просто попробовать изменить параметры конфигурации и перезапустить apache.

Редактировать 2 - обратная трассировка (bt) из gdb, кажется, не так уж и полезна, когда PHP не настроен с --enable-debug - он показывает только «execute ()», но мне нужно знать, что такое PHP-скрипт на самом деле работает .. есть ли другой способ?

#0  0x00007f6c143fb0c5 in ?? () from /usr/lib/apache2/modules/libphp5.so
#1  0x00007f6c143b040b in execute () from /usr/lib/apache2/modules/libphp5.so
#2  0x00007f6c1438b970 in zend_execute_scripts () from     /usr/lib/apache2/modules/libphp5.so
#3  0x00007f6c14337fe3 in php_execute_script () from     /usr/lib/apache2/modules/libphp5.so
#4  0x00007f6c1441ae7d in ?? () from /usr/lib/apache2/modules/libphp5.so
#5  0x00007f6c18912508 in ap_run_handler ()
#6  0x00007f6c1891297e in ap_invoke_handler ()
#7  0x00007f6c18922570 in ap_process_request ()
#8  0x00007f6c1891f398 in ?? ()
#9  0x00007f6c18918fa8 in ap_run_process_connection ()
#10 0x00007f6c189271d0 in ?? ()
#11 0x00007f6c1892793a in ?? ()
#12 0x00007f6c189284e7 in ap_mpm_run ()
#13 0x00007f6c188fd4a4 in main ()

1
Apache поддерживает «изящный» перезапуск, так почему бы и нет?
Пой

1
Я думаю, что когда мы попробовали это ранее, он не мог перезапуститься из-за «зависших» процессов apache ... хотя это могло быть неправильно, это было некоторое время назад.
BT643

Другой трюк - запустить другой экземпляр apache на другом порту, перенаправив на него новые соединения.
Пойдж

Ответы:


9

Ну, если ты чувствуешь себя смелым

gdb -p 20788

затем выполните btкоманду, чтобы увидеть кадр стека, например,

И кстати, есть также ltraceупомянуть - попробуйте это тоже.

UPD. : ну хорошо, так как теперь у нас есть идея, что Apache действительно что-то запускает, почему бы вам не посмотреть на mod_statusвывод - Extended ?


GDB не установлен :( придется подождать, пока я не вернусь на работу завтра, чтобы посмотреть, смогу ли я установить его, не вызывая каких-либо проблем .. ltraceтоже не показывал никаких результатов.
BT643

Просто добавил результаты из gdb bt в первоначальный пост ... на самом деле мне это мало что говорит!
BT643

О, рад видеть, что я предложил правильное направление. )
Пой

@ BT643, см. UPD.
Пой

4
Реализованный mod_status уже был включен по умолчанию, доступ к нему был ограничен 127.0.0.1. Я только что вошел через SSH и передал вывод в файл curl domain.com/server-status > randomfile.html- затем просмотрел файл. Оказалось, что это был старый код разработчиков, застрявший в цикле (файл PHP)! Все отсортировано сейчас. Спасибо за помощь :)
BT643

2

Очень простой подход заключается в использовании htop. Вы можете отсортировать процессы с высокой загрузкой процессора, а затем использовать

  • s для straceпроцесса
  • л, lsofчтобы увидеть открытые файлы процессов
  • Л к ltrace.

Я обнаружил, что по крайней мере одна из этих опций находит скрипт, который генерирует нагрузку, и вы, конечно, можете использовать его на рабочем веб-сервере для отладки.


1

Вы можете попробовать:

  • iotop (показывает ввод / вывод в системе)
  • netstat -t (показывает соединения)
  • Взгляните на лог-файлы apache и узнайте, что сервер делал последним
  • установить некоторые RLimits для процесса apache. Когда эти пределы достигнуты, процесс будет убит, давая вам больше информации

0

Ваша команда должна работать при условии, что вы делаете HTTP-запрос, который запускает этот PID.

Может быть, вы хотите временно перенастроить Apache только с одним дочерним процессом?


Помните, что только один дочерний процесс означает, что Apache может обслуживать только один запрос, и если этот единственный дочерний процесс застрянет, Apache не сможет обслуживать любые запросы.
Стефан Ласевский

Не могу этого сделать, так как это живой сервер с сотнями одновременно работающих пользователей (добавили это в OP, как это было непонятно до этого)
BT643

0

PID этого экземпляра Apache низкий, он может быть отцом всего этого. Это, безусловно, объясняет высокую загрузку ЦП (она сохраняется, другие создаются и загружаются в зависимости от нагрузки). Много времени, накопленного процессором, может означать, что оно уже давно работает. Отсутствие вывода strace(1)означает, что он не выполнял системные вызовы. Да, это может быть в узком цикле, но apache - это, по сути, ввод-вывод через сеть, поэтому я думаю, что он не делает ничего полезного. Странно 100% одного процессора, в любом случае.


Низкий PID не обязательно означает, что это старый процесс. PID имеют максимальное значение и могут использоваться для создания новых процессов с использованием низких PID.
австралиец

0

Попробуй это:

1) Запустите журнал с датой / временем, PHP-скриптом и PID, используя getmypid()

2) Затем следите за своим сервером с top

3) Когда вы видите, что процесс apache идет высоко, ищите ту же дату / время и PID в ваших журналах. Вы должны быть в состоянии найти проблемный сценарий.


Это интересное решение, но я вижу, что оно потребляет больше ресурсов, чем стоит, учитывая, что mod_statusоно хорошо справляется со своей задачей.
австралиец
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.