Отслеживание Apache от VirtualHost
У меня есть веб-сервер Apache, на котором работает много виртуальных хостов.
В последнее время он застопорился и стал не отвечать, и мне интересно, как я могу определить, какие виртуальные хосты вызывают большую часть проблемы. В прошлом у нас были случаи, когда ошибка в коде отдельного сайта приводила к сбою всего сервера. Моя цель - быстро диагностировать эти случаи.
Я наблюдаю за сервером с помощью munin и замечаю, что количество процессов apache, использование памяти и нагрузка в рассматриваемые периоды, как правило, очень высоки. Проблема в том, что эта статистика предназначена для всего веб-сервера, а не для отдельных виртуальных хостов.
Я написал скрипт для разбора блогов на трафик по VirtualHost, но, похоже, этого недостаточно. Возможно, мне нужно определить, сколько процессов apache отвечает за каждый VirtualHost, или как долго они держат каждый процесс открытым - или, возможно, за какой объем памяти отвечает каждый.
Где я могу найти эту информацию? Я не против написания скрипта для отслеживания этих данных, но я не знаю точно, откуда его извлекать.
2 ответа
Я ценю, что не всегда подходит наличие mod_status в любое время, но это и apachetop - лучшие способы диагностики этих проблем. Однако есть много способов снять кожу с кошки.
Этот трюк полезен в ряде обстоятельств и не только специфичен для Apache. Однако это зависит от ряда факторов, и вам нужно знать, что он делает, чтобы знать его ограничения.
for pid in `pgrep -u www-data`; do find /proc/${pid}/cwd -printf "%l\n" ; done
Давайте разберемся с этим:
- pgrep -u www-data выдает список пидов, работающих под пользовательскими www-данными. Это значение по умолчанию в Debian / Ubuntu, измените его в соответствии с вашей собственной системой (системы на базе RedHat, как правило, используют httpd, например, в качестве пользователя). Для систем без pgrep вы можете использовать ps axuwww | пользователь grep | awk '{print $ 2}'
- для; делать; ... done * loop означает, что мы перебираем все записи, выполняющие команду (и) в части do цикла.
- find /proc / $ {pid} / cwd -printf "%l\n" просто ищет /proc для каждого из этих PID и выплевывает текущий рабочий каталог для этого процесса. Apache по умолчанию выполняет вызов chdir() в VirtualHost при обслуживании файлов из этого VirtualHost. /proc/PID/cwd - это символическая ссылка на каталог, в котором выполняется процесс apache. printf "%l\n" печатает конечную точку для этой ссылки. См. Find(1) для получения дополнительной информации об этом.
У этого трюка есть два основных предостережения:
1) Если что-то, выполняющееся в том же контексте, что и процесс Apache, выполняет chdir() вне каталога VirtualHost, вам будет сложно это выяснить.
например, PHP-скрипт, работающий под mod_php (CGI будет отличаться, так как Apache fork - это отдельный процесс, но я предполагаю, что CGI не проблема, или вы могли бы легче их отслеживать).
2) Если у вас есть экземпляры Apache, которые очень очень быстро обслуживают страницы (например, небольшая статическая HTML-страница). Обычно это не проблема, но это возможно. Если вы получаете много ошибок "Нет такого файла или каталога", это в основном является проявлением этого. Я ожидал бы некоторых, но не большинства, если они не соответствуют этому конкретному случаю. По сути, это потому, что процессы Apache, которые вы сканировали с помощью ps, уже вышли к тому времени, когда вы проверили /proc. Очевидно, это означает, что они очень быстро обслуживают страницы.
Что касается связанных с памятью процессов Apache, я использую ps_mem.py для расчета использования памяти на моих веб-серверах. Если у вас есть большие процессы Apache (с точки зрения размера резидентной памяти), и они быстро завершают работу, это примерно эквивалентно тому, чтобы просить большого толстяка продолжать 100-метровые спринты. Если ваш веб-сервер не является общедоступным, эти ошибки "Нет такого файла или каталога" обычно являются хорошими кандидатами для перемещения некоторого содержимого на меньший облегченный веб-сервер (например, nginx / lighttpd) или для запуска интенсивного кэширования содержимого (например, varnish / squid).
Я думаю, что вы хотите apachetop, или иначе mod_status (с ExtendedStatus On). У меня еще не было проблемы с производительностью в Apache, которая не была освещена mod_status, и apachetop выглядит как аккуратный инструмент (который имеет некоторые раздражающие ограничения в макете журнала).