Глядя на вывод, topя замечаю, что периодически один или два процесса Apache потребляют большое количество ресурсов ЦП — где-то от 50% до 90%.
Скачки загрузки ЦП происходят и исчезают довольно быстро, примерно каждые 10 секунд.
Существуют и другие запущенные процессы Apache, которые потребляют где-то от 2% до 4%
Я исследовал все возможные способы, чтобы попытаться отследить, какой виртуальный хост/сайт отвечает за эти процессы. Однако, поскольку они появляются и исчезают быстро, я не могу найти надежный способ сделать это.
Я пробовал lsofи также смотрел на выходные данные, server-statusно поскольку процессы не длятся долго, идентификатор процесса используется повторно, и его невозможно связать с виртуальным хостом, вызывающим проблему.
Например, если я запускаю lsofна рассматриваемом идентификаторе процесса, он выводит дюжину различных файлов журнала виртуального хоста, которые разделяли этот идентификатор процесса за последние несколько секунд. Я убежден, что виноват один виртуальный хост, но не могу понять, какой именно.
Я также проверил журнал медленных запросов MySQL, и он не выявил ничего интересного.
решение1
Моя рекомендация: добавьте время ответа в ваши журналы.
Это не идеально, поскольку нет гарантии, что запросы, вызывающие всплеск, будут обрабатываться дольше, чем другие, но это вероятно и дает вам отправную точку для расследования.
Для этого вам нужно определить новый LogFormat и CustomLog, который включает параметр %D. Смотрите ApacheДокументация по mod_log_config.
Другой вариант, который, вероятно, слишком низкоуровневый, но может дать вам представление о характере нагрузки, — это трассировка родительского процесса Apache с помощью -f для отслеживания дочерних процессов и -c для отображения времени ЦП на вызов, например:strace -f -c -p <apache parent pid>
Как только вы узнаете системные вызовы, которые занимают больше всего времени, вы можете отслеживать их напрямую. Например, предположим, что сервер тратит много времени на выполнение write(), вы можете сделать strace -f -e trace=write -p <apache parent pid>, и рассмотреть эти вызовы более подробно.