Lösung 1:
BEARBEITEN: tcp_fin_timeout NICHT steuern Sie die Dauer von TIME_WAIT, sie ist bei 60 Sekunden fest codiert
Wie von anderen erwähnt, habe ich einige Verbindungen in TIME_WAIT ist ein normaler Bestandteil der TCP-Verbindung. Sie können das Intervall sehen, indem Sie /proc/sys/net/ipv4/tcp_fin_timeout untersuchen :
[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60
Und ändern Sie es, indem Sie diesen Wert ändern:
[[email protected] admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
Oder dauerhaft durch Hinzufügen zu /etc/sysctl.conf
net.ipv4.tcp_fin_timeout=30
Wenn Sie den RPC-Dienst oder NFS nicht verwenden, können Sie ihn auch einfach deaktivieren:
/etc/init.d/nfsd stop
Und schalten Sie es vollständig aus
chkconfig nfsd off
Lösung 2:
TIME_WAIT ist normal. Es ist ein Zustand nach dem Schließen eines Sockets, der vom Kernel verwendet wird, um Pakete zu verfolgen, die möglicherweise verloren gegangen sind und zu spät zur Party aufgetaucht sind. Eine hohe Anzahl von TIME_WAIT-Verbindungen ist ein Symptom für viele kurzlebige Verbindungen, kein Grund zur Sorge.
Lösung 3:
Es ist nicht wichtig. Das bedeutet lediglich, dass Sie viele Sun-RCP-TCP-Verbindungen öffnen und schließen (1500-2500 davon alle 2-4 Minuten). Die TIME_WAIT Zustand ist, was ein Socket annimmt, wenn er geschlossen wird, um zu verhindern, dass Nachrichten für die falschen Anwendungen ankommen, wie sie es könnten, wenn der Socket zu schnell wiederverwendet würde, und für ein paar andere nützliche Zwecke. Machen Sie sich keine Sorgen.
(Es sei denn natürlich, Sie führen nichts aus, was so viele RCP-Operationen verarbeiten sollte. Dann machen Sie sich Sorgen.)
Lösung 4:
Etwas auf Ihrem System führt eine Menge RPC (Remote Procedure Calls) in Ihrem System durch (beachten Sie, dass sowohl Quelle als auch Ziel localhost sind). Das sieht man oft bei lockd für NFS-Mounts, aber vielleicht sieht man es auch bei anderen RPC-Aufrufen wie rpc.statd oder rpc.spray.
Sie könnten versuchen, "lsof -i" zu verwenden, um zu sehen, wer diese Sockets geöffnet hat, und zu sehen, was es tut. Es ist wahrscheinlich harmlos.
Lösung 5:
tcp_fin_timeout kontrolliert NICHT TIME_WAIT Verzögerung. Sie können dies sehen, indem Sie ss oder netstat mit -o verwenden, um die Countdown-Timer anzuzeigen:
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)
selbst wenn tcp_fin_timeout auf 3 gesetzt ist, beginnt der Countdown für TIME_WAIT immer noch bei 60. Wenn Sie jedoch net.ipv4.tcp_tw_reuse auf 1 gesetzt haben (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse ), dann kann der Kernel Sockets in TIME_WAIT wiederverwenden, wenn er feststellt, dass es keine möglichen Konflikte bei der Nummerierung von TCP-Segmenten geben wird.