Un'enorme quantità di connessioni TIME_WAIT dice netstat

Soluzione 1:

MODIFICA: tcp_fin_timeout NON controlla la durata TIME_WAIT, è hardcoded a 60s

Come menzionato da altri, avere alcune connessioni in TIME_WAIT è una parte normale della connessione TCP. Puoi vedere l'intervallo esaminando /proc/sys/net/ipv4/tcp_fin_timeout :

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

E cambialo modificando quel valore:

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

O permanentemente aggiungendolo a /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Inoltre, se non utilizzi il servizio RPC o NFS, puoi semplicemente disattivarlo:

/etc/init.d/nfsd stop

E spegnilo completamente

chkconfig nfsd off

Soluzione 2:

TIME_WAIT è normale. È uno stato dopo la chiusura di un socket, utilizzato dal kernel per tenere traccia dei pacchetti che potrebbero essere stati persi e presentati in ritardo alla festa. Un numero elevato di connessioni TIME_WAIT è un sintomo di molte connessioni di breve durata, non è nulla di cui preoccuparsi.

Soluzione 3:

Non è importante. Tutto ciò che significa è che stai aprendo e chiudendo molte connessioni Sun RCP TCP (1500-2500 ogni 2-4 minuti). Il TIME_WAIT state è ciò in cui entra un socket quando si chiude, per evitare che i messaggi arrivino per le applicazioni sbagliate come potrebbero se il socket fosse riutilizzato troppo velocemente, e per un paio di altri scopi utili. Non preoccuparti.

(A meno che, ovviamente, tu non stia effettivamente eseguendo qualcosa che dovrebbe elaborare così tante operazioni RCP. Allora, preoccupati.)

Soluzione 4:

Qualcosa sul tuo sistema sta eseguendo molte RPC (Remote Procedure Calls) all'interno del tuo sistema (nota che sia l'origine che la destinazione sono localhost). Questo è spesso visto per lockd per i montaggi NFS, ma potresti anche vederlo per altre chiamate RPC come rpc.statd o rpc.spray.

Potresti provare a usare "lsof -i" per vedere chi ha quei socket aperti e vedere cosa lo sta facendo. Probabilmente è innocuo.

Soluzione 5:

tcp_fin_timeout NON controlla TIME_WAIT ritardo. Puoi vederlo usando ss o netstat con -o per vedere i timer del conto alla rovescia:

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)

anche con tcp_fin_timeout impostato su 3 il conto alla rovescia per TIME_WAIT parte ancora da 60. Tuttavia, se hai net.ipv4.tcp_tw_reuse impostato su 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse ) allora il kernel può riutilizzare i socket in TIME_WAIT se determina che non ci saranno possibili conflitti nella numerazione dei segmenti TCP.