Apache использует чрезмерный процессор - PullRequest
11 голосов
/ 06 октября 2008

У нас есть сайт среднего размера, который получает несколько сотен тысяч просмотров страниц в день. До прошлых выходных мы работали с виртуальной машиной с нагрузкой, обычно ниже 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.

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

Ответы [ 5 ]

12 голосов
/ 20 октября 2008

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

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

Заключение; иногда нужно просто начать все сначала ...:)

5 голосов
/ 06 октября 2008

Наблюдение вызова accept () от вашего процесса Apache вовсе не является необычным - это веб-сервер, ожидающий новый запрос.

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

vmstat 1

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

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

Запуск

top

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

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

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

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

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

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

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

1 голос
/ 06 октября 2008

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

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

1 голос
/ 06 октября 2008

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

Я знаю, что PHP5 не работает с Worker MPM. На моем сервере Ubuntu PHP5 может быть установлен только с Prefork MPM. Кажется, что модуль PHP5 не совместим с многопоточными версиями Apache.

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

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

0 голосов
/ 06 октября 2008

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

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

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