Solusi 1:
EDIT: tcp_fin_timeout TIDAK kontrol durasi TIME_WAIT, ini di-hardcode pada 60 detik
Seperti yang disebutkan oleh orang lain, memiliki beberapa koneksi di TIME_WAIT adalah bagian normal dari koneksi TCP. Anda dapat melihat intervalnya dengan memeriksa /proc/sys/net/ipv4/tcp_fin_timeout :
[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60
Dan ubahlah dengan memodifikasi nilai tersebut:
[[email protected] admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
Atau secara permanen dengan menambahkannya ke /etc/sysctl.conf
net.ipv4.tcp_fin_timeout=30
Selain itu, jika Anda tidak menggunakan layanan RPC atau NFS, Anda dapat mematikannya saja:
/etc/init.d/nfsd stop
Dan matikan sepenuhnya
chkconfig nfsd off
Solusi 2:
TIME_WAIT normal. Ini adalah keadaan setelah soket ditutup, digunakan oleh kernel untuk melacak paket yang mungkin hilang dan terlambat datang ke pesta. Jumlah koneksi TIME_WAIT yang tinggi adalah gejala mendapatkan banyak koneksi berumur pendek, bukan hal yang perlu dikhawatirkan.
Solusi 3:
Itu tidak penting. Semua itu menandakan bahwa Anda membuka dan menutup banyak koneksi Sun RCP TCP (1500-2500 di antaranya setiap 2-4 menit). TIME_WAIT state adalah apa yang masuk ke soket ketika ditutup, untuk mencegah pesan tiba untuk aplikasi yang salah seperti jika soket digunakan kembali terlalu cepat, dan untuk beberapa tujuan berguna lainnya. Jangan khawatir tentang itu.
(Kecuali, tentu saja, Anda tidak benar-benar menjalankan apa pun yang seharusnya memproses banyak operasi RCP. Maka, khawatirlah.)
Solusi 4:
Sesuatu di sistem Anda melakukan banyak RPC (Remote Procedure Calls) di dalam sistem Anda (perhatikan sumber dan tujuan adalah localhost). Itu sering terlihat untuk lockd untuk mount NFS, tetapi Anda mungkin juga melihatnya untuk panggilan RPC lain seperti rpc.statd atau rpc.spray.
Anda dapat mencoba menggunakan "lsof -i" untuk melihat siapa yang membuka soket tersebut dan melihat apa yang dilakukannya. Mungkin tidak berbahaya.
Solusi 5:
tcp_fin_timeout TIDAK mengontrol TIME_WAIT menunda. Anda dapat melihatnya dengan menggunakan ss atau netstat dengan -o untuk melihat penghitung waktu mundur:
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)
bahkan dengan tcp_fin_timeout disetel ke 3 hitungan mundur untuk TIME_WAIT masih dimulai pada 60. Namun jika Anda memiliki net.ipv4.tcp_tw_reuse disetel ke 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse ) maka kernel dapat menggunakan kembali soket di TIME_WAIT jika menentukan tidak akan ada kemungkinan konflik dalam penomoran segmen TCP.