Моя установка: у меня есть 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 ГБ.
tcpdump) поможет вам понять причину проблемы ... кстати, каковы ваши правила использования памяти и брандмауэра?Ответы:
Вы должны включить расширенный статус 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/ со следующим содержимым. Убедитесь, что имя пользователя соответствует тому, что вы используете для своего веб-сервера.
Второе: если проблема с исчерпанием порта, вы можете изменить некоторые настройки ip в /etc/sysctl.conf. (Начиная с
net.ipv4.tcp_fin_timeout). Обычно это проблема только с большим количеством очень маленьких соединений. Многие сокеты TIME_WAIT являются одним из индикаторов этого, но это указывает на исчерпание порта, только когда сопровождается ошибками в системном журнале оpossible SYN floodingиSending cookies. Вы также должны убедиться, что ваш сервер защищен брандмауэром, который может предотвратить атаки SYN.источник
Кроме того, имейте в виду, что в prefork MPM каждый процесс будет иметь PHP в своем пространстве памяти (каково его ограничение памяти?). Вы можете попробовать перейти на рабочий MPM, для чего может потребоваться немного другой модуль PHP.
Также стоит удаленная серьга, чтобы обрезать свой Apache конфиг посторонних модулей
По моему опыту, такие вещи запускаются такими вещами, как поисковый движок или конфликты ARP. Или уровни трафика в некоторой связанной части сети.
Вы можете найти 'sar' полезным ... не самым дружелюбным, но, безусловно, полезным.
Возможно, также связано. Sar может сказать вам (если вы настроите его для записи активности диска), каково среднее время ожидания. Вы также можете взглянуть на время ожидания ввода-вывода сверху (это процент, прочитайте, что это на самом деле означает). Это может быть важно, если вы используете SAN или виртуальную среду.
источник