Огромное количество соединений TIME_WAIT говорит netstat

TIME_WAIT это нормально. Это состояние после закрытия сокета, которое используется ядром для отслеживания пакетов, которые могут быть потеряны и опозданы на вечеринку. Большое количество соединений TIME_WAIT является признаком получения большого количества коротких соединений, и не о чем беспокоиться.

Это не важно Все, что означает, это то, что вы открываете и закрываете большое количество Sun RCP TCP соединений (1500-2500 из них каждые 2-4 минуты). TIME_WAIT состояние - это то, во что входит сокет при закрытии, чтобы предотвратить поступление сообщений для неправильных приложений, как если бы сокет использовался слишком быстро, и для нескольких других полезных целей. Не беспокойся об этом.

(Если, конечно, вы на самом деле не выполняете ничего, что должно обрабатывать столько операций RCP. Тогда беспокойтесь.)

Что-то в вашей системе выполняет много RPC (удаленных вызовов процедур) в вашей системе (обратите внимание, что источником и получателем является localhost). Это часто наблюдается для lockd для монтирования NFS, но вы также можете увидеть это и для других вызовов RPC, таких как rpc.statd или rpc.spray.

Вы можете попробовать использовать "lsof -i", чтобы увидеть, у кого открыты эти сокеты, и посмотреть, что это делает. Это, вероятно, безвредно.

tcp_fin_timeout НЕ контролирует TIME_WAIT задержка. Вы можете увидеть это, используя ss или netstat с -o, чтобы увидеть таймеры обратного отсчета:

cat /proc/sys/net/ipv4/tcp_fin_timeout
3

# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24

NetidRecv-Q  Send-Q    Local Address:Port    Peer Address:Port                             
tcp  0       0         192.168.100.1:57516   192.168.0.10:80    timer:(timewait,55sec,0)   
tcp  0       0         192.168.100.1:57356   192.168.0.10:80    timer:(timewait,25sec,0)   
tcp  0       0         192.168.100.1:57334   192.168.0.10:80    timer:(timewait,22sec,0)   
tcp  0       0         192.168.100.1:57282   192.168.0.10:80    timer:(timewait,12sec,0)   
tcp  0       0         192.168.100.1:57418   192.168.0.10:80    timer:(timewait,38sec,0)   
tcp  0       0         192.168.100.1:57458   192.168.0.10:80    timer:(timewait,46sec,0)   
tcp  0       0         192.168.100.1:57252   192.168.0.10:80    timer:(timewait,7.436ms,0) 
tcp  0       0         192.168.100.1:57244   192.168.0.10:80    timer:(timewait,6.536ms,0)

даже если для tcp_fin_timeout установлено значение 3, обратный отсчет для TIME_WAIT все еще начинается с 60. Однако, если для net.ipv4.tcp_tw_reuse установлено значение 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse) тогда ядро ​​может повторно использовать сокеты в TIME_WAIT, если определит, что при TCP нумерации сегментов) не будет никаких возможных конфликтов.

У меня тоже была такая же проблема. Мне потребовалось несколько часов, чтобы выяснить, что происходит. В моем случае причиной этого было то, что netstat пытается найти имя хоста, соответствующее IP-адресу (я предполагаю, что он использует API gethostbyaddr). Я использовал встроенную установку Linux, которая не имела /etc/nsswitch.conf. К моему удивлению, проблема существует, только когда вы фактически выполняете команду netstat -a (выясните это, запустив portmap в подробном режиме и режиме отладки).

Теперь произошло следующее: По умолчанию функции поиска также пытаются связаться с демоном ypbind (Sun Yellow Pages, также известным как NIS), чтобы запросить имя хоста. Чтобы запросить этот сервис, необходимо связаться с portmapper portmap, чтобы получить порт для этого сервиса. Теперь в моем случае с portmapper связались через TCP. Затем portmapper сообщает функции libc, что такой службы не существует, и соединение TCP закрывается. Как мы знаем, закрытые TCP соединения переходят в состояние TIME_WAIT для некоторых время. Таким образом, netstat перехватывает это соединение при перечислении, и эта новая строка с новым IP-адресом выдает новый запрос, который генерирует новое соединение в состоянии TIME_WAIT и так далее ...

Чтобы решить эту проблему, создайте файл /etc/nsswitch.conf, который не использует службы NIS rpc, т.е. со следующим содержимым:

passwd:         files
group:          files
hosts:          files dns
networks:       files dns
services:       files
protocols:      files
netmasks:       files