Наш сервер иногда отказывается обслуживать простую HTML-страницу.
Это происходит при относительно большом количестве запросов. Однако процессор не сильно загружен и есть много свободной памяти. Ошибка, похоже, возникает в среднем 1 из 50 запросов, в зависимости от нагрузки на сервер.
Мне необходимо найти источник проблемы и принять соответствующие меры для ее устранения.
У меня есть подозрение, что источником проблемы является огромное количество входящих сетевых пакетов. В среднем 5000 пакетов в секунду. Трафик - 2 Мбит/сек. Может ли это быть причиной ошибки?
Интересный момент: если сервер не отвечает, строка запроса не регистрируется в access.log Apache.
Ошибка повторяется с нескольких клиентских компьютеров. DNS тут не при чем, так как я зашел на сервер по IP.
Я профилировал проблемный случай с помощью утилиты tcpdump. Это хорошие и плохие сеансы, отслеженные tcpdump. Запрос одинаков в обоих экспериментах. Хороший — сервер возвращает ответ. Плохой — нет ответа, ошибка тайм-аута.
---- Bad ----
12:23:36.366292 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:23:39.362394 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:23:45.365567 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,nop,sackOK>
--------
---- Good ----
12:27:07.632229 IP 123.45.67.890.63914 > myserver.superbservers.com.www: S 3581365570:3581365570(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:27:10.620946 IP 123.45.67.890.63914 > myserver.superbservers.com.www: S 3581365570:3581365570(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:27:10.620969 IP myserver.superbservers.com.www > 123.45.67.890.63914: S 2654770980:2654770980(0) ack 3581365571 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
12:27:10.838747 IP 123.45.67.890.63914 > myserver.superbservers.com.www: . ack 1 win 4380
12:27:10.957143 IP 123.45.67.890.63914 > myserver.superbservers.com.www: P 1:213(212) ack 1 win 4380
12:27:10.957152 IP myserver.superbservers.com.www > 123.45.67.890.63914: . ack 213 win 108
12:27:10.965543 IP myserver.superbservers.com.www > 123.45.67.890.63914: P 1:630(629) ack 213 win 108
12:27:10.965621 IP myserver.superbservers.com.www > 123.45.67.890.63914: F 630:630(0) ack 213 win 108
12:27:11.183540 IP 123.45.67.890.63914 > myserver.superbservers.com.www: . ack 631 win 4222
12:27:11.185657 IP 123.45.67.890.63914 > myserver.superbservers.com.www: F 213:213(0) ack 631 win 4222
12:27:11.185663 IP myserver.superbservers.com.www > 123.45.67.890.63914: . ack 214 win 108
--------
Хостер: SuperbHosting
ОС: Ubuntu
Параметры сервера: E6300 CONROE 1.86GHZ 2 X 1MB CACHE 1066 1GB DDR2 667MHZ
Это ссылка на файл конфигурации Apache, который мы используемhttp://repkin5.snow.prohosting.com/apache.txt
Это отчет о состоянии сервера, составленный сразу после ошибки тайм-аута.http://repkin5.snow.prohosting.com/server-status.htmИз 120 дочерних серверов осталось всего 10, так что места для новых запросов достаточно.
ВМСТАТ
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 8900 725900 8468 65684 0 0 5 18 11 33 4 3 92 1
решение1
- Интересный момент: если сервер не отвечает, строка запроса не регистрируется в access.log Apache.
Похоже на проблему с сетью. Сервер должен регистрировать все получаемые запросы, даже если по какой-то причине он не может ответить. Возможно, вам стоит проверить, не наблюдаются ли потери пакетов на веб-сервере.
решение2
Есть небольшая вероятность, что вы находитесь в ситуации, когда доступные буферы ядра для TCP-соединений малы. Я бы ожидал от этого некоторого логирования (войдите на сервер, протестируйте, пока не получите "нет ответа", затем запустите dmesg
и посмотрите, выглядит ли что-нибудь применимым).
Чтобы настроить параметры сети,это может быть отправной точкой.
Как сказал Крис Нава, вероятно, стоит убедиться, что у вас не просто происходит потеря пакетов по всей сети, поэтому обязательно начните проверку с помощью ping (увы, ответ на ping совсем не то же самое, что работа с TCP-пакетом).