Gran cantidad de conexiones TIME_WAIT dice netstat

Solución 1:

EDITAR: tcp_fin_timeout NO controle la duración de TIME_WAIT, está codificado a los 60 s

Como mencionaron otros, tener algunas conexiones en TIME_WAIT es una parte normal de la conexión TCP. Puedes ver el intervalo examinando /proc/sys/net/ipv4/tcp_fin_timeout :

[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

Y cámbialo modificando ese valor:

[[email protected] admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

O permanentemente agregándolo a /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Además, si no usa el servicio RPC o NFS, puede desactivarlo:

/etc/init.d/nfsd stop

Y apágalo por completo

chkconfig nfsd off

Solución 2:

TIME_WAIT es normal. Es un estado después de que un socket se ha cerrado, utilizado por el núcleo para realizar un seguimiento de los paquetes que pueden haberse perdido y llegado tarde a la fiesta. Una gran cantidad de conexiones TIME_WAIT es un síntoma de obtener muchas conexiones de corta duración, no es nada de qué preocuparse.

Solución 3:

No es importante. Todo lo que significa es que está abriendo y cerrando muchas conexiones Sun RCP TCP (1500-2500 de ellas cada 2-4 minutos). El TIME_WAIT state es en lo que entra un socket cuando se cierra, para evitar que lleguen mensajes para las aplicaciones incorrectas como lo harían si el socket se reutilizara demasiado rápido, y para un par de otros propósitos útiles. No te preocupes por eso.

(A menos, por supuesto, que no esté ejecutando nada que deba procesar tantas operaciones RCP. Entonces, preocúpese).

Solución 4:

Algo en su sistema está haciendo muchas RPC (llamadas a procedimientos remotos) dentro de su sistema (observe que tanto el origen como el destino son localhost). Eso se ve a menudo para lockd para montajes NFS, pero también puede verlo para otras llamadas RPC como rpc.statd o rpc.spray.

Podría intentar usar "lsof -i" para ver quién tiene esos sockets abiertos y ver qué lo está haciendo. Probablemente sea inofensivo.

Solución 5:

tcp_fin_timeout NO controla TIME_WAIT demora. Puede ver esto usando ss o netstat con -o para ver los temporizadores de cuenta regresiva:

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)

incluso con tcp_fin_timeout configurado en 3, la cuenta regresiva para TIME_WAIT aún comienza en 60. Sin embargo, si tiene net.ipv4.tcp_tw_reuse configurado en 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse ), entonces el kernel puede reutilizar los sockets en TIME_WAIT si determina que no habrá ningún posible conflicto en la numeración de segmentos TCP.