Назад | Перейти на главную страницу

Странные 3-секундные задержки tcp-соединения (Linux, HTTP)

Наши веб-серверы со статическим контентом иногда испытывают странные задержки в 3 секунды. Обычно запуск ApacheBench (> 10000 запросов, параллелизм 1 или 40, без разницы, но поддержка активности отключена) выглядит так:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2   10 152.8      3    3015
Processing:     2    8  34.7      3     663
Waiting:        2    8  34.7      3     663
Total:          4   19 157.2      6    3222

Percentage of the requests served within a certain time (ms)
  50%      6
  66%      7
  75%      7
  80%      7
  90%      9
  95%     11
  98%    223
  99%    225
 100%   3222 (longest request)

Я много чего пробовал: - Apache2 2.2.9 с MPM worker или prefork, без разницы (с KeepAliveTimeout 10-15) - Nginx 0.6.32 - различные параметры tcp (net.core.somaxconn = 3000, net.ipv4.tcp_sack = 0, net.ipv4.tcp_dsack = 0) - размещение файлов / DocumentRoot в tmpfs - включение или отключение shorewall (т.е. пустые iptables или нет) - AllowOverride None включен для /, поэтому проверки .htaccess (проверены с помощью strace) не выполняются - проблема сохраняется независимо от того, осуществляется ли доступ к веб-серверам напрямую или через балансировщик нагрузки Foundry

Ядро - 2.6.32 (бэкпорты Debian Lenny), но это произошло и с 2.6.26. IPv6 включен, но не используется.

Эта проблема кому-то кажется знакомой? Помощь / предложения очень ценятся. Это немного похоже на то, как SYN, пакет ACK теряется или игнорируется.

Захватите это событие с помощью tcpdump / Wireshark / tshark. Затем откройте захват в Wireshark, перейдите в Статистика-> График потока TCP-> График временной последовательности (Стивенс).

Это дает вам график порядковых номеров в зависимости от времени. Если у вас есть 3-секундный промежуток в ваших соединениях, вы сможете его заметить, так как на оси x не должно быть точек в течение 3 секунд между двумя плотными группами точек. Нажмите на последнюю точку слева от разрыва. Это приведет вас к кадру непосредственно перед тем, как произойдет разрыв. Обычно это единственный пакет, содержащий проблему. Вы можете увидеть пакет с нулевым окном, пропавший пакет, неупорядоченную доставку, дублирование и т. Д.

Убедитесь, что ваш DNS-сервер работает медленно, и настройте файлы журнала Apache так, чтобы они регистрировались по IP, а не по имени домена. Если вы не измените настройки файла журнала по умолчанию, каждый раз, когда вы получаете запрос, регистратор должен выполнять поиск в DNS.

Это может быть вызвано блокировками ввода-вывода разными интересными способами. Для начала попробуйте изолировать проблему. Проблема в сервере / сети или в сервисе? Можете ли вы воспроизвести проблему с помощью ping / tcpping?

Если это проблема, когда весь сервер зависает на несколько секунд.

  1. Настроены ли ваши жесткие диски на замедление при бездействии? Если вы получаете ошибку страницы на жестком диске, который остановлен, системе могут потребоваться секунды для восстановления. В любом случае подумайте об избавлении от свопа.

  2. Это может быть проблема низкого уровня в сети. Я наблюдал подобное поведение с редкими, медленными соединениями, когда на коммутаторе не хватало места в таблице MAC-адресов. Проследите несколько пакетов и посмотрите, можете ли вы увидеть что-то еще, что кажется связанным с сетью.

  3. Это также может быть аппаратная проблема с сервером, например, шина, которая блокируется и восстанавливается через несколько секунд. Проверьте свои журналы.

Если кажется, только Apache:

  1. Поиск DNS был бы частым виновником, но, похоже, вы его прикрыли.

  2. Попробуйте развернуть совершенно другой сервер (например, lighttp) и посмотрите, поможет ли это решить проблему. Тогда вы можете начать подозревать что-то в вашей конфигурации apache.

Похоже на проблему с установлением TCP-соединения, то есть потерянный SYN, ACK, как вы предлагаете.

3 секунды - это первый тайм-аут по умолчанию для TCP SYN, ACK в Linux. Маловероятно, что это связано с приложением (веб-сервером), поскольку установлением соединения занимается ядро.

Поскольку это влияет на менее 1% подключений, это может быть следующее:

  • потеря пакетов в WAN (потеря 1% пакетов не является неслыханной для некоторых типов WAN),
  • неправильно настроенный сетевой адаптер (используйте ethtool для исследования и подтверждения дуплексной связи, автонегирования и т. д.),
  • неисправность кабеля (не помешает попробовать поменять кабель),
  • ошибка ядра (которую вы, кажется, устранили).

Недавно у меня было это на сервере, и оказалось, что это второй из приведенных выше: неправильно настроенный сетевой адаптер, который был вынужден установить неправильную скорость и настройки дуплекса. Я сбросил его для автосогласования с ethtool и не оглядывался.