Apache использует избыточный процессор

Мы запускаем сайт среднего размера, который получает несколько сотен тысяч просмотров страниц в день. До прошлых выходных мы бегали с нагрузкой, обычно ниже 0,2 на виртуальной машине. ОС - Ubuntu.

При развертывании последней версии нашего приложения мы также выполнили apt-get dist-upgrade перед развертыванием. После того, как мы развернулись, мы заметили, что нагрузка на процессор сильно драматизировалась (иногда достигая 10 и останавливаясь, чтобы отвечать на запросы страниц).

Мы попытались сбросить полную минуту данных профилирования Xdebug с PHP, но просмотр через него показал лишь несколько несколько медленных частей, но ничего не объяснил огромный скачок.

Теперь мы уверены, что ничто в новой версии нашего сайта не вызывает проблемы, но мы не можем быть уверены. Мы отбросили много изменений, но проблема все еще сохраняется.

Когда мы смотрим на процессы, мы видим, что отдельные процессы Apache используют довольно немного процессора в течение более длительного периода времени, чем это необходимо. Однако при использовании strace в затронутом процессе мы никогда ничего не видим, кроме

accept(3,

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

Стек - это PHP 5, Apache 2 (prefork), MySQL 5.1. Большинство вещей проходят через Memcached. Мы пробовали APC и eAccelerator.

Итак, что должно быть нашим следующим шагом? Есть ли какие-либо методы профилирования, о которых мы не замечаем/не знаем?

Ответ 1

Ответ оказался не связанным с Apache. Как уже упоминалось, мы были на виртуальной машине. Наши пользовательские сессии довольно большие (думаю, 500 КБ на активного пользователя), поэтому у нас было много дискового ввода-вывода. Диск был почти полным, а это означало, что Ubuntu потратил много времени на перемещение вещей (или, как мы думаем). Не было простого способа расширить диск (потому что он не был настроен правильно для VMWare). Это полностью убило производительность, и Apache и MySQL иногда использовали 100% -ный процессор (в течение очень короткого времени), и система была бы настолько медленной, чтобы обновлять счетчики использования процессора, которые, казалось, застряли там.

В итоге мы создали новую виртуальную машину (которая также дала нам возможность полностью документировать все на сервере). На новой виртуальной машине мы выделили много дискового пространства и переместили сеансы в память (используя memcached). Наша загрузка снизилась до 0,2 при использовании вне пика и около 1 около пикового использования (на VM 2-CPU). Перемещение сеансов в memcached заняло много дискового ввода-вывода (мы постоянно использовали около 2 МБ/с дискового ввода-вывода, что очень плохо).

Вывод; иногда вам нужно только начать...:)

Ответ 2

Просмотр вызова accept() из вашего процесса Apache совсем не необычен - веб-сервер ожидает нового запроса.

Прежде всего, вы хотите установить параметры нагрузки. Что-то вроде

vmstat 1

покажет вам, что ваша система. Посмотрите в столбцах "swap" и "io". Если вы видите что-либо, кроме "0" в столбцах "si" и "so", ваша система меняет местами из-за низкого состояния памяти. Подумайте о сокращении количества работающих пользователей Apache или о том, что на вашем сервере больше памяти.

Если операционная система не является проблемой, посмотрите на столбцы "cpu". Вас интересуют колонки "us" и "sy". Они показывают процентное соотношение времени процессора, затраченного на процессы или систему пользователя. Высокий номер "нас" указывает пальцем на Apache или ваши сценарии - или, возможно, что-то еще на сервере.

Запуск

top

покажет вам, какие процессы наиболее активны.

Вы исключили свою базу данных? Наиболее распространенная причина неожиданной высокой нагрузки, которую я видел на производственных столах LAMP, сводится к запросам базы данных. Возможно, вы использовали новый код с дорогостоящим запросом; или дошел до того, что в вашем наборе данных есть достаточно строк, чтобы заставить ранее дешевые запросы стать дорогими.

В периоды высокой нагрузки do

echo "show full processlist" | mysql | grep -v Sleep

чтобы увидеть, есть ли долговременные запросы или огромные числа одного и того же запроса работают сразу. Другие инструменты mysql помогут вам оптимизировать их.

Вам может быть полезно настроить и использовать mod_status для Apache, что позволит вам узнать, какой запрос обслуживает каждый ребенок Apache, и как долго он это делает.

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

Ответ 3

Возможно, вы, где используете рабочий MPM раньше, а теперь нет?

Я знаю, что PHP5 не работает с WorkM MPM. На моем сервере Ubuntu PHP5 можно установить только с помощью Prefork MPM. Похоже, что модуль PHP5 несовместим с многопотоковой версией Apache.

Я нашел ссылку здесь, которая покажет вам, как повысить производительность с помощью mod_fcgid

Чтобы узнать, что рабочий MPM видит здесь.

Ответ 4

Я бы использовал dTrace для решения этой загадки... если бы она работала на Solaris или Mac... но так как Linux ее не имеет, вы можете попробовать их Systemtap, однако я ничего не могу сказать о его удобстве использования, поскольку я не использовал его.

С помощью dTrace вы можете легко вынюхивать преступников в течение дня и надеяться, что Systemtap будет похож на

Ответ 5

Еще один вариант, который я не могу вам заверить, будет полезен, но это более чем стоит усилий. Должен прочитать подробный журнал изменений для новой версии и просмотреть, что могло измениться, что может оказать на вас удаленное влияние.

Прохождение в списках изменений спасло меня не один раз. Особенно когда некоторые параметры конфигурации изменились и когда что-то устарело. Худший случай - это даст вам некоторые подсказки относительно того, где искать следующий