У меня есть кластер из нескольких машин, подключенных к сети 10GBE (сетевые адаптеры Intel 82599EB 10GBE SFI / SFP +), работающие под Debian 6.0, и столкнулся с проблемой зависания TCP-соединений в состоянии CLOSE_WAIT. Я знаю, что теоретически соединение в состоянии CLOSE_WAIT должно быть явно закрыто приложением, но в моем случае как минимум два разных приложения генерируют эти зависшие соединения, и я думаю, что проблема в другом.
Сначала эта проблема была воспроизведена Cassandra, работающей как демон в процессе jsvc. Один узел Cassandra («сервер») не закрыл соединение, которое было закрыто на одной стороне другого узла, инициировавшего это соединение («клиент»). После этого я запустил тест TCP_CRR netperf и получил сообщение об ошибке:
netperf -H 172.15.2.166 -t TCP_CRR -l -5 -D TCP Connect / Request / Response TEST от 0.0.0.0 (0.0.0.0) порт 0 AF_INET до 172.15.2.166 (172.15.2.166) порт 0 AF_INET: demo send_tcp_conn_rr: Ошибка получения данных: сброс соединения одноранговым узлом
С подключением TCP, зависшим в состоянии CLOSE_WAIT на машине 172.15.2.166 со странным 1 байтом в Recv-Q.
tcp 1 0 172.15.2.166:12865 172.15.2.161:42863 CLOSE_WAIT
Я обновил драйвер ixgbe до последней версии 3.9-NAPI, но эта проблема все еще сохраняется, и теперь мне интересно, что еще может вызвать проблему?
FIN за которым следует RST от клиентаlsof -n | grep CLOSE.WAIT