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.
Итак, каким должен быть наш следующий шаг? Есть ли какие-то методы профилирования, которые мы упустили / не знаем?
К сожалению, у меня нет этого журнала. Насколько я знаю, журнала apt-get / aptitude нет.
Ответы 5
Возможно, вы раньше использовали рабочий MPM, а теперь нет?
Я знаю, что PHP5 не работает с Worker MPM. На моем сервере Ubuntu PHP5 можно установить только с Prefork MPM. Похоже, что модуль PHP5 несовместим с многопоточной версией Apache.
Я нашел здесь ссылку, которая покажет вам, как повысить производительность с помощью mod_fcgid
Чтобы узнать, что такое рабочий MPM, см. здесь.
Из-за идей, я боюсь, я подумал, что вы могли использовать php4 в своей старой версии приложения, и теперь, когда обновление до php5, apapche работает в режиме prefork. Ваша старая версия приложения использовала php4?
Может, около месяца. Мы обновляем перед каждым развертыванием. Но мы можем перестать это делать после этой проблемы ... :)
Я бы использовал dTrace, чтобы решить эту загадку ... если бы он работал на Solaris или Mac ... но поскольку в Linux его нет, вы можете попробовать их Systemtap, однако я ничего не могу сказать о его удобстве использования, так как Я этим не пользовался.
С dTrace вы можете легко найти виновных в течение дня, и надеетесь, что с Systemtap это будет похоже на
Systemtap пока кажется немного сложным.
Еще один вариант, в котором я не могу заверить вас, что он принесет пользу, но он того стоит. Прочитать подробный список изменений для новой версии и просмотреть, что могло измениться, что могло бы удаленно повлиять на вас.
Просмотр журналов изменений не раз спасал меня. Особенно, когда некоторые параметры конфигурации были изменены и что-то устарело. В худшем случае это подскажет, где искать дальше.
В данном случае это не особо помогло. Мы сделали это изначально и обнаружили некоторые проблемы с производительностью, но, к сожалению, откат этих изменений не решил проблему.
Наблюдение за вызовом accept () из вашего процесса Apache вовсе не необычно - это веб-сервер, ожидающий нового запроса.
Прежде всего, вы хотите установить, каковы параметры нагрузки. Что-то типа
vmstat 1
покажет вам, что делает ваша система. Посмотрите столбцы «swap» и «io». Если вы видите что-либо, кроме «0» в столбцах «si» и «so», ваша система меняет местами из-за нехватки памяти. Подумайте об уменьшении количества запущенных дочерних серверов Apache или увеличении объема оперативной памяти на вашем сервере.
Если оперативная память не является проблемой, посмотрите столбцы «cpu». Вас интересуют столбцы «нас» и «сы». Они показывают процент времени ЦП, затрачиваемого на пользовательские процессы или систему. Большое число «нас» указывает пальцем на Apache или ваши скрипты - или, возможно, на что-то еще на сервере.
Бег
top
покажет вам, какие процессы наиболее активны.
Вы исключили свою базу данных? Наиболее частая причина неожиданно высокой нагрузки, которую я видел в производственных стеках LAMP, сводится к запросам к базе данных. Возможно, вы развернули новый код с дорогостоящим запросом; или дошли до точки, когда в вашем наборе данных достаточно строк, чтобы ранее дешевые запросы стали дорогими.
В периоды высокой нагрузки делайте
echo "show full processlist" | mysql | grep -v Sleep
чтобы увидеть, есть ли либо долго выполняющиеся запросы, либо одновременно работает огромное количество одного и того же запроса. Другие инструменты mysql помогут вам их оптимизировать.
Возможно, вам будет полезно настроить и использовать mod_status для Apache, что позволит вам увидеть, какой запрос обслуживает каждый дочерний элемент Apache и как долго он это делал.
Наконец, настройте долгосрочный статистический мониторинг. Что-то вроде zabbix легко настроить и позволит вам отслеживать использование ресурсов с течением времени, так что, если что-то замедляется, у вас есть исторические базовые показатели для сравнения, а также лучшая информация о том, когда начались проблемы.
Проблема в том, что Apache использует процессор. Оперативной памяти более чем достаточно (до обновления мы использовали 512 МБ, теперь у нас 2 ГБ). Никакой подкачки не происходит. Журнал медленных запросов MySQL не сообщает ничего необычного. Сейчас мы наблюдаем скачок нагрузки на уровне 40 во время интенсивного использования.
mod_status - ваш лучший выбор отсюда. Кроме того, чтобы ограничить все процессы Apache, а не только родительский, попробуйте: ps aux | grep h [t] tpd | awk '{print "-p" $ 2}' | xargs strace
Ответ оказался не связанным с Apache. Как уже упоминалось, мы были на виртуальной машине. Наши пользовательские сеансы довольно большие (предположим, 500 КБ на активного пользователя), поэтому у нас было много дискового ввода-вывода. Диск был почти заполнен, а это означало, что Ubuntu тратила много времени на перемещение вещей (по крайней мере, мы так думаем). Не было простого способа расширить диск (потому что он не был правильно настроен для VMWare). Это полностью убивало производительность, и Apache и MySQL время от времени использовали 100% ЦП (в течение очень короткого времени), и система так медленно обновляла счетчики использования ЦП, что казалось, что они застряли там.
Мы закончили настройкой новой виртуальной машины (которая также дала нам возможность тщательно документировать все на сервере). На новой виртуальной машине мы выделили много дискового пространства и переместили сеансы в память (используя memcached). Наша нагрузка упала до 0,2 при непиковой нагрузке и примерно до 1 при пиковой нагрузке (на 2-процессорной виртуальной машине). Перенос сеансов в memcached потребовал много дискового ввода-вывода (мы постоянно использовали около 2 МБ / с дискового ввода-вывода, что очень плохо).
Заключение; иногда приходится начинать сначала ... :)
С каких версий до каких версий вы обновляли систему? Я имею в виду а) PHP, б) Apache и в) memcached.