Büyük miktarda TIME_WAIT bağlantısı diyor netstat
Tamam, bu beni korkutuyor - bunlardan yaklaşık 1500-2500 tanesini görüyorum:
[email protected]:# netstat
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:60930 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60934 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60941 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60947 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60962 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60969 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60998 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60802 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60823 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60876 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60886 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60898 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60897 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60905 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60918 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60921 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60673 localhost:sunrpc TIME_WAIT
tcp 0 0 localhost:60680 localhost:sunrpc TIME_WAIT
[etc...]
[email protected]:# netstat | grep 'TIME_WAIT' |wc -l
1942
Bu sayı hızla değişiyor.
Bu neden olabilir hiçbir fikrim yok bu yüzden oldukça sıkı bir iptables yapılandırma var. herhangi bir fikir?
Teşekkürler,
Tamas
Düzenleme: 'netstat -anp' çıktısı:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:60968 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60972 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60976 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60981 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60980 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60983 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60999 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60809 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60834 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60872 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60896 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60919 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60710 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60745 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60765 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60772 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60558 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60564 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60600 127.0.0.1:111 TIME_WAIT -
tcp 0 0 127.0.0.1:60624 127.0.0.1:111 TIME_WAIT -
DÜZENLEME: tcp_fin_timeout ETMEZ TIME_WAIT süresini kontrol et, 60 saniyede sabit kodlanmış
Başkaları tarafından belirtildiği gibi, TIME_WAIT TCP bağlantısının normal bir parçasıdır. /proc/sys/net/ipv4/tcp_fin_timeout:
[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60
Ve bu değeri değiştirerek değeri değiştirin:
[[email protected] admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
Veya kalıcı olarak /etc/sysctl.conf dosyasına ekleyerek
net.ipv4.tcp_fin_timeout=30
Ayrıca, RPC hizmetini veya NFS'yi kullanmıyorsanız, hizmeti kapatabilirsiniz:
/etc/init.d/nfsd stop
Ve tamamen kapat
chkconfig nfsd off
TIME_WAIT normal. Bir soket kapandıktan sonra, çekirdek tarafından kaybolan ve partiye geç açılan paketleri izlemek için kullanılan bir durumdur. Çok sayıda TIME_WAIT bağlantısı, endişelenecek bir şey değil, çok sayıda kısa ömürlü bağlantı almanın bir belirtisidir.
Önemli değil. Bunun anlamı, Sun RCP TCP bağlantılarını (her 2-4 dakikada bir 1500-2500) açıp kapatmanızdır. TIME_WAIT durumu, soket çok hızlı bir şekilde yeniden kullanılmışsa ve birkaç başka faydalı amaç için iletilerin yanlış uygulamalar için gelmesini önlemek amacıyla, bir soketin kapatıldığında girdiği durumdur. Endişelenme.
(Tabii ki, aslında birçok RCP operasyonunu işlemesi gereken bir şey çalıştırmıyorsanız. O zaman endişe edin.)
Sisteminizdeki bir şey, sisteminizde çok fazla RPC (Uzaktan Yordam Çağrısı) yapıyor (hem kaynak hem de hedefin yerel ana bilgisayar olduğuna dikkat edin). Bu genellikle NFS bağlantıları için lockd için görülür, ancak bunu rpc.statd veya rpc.spray gibi diğer RPC çağrıları için de görebilirsiniz.
Bu soketleri kimin açtığını ve ne yaptığını görmek için "lsof -i" komutunu kullanmayı deneyebilirsiniz. Muhtemelen zararsızdır.
tcp_fin_timeout, TIME_WAIT Gecikmesini kontrol ETMEZ. Geri sayım zamanlayıcılarını görmek için -o ile ss veya netstat kullanarak bunu görebilirsiniz:
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)
tcp_fin_timeout 3 olarak ayarlanmış olsa bile TIME_WAIT için geri sayım hala 60'da başlar. Ancak net.ipv4.tcp_tw_reuse 1 (echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse) olarak ayarlanmışsa, çekirdek TIME_WAIT içindeki soketleri yeniden kullanamazsa TCP segment numaralandırmasında olası çakışmalar olabilir).
Ben de aynı problemi yaşadım. Neler olup bittiğini öğrenmek için birkaç saatime mal oldum. Benim durumumda, bunun nedeni, netstat IP'ye karşılık gelen ana bilgisayar adını aramaya çalışmasıydı (gethostbyaddr API'sini kullandığını varsayıyorum). /Etc/nsswitch.conf dosyasına sahip gömülü bir Linux kurulumu kullanıyordum. Şaşırtıcı bir şekilde, sorun sadece bir netstat -a (bunu ayrıntılı ve hata ayıklama modunda portmap çalıştırarak) yaptığınızda ortaya çıkar.
Şimdi ne oldu: Varsayılan olarak, arama işlevleri de bir ana bilgisayar adı sorgulamak için ypbind daemon (Güneş Sarı Sayfalar, NIS olarak da bilinir) başvurun. Bu hizmeti sorgulamak için, bu hizmetin bağlantı noktasını almak üzere portmapper portmap ile iletişim kurulmalıdır. Şimdi benim durumumda portmapper TCP ile temasa geçti. Daha sonra portmapper, libc işlevine böyle bir hizmetin olmadığını ve TCP bağlantısının kapandığını söyler. Bildiğimiz gibi kapalı TCP bağlantılar, bazıları için TIME_WAIT durumuna girer) Böylece, netstat listeleme sırasında bu bağlantıyı yakalar ve yeni bir IP'ye sahip bu yeni satır, TIME_WAIT durumunda yeni bir bağlantı oluşturan yeni bir istek gönderir ve bu şekilde devam eder ...
Bu sorunu çözmek için, rpc NIS hizmetlerini kullanmayan bir /etc/nsswitch.conf dosyası oluşturun, yani aşağıdaki içeriklerle:
passwd: files
group: files
hosts: files dns
networks: files dns
services: files
protocols: files
netmasks: files