Une quantité énorme de connexions TIME_WAIT dit netstat

Solution 1 :

MODIF : tcp_fin_timeout NE FAIT PAS contrôler la durée de TIME_WAIT, elle est codée en dur à 60s

Comme mentionné par d'autres, avoir des connexions dans TIME_WAIT est une partie normale de la connexion TCP. Vous pouvez voir l'intervalle en examinant /proc/sys/net/ipv4/tcp_fin_timeout :

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

Et changez-le en modifiant cette valeur :

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

Ou de façon permanente en l'ajoutant à /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

De plus, si vous n'utilisez pas le service RPC ou NFS, vous pouvez simplement le désactiver :

/etc/init.d/nfsd stop

Et éteignez-le complètement

chkconfig nfsd off

Solution 2 :

TIME_WAIT est normal. C'est un état après la fermeture d'un socket, utilisé par le noyau pour garder une trace des paquets qui peuvent avoir été perdus et arriver en retard à la partie. Un nombre élevé de connexions TIME_WAIT est le symptôme d'un grand nombre de connexions de courte durée, pas de quoi s'inquiéter.

Solution 3 :

Ce n'est pas important. Tout ce que cela signifie, c'est que vous ouvrez et fermez de nombreuses connexions TCP Sun RCP (1 500 à 2 500 toutes les 2 à 4 minutes). Le TIME_WAIT state est ce dans quoi un socket entre lorsqu'il se ferme, pour empêcher les messages d'arriver pour les mauvaises applications comme ils pourraient le faire si le socket était réutilisé trop rapidement, et pour quelques autres raisons utiles. Ne vous inquiétez pas.

(À moins, bien sûr, que vous n'exécutiez rien qui devrait traiter autant d'opérations RCP. Alors, inquiétez-vous.)

Solution 4 :

Quelque chose sur votre système fait beaucoup de RPC (appels de procédure à distance) au sein de votre système (notez que la source et la destination sont localhost). Cela se voit souvent pour lockd pour les montages NFS, mais vous pouvez également le voir pour d'autres appels RPC comme rpc.statd ou rpc.spray.

Vous pouvez essayer d'utiliser "lsof -i" pour voir qui a ces sockets ouverts et voir ce qui le fait. C'est probablement inoffensif.

Solution 5 :

tcp_fin_timeout ne contrôle PAS TIME_WAIT retard. Vous pouvez le voir en utilisant ss ou netstat avec -o pour voir les comptes à rebours :

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)

même avec tcp_fin_timeout défini sur 3, le compte à rebours pour TIME_WAIT commence toujours à 60. Cependant, si vous avez net.ipv4.tcp_tw_reuse défini sur 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse ) alors le noyau peut réutiliser les sockets dans TIME_WAIT s'il détermine qu'il n'y aura pas de conflits possibles dans la numérotation des segments TCP.