Почему сервер не отвечает?

Почему сервер не отвечает?

Наш сервер иногда отказывается обслуживать простую 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-пакетом).

Связанный контент