Требуется дальнейшее объяснение в TIME_WAIT

Привет, гуру Unix / Linux!

Мне нужно твердое доказательство того, что TIME_WAIT (на самом деле это много) является реальным виновником замедления на одном из наших серверов. Сервер размещается на виртуализации Parallels Baremetal, а фактический сервер – VM: CentOS5 с двойным процессором и оперативной памятью 2 ГБ.

Неделю назад мы начали замечать, что было слишком медленно, что даже выполнение «ls» в каталоге с несколькими файлами (около 20) понадобилось бы около 1,5 секунд для отображения результатов.

Я пробовал делать vmstat но, похоже, он даже не использует его подкачку. Отсутствие узких мест в сети. Но работая top , вы увидите, что java в основном забивает ресурс. Java требуется, поскольку эта виртуальная машина является нашим сервером hudson.

Один из моих коллег попытался проверить соединения через

 $ vmstat -vatpno 

И заметил, что там, где много связей в TIME_WAIT … около 300+. Поэтому мы попытались применить некоторые рекомендации на этой странице, в частности, TCP_FIN_TIMEOUT, TCP_KEEPALIVE_INTERVAL & TCP_KEEPALIVE_PROBES. Соединения в TIME_WAIT уменьшались, но все еще колеблются от 220 до 280 (возможно, из-за того, что время добавления нового соединения добавляется, а другие соединения в TIME_WAIT еще не «тайм-аут»). Возможно, мы могли бы попробовать добавить TCP_TW_RECYCLE & TCP_TW_REUSE позже, когда мы не увидим никаких улучшений.

Теперь вернемся к моему основному вопросу: есть ли веские доказательства того, что многие соединения TIME_WAIT содержат много ОЗУ?

Заранее спасибо.

One Solution collect form web for “Требуется дальнейшее объяснение в TIME_WAIT”

Соединение в состоянии TIME_WAIT просто ждет, чтобы увидеть, просачиваются ли какие-либо последние отбрасывающие пакеты данных через сеть с другого конца, чтобы они не смешивались с пакетами другого соединения. На самом деле он ничего не делает с этими пакетами. Поэтому, если что-либо, соединение TIME_WAIT использует меньше ресурсов, чем открытое соединение.

Хорошо подготовленный веб-сервер в эти дни может обрабатывать более 10 000 одновременных подключений (обратите внимание, что это было написано в 2003 году, и закон Мура продолжает маршировать). Поскольку, если что-либо, соединение в состоянии TIME_WAIT будет использовать меньше памяти, чем открытое соединение, 300 соединений в TIME_WAIT должны быть ничем.

Для получения дополнительной информации о TIME_WAIT см. http://tangentsoft.net/wskfaq/articles/debugging-tcp.html и http://developerweb.net/viewtopic.php?id=2941 .

Между тем, мне интересно, как выглядит использование дискового ввода-вывода. По моему опыту, жесткие дисковые операции ввода-вывода могут замедлить работу ядра Linux намного легче, чем интенсивное использование ЦП. Вы можете посмотреть инструменты iostat и dstat и посмотреть, что они говорят вам.

  • график производительности TCP-соединения на основе `ss -i`
  • Что означает TCPRcvCoalesce, TCPAutoCorking и TCPHystartTrainCwnd в netstat?
  • Сервер ретрансляции для общего трафика TCP?
  • Сиротские соединения в состоянии CLOSE_WAIT
  • что такое спецификация формата для `ss -D`?
  • `cat / dev / ttyACM` теряет данные при передаче через netcat
  • Как запустить различные алгоритмы управления перегрузками в FEDORA 17 ..?
  • Сброс TCP после SYN ACK, возможно, связанный с "no route to host"
  • Как прекратить TCP-соединение, установленное самим bash?
  • включить эхо-сервис и проблемы безопасности в Linux
  • Переадресация портов и маскировка
  • Linux и Unix - лучшая ОС в мире.