веб-сервер apache не отвечает с состоянием сервера, показывая все дочерние процессы, ожидающие подключения [закрыто]


10

Моя установка: у меня есть 3 почти идентичных машины веб-сервера, обслуживающих один и тот же высоконагруженный динамический веб-сайт с простой балансировкой нагрузки по DNS. Сервис работает уже более двух лет с одной и той же конфигурацией apache: apache2, php5, ubuntu 8.04 linux 2.6.24-29-server.

Моя проблема: Примерно две недели назад у меня возникли проблемы с этим конфигом. Почти каждый день у меня есть один маленький момент в течение 5 минут, в течение которого сайт недоступен. Я все еще могу войти на сервер через SSH. Если я бегу htop, я вижу, что машина просто ничего не делает. У меня работает около 1000 процессов Apache, но нет активности процессора.

Я использовал apache mod_status для отладки этой ситуации. Табло процесса выглядит так:

_C.___K_______________________R._______.__K_K____K___C_______.__
_______C__________.___________________________________.________C
_.____K__________K___K_WK_____._K_____________________________._
W______K__________K________.____________________._______C_______
_C_.__K__K____.._.._____________________________________C_______
_R___________K___.______C________.C_________.______._____C______
____________KKC____K_____K__WC_________________C_____.__.____.__
_____________________C_________K______.____C______._____________
_.___C____.___.___________________________.K______.____K________
W__.___________________C.__.____K________K_______R_._.__._______
__C__C_.__________C__C_______._____W______________C_.___C_______
____.______C_____________C________.____C____________.________._K
__.__________.K_____________K_________._____C____.K__________KW_
__K.W________R_________._______.___W___________.____.__K_____W__
W___.___..________W____K

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

Таким образом, большинство процессов просто ждут подключения. Примерно через 5 минут ситуация вернется к норме: на каждой машине у меня будет наименьшее количество процессов, большинство работников имеют статус "." (это означает, что они открыты для обработки запроса) и, конечно, сайт доступен!

так что я пытаюсь найти что-то в журналах, но просто ничего нет ... журнал доступа apache молчит около 4 минут, то же самое относится и к журналу ошибок. Я также не могу понять, что-то не так в других системных журналах.

Ситуация одинакова на всех 3 веб-серверах (все они имеют пиковую нагрузку и одновременно не отвечают), поэтому я не думаю, что это связано с аппаратным обеспечением. но я думаю, это может быть связано с какой-то проблемой сети (tcp).

Любые идеи?

РЕДАКТИРОВАТЬ: еще немного информации, которую я только что обнаружил:

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

Я сделал некоторые статистические данные о соединении с помощью следующей команды: netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

  • 109 CLOSE_WAIT
  • 2652 УСТАНОВЛЕНО
  • 2 FIN_WAIT1
  • 11 LAST_ACK
  • 12 СЛУШАТЬ
  • 91 SYN_RECV
  • 1 SYN_SENT
  • 16 TIME_WAIT

Если я выполню ту же команду через некоторое время, у меня будет что-то вроде этого:

  • 4 ЗАКРЫТИЕ
  • 108 УСТАНОВЛЕНО
  • 18 FIN_WAIT1
  • 182 FIN_WAIT2
  • 37 LAST_ACK
  • 12 СЛУШАТЬ
  • 50 SYN_RECV
  • 11276 TIME_WAIT

Таким образом, в обычной ситуации у меня только 100-200 открытых подключений клиентами, обрабатываемыми apache в данный момент. Когда у меня происходит этот «сбой», у меня намного больше связей. Каков наилучший способ проанализировать это?

EDIT2: важные строки в apache2.conf:

KeepAlive On
MaxKeepAliveRequests 20
KeepAliveTimeout 1
<IfModule mpm_prefork_module>
ServerLimit           920
StartServers          30
MinSpareServers       80
MaxSpareServers      120
MaxClients          920
MaxRequestsPerChild   700
</IfModule>

Это предварительная ветка apache2 с php_mod.

Сервер имеет оперативную память 8 ГБ и раздел подкачки 4 ГБ.


Показывает ли веб-сайт те же симптомы при запуске wget или curl с локального хоста или между серверами (если они находятся в одной сети)?
Алекс Форбс

Возможно, дамп трафика ( tcpdump) поможет вам понять причину проблемы ... кстати, каковы ваши правила использования памяти и брандмауэра?
drcelus

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

Если вы можете подтвердить, что он работает локально, но не извне, это усиливает аргумент в пользу проблемы с сетью - это означает, что вы должны протестировать tcpdumps и wireshark на обоих концах, чтобы увидеть, что происходит, вместо того, чтобы ограничивать процессы apache. Я бы также проверил с хоста в той же локальной сети, если это возможно. И проверьте dmesg, чтобы увидеть, есть ли какие-либо сообщения, которые могут быть связаны, но похоже, что вы уже сделали это.
Алекс Форбс

это просто случилось снова. и я смог проверить, что я также не могу подключиться локально, когда возникает эта проблема. я также сделал некоторую статистику соединения с netstat: см. текст вопроса
Джефф

Ответы:


2

Вы должны включить расширенный статус mod_status ( http://httpd.apache.org/docs/2.2/mod/mod_status.html#extendedstatus ), чтобы отслеживать текущие хосты и обрабатываемые запросы. Я думаю, что есть сценарий (ы) / страница (ы), которые занимают слишком много времени, чтобы освободить соединение, и это делает стек соединения.


1

Первое: проверьте свой Max open filesлимит на процесс. Активное соединение с сокетом считается открытым файлом. cat /proc/###/limitsхороший способ проверить действующее значение для другого процесса. Вы можете получить список открытых файлов, lsof -p ###где ### - идентификатор процесса вашего веб-сервера. Вы можете сравнить, lsof -p ### | wc -lчтобы увидеть, насколько близко вы подходите к пределу. Вы также должны видеть сообщения в error_log apache, если вы достигаете предела.

Вам нужен дескриптор файла для каждого соединения сокета, а также для каждого сценария cgi или ссылки на файл данных. Для 920 MaxClients вы должны сконфигурировать не менее 4000 файлов для процесса httpd. Вы можете увеличить количество файлов, добавив файл в /etc/security/limits.d/ со следующим содержимым. Убедитесь, что имя пользователя соответствует тому, что вы используете для своего веб-сервера.

apache soft nofile 10000
apache hard nofile 10000

Второе: если проблема с исчерпанием порта, вы можете изменить некоторые настройки ip в /etc/sysctl.conf. (Начиная с net.ipv4.tcp_fin_timeout). Обычно это проблема только с большим количеством очень маленьких соединений. Многие сокеты TIME_WAIT являются одним из индикаторов этого, но это указывает на исчерпание порта, только когда сопровождается ошибками в системном журнале о possible SYN floodingи Sending cookies. Вы также должны убедиться, что ваш сервер защищен брандмауэром, который может предотвратить атаки SYN.


0

Кроме того, имейте в виду, что в prefork MPM каждый процесс будет иметь PHP в своем пространстве памяти (каково его ограничение памяти?). Вы можете попробовать перейти на рабочий MPM, для чего может потребоваться немного другой модуль PHP.

Также стоит удаленная серьга, чтобы обрезать свой Apache конфиг посторонних модулей

По моему опыту, такие вещи запускаются такими вещами, как поисковый движок или конфликты ARP. Или уровни трафика в некоторой связанной части сети.

Вы можете найти 'sar' полезным ... не самым дружелюбным, но, безусловно, полезным.

Возможно, также связано. Sar может сказать вам (если вы настроите его для записи активности диска), каково среднее время ожидания. Вы также можете взглянуть на время ожидания ввода-вывода сверху (это процент, прочитайте, что это на самом деле означает). Это может быть важно, если вы используете SAN или виртуальную среду.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.