Моя установка: у меня есть 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
Если через некоторое время я выполню ту же команду, у меня будет что-то вроде этого:
Таким образом, в нормальной ситуации у меня в данный момент есть только 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 ГБ.
Вы должны включить расширенный статус mod_status (http://httpd.apache.org/docs/2.2/mod/mod_status.html#extendedstatus), чтобы отслеживать текущие хосты и обрабатываемые запросы. Я думаю, что есть скрипт (ы) / страница (ы), который требует слишком много времени для освобождения соединения и заставляет соединения складываться.
Во-первых: проверьте свой 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.
Также имейте в виду, что в MPM prefork каждый процесс будет иметь PHP в своей области памяти (каковы его настройки ограничения памяти?). Вы можете попробовать перейти на рабочий MPM, для которого может потребоваться немного другой модуль PHP.
Также стоит удаленная серьга для обрезки вашего конфига Apache от посторонних модулей
По моему опыту, такие вещи запускаются такими вещами, как сканер поисковой системы, или такими вещами, как конфликты ARP. Или уровни трафика в какой-либо связанной части сети.
Вы можете найти sar полезным ... не самым дружелюбным, но определенно полезным.
Возможно, также связано с ИО. Sar может сказать вам (если вы настроите его для записи активности диска), каково среднее время ожидания io. Вы также можете посмотреть время ожидания ввода-вывода в верхней части (это процент, прочтите, что это на самом деле означает). Это может быть важно, если вы используете SAN или виртуальную среду.