Řešení 1:
UPRAVIT: tcp_fin_timeout NEPLATÍ ovládání TIME_WAIT trvání, je pevně zakódováno na 60s
Jak zmínili jiní, mít některá spojení v TIME_WAIT je normální součástí TCP spojení. Interval můžete vidět prozkoumáním /proc/sys/net/ipv4/tcp_fin_timeout :
[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60
A změňte ji úpravou této hodnoty:
[[email protected] admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
Nebo trvale přidáním do /etc/sysctl.conf
net.ipv4.tcp_fin_timeout=30
Také pokud nepoužíváte službu RPC nebo NFS, můžete je jednoduše vypnout:
/etc/init.d/nfsd stop
A úplně jej vypněte
chkconfig nfsd off
Řešení 2:
TIME_WAIT je normální. Je to stav po uzavření soketu, který používá jádro ke sledování paketů, které se mohly ztratit a mohly se objevit pozdě na straně. Vysoký počet TIME_WAIT připojení je příznakem získání mnoha krátkodobých připojení, není se čeho bát.
Řešení 3:
To není důležité. Znamená to pouze to, že otevíráte a zavíráte mnoho spojení Sun RCP TCP (1500–2500 každé 2–4 minuty). TIME_WAIT stav je to, do čeho soket přejde, když se zavře, aby se zabránilo příchodu zpráv pro nesprávné aplikace, jako by tomu bylo, kdyby byl soket znovu použit příliš rychle, a pro několik dalších užitečných účelů. Nedělejte si s tím starosti.
(Pokud ovšem ve skutečnosti nespouštíte nic, co by mělo zpracovávat tolik operací RCP. Pak si nedělejte starosti.)
Řešení 4:
Něco ve vašem systému provádí mnoho RPC (Remote Procedure Calls) ve vašem systému (všimněte si, že zdrojem i cílem je localhost). To je často vidět u lockd pro připojení NFS, ale můžete to vidět také u jiných volání RPC, jako je rpc.statd nebo rpc.spray.
Můžete zkusit použít "lsof -i", abyste viděli, kdo má tyto zásuvky otevřené, a uvidíte, co to dělá. Pravděpodobně je to neškodné.
Řešení 5:
tcp_fin_timeout neovládá TIME_WAIT zpoždění. Můžete to vidět pomocí ss nebo netstat s -o, abyste viděli odpočítávací časovače:
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)
i když je tcp_fin_timeout nastaveno na 3, odpočítávání pro TIME_WAIT stále začíná na 60. Pokud však máte net.ipv4.tcp_tw_reuse nastaveno na 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse ), pak jádro může znovu použít sockety v TIME_WAIT, pokud zjistí, že nedojde k žádným možným konfliktům v číslování segmentů TCP.