it-swarm-tr.com

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   -               
28
KTamas

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
22
Brandon

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.

16
David Pashley

Ö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.)

5
chaos

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.

4
Paul Tomblin

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).

2
Greg Bray

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
1
leecher