Требуется дальнейшее объяснение в 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 содержат много ОЗУ?

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

Соединение в состоянии 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 и посмотреть, что они говорят вам.