TIME_WAIT içindeki soket sayısını nasıl azaltabilirim?

Ubuntu Sunucusu 10.04.1 x86

Nginx'in arkasında FCGI HTTP servisi olan ve birçok farklı istemciye çok sayıda küçük HTTP isteği sunan bir makinem var. (Yoğun saatlerde saniyede yaklaşık 230 istek, başlıklı ortalama yanıt boyutu 650 bayttır, günde birkaç milyon farklı müşteri.)

Sonuç olarak, TIME_WAIT içinde asılı bir sürü soketim var (grafik aşağıdaki TCP ayarlarıyla yakalanmıştır):

TIME_WAIT

Soket sayısını azaltmak istiyorum.

Bundan başka ne yapabilirim?

$ cat / proc / sys / net / ipv4 / tcp_fin_timeout
1
$ cat / proc / sys / net / ipv4 / tcp_tw_recycle
1
$ cat / proc / sys / net / ipv4 / tcp_tw_reuse
1

Güncelleme: makinedeki gerçek servis düzeniyle ilgili bazı detaylar:

istemci ----- TCP soketi -> nginx (yük dengeleyici ters vekil) 
       ----- TCP-soketi -> nginx (işçi) 
       - etki alanı soketi -> fcgi yazılımı
                          - tek kalıcı bir TCP soketi -> Redis
                          - tek kalıcı bir TCP soketi -> MySQL (diğer makine)

Muhtemelen yük dengeleyici -> çalışan bağlantısını etki alanı soketlerine de değiştirmeliyim, ancak TIME_WAIT soketleri ile ilgili sorun devam edecek - Yakında ayrı bir makineye ikinci bir işçi eklemeyi planlıyorum. Bu durumda etki alanı soketleri kullanamazsınız.

— Alexander Gladysh
kaynak

Görünüşe göre Munin utanmadan yalan söylüyor. Kyle'ın cevabına yapılan yorumları görün. Şimdi bunu inceliyorum.

— Alexander Gladysh,

Munin hakkında bir soru düzenlendi: serverfault.com/questions/212200/…

— Alexander Gladysh

Şimdi Munin yalan söylemiyor gibi gözüküyor, ama ben yanlış

— bölgeye

Yanıtlar:

Başlamak için yapmanız gereken bir şey düzeltmektir net.ipv4.tcp_fin_timeout=1. Bu düşük bir yoldur, muhtemelen 30'dan daha düşük olmamalıdır.

Çünkü bu nginx'in arkasında. Bu, nginx'in ters bir vekil olarak davrandığı anlamına mı geliyor? Bu durumda bağlantılarınız 2x olur (biri istemciye, diğeri web sunucularınıza). Bu soketlerin hangi ucuna ait olduğunu biliyor musunuz?

Güncelleme:
fin_timeout, FIN-WAIT-2'de ne kadar süre kaldıklarını gösterir ( networking/ip-sysctl.txtçekirdek belgelerinde):

tcp_fin_timeout - INTEGER
        Time to hold socket in state FIN-WAIT-2, if it was closed
        by our side. Peer can be broken and never close its side,
        or even died unexpectedly. Default value is 60sec.
        Usual value used in 2.2 was 180 seconds, you may restore
        it, but remember that if your machine is even underloaded WEB server,
        you risk to overflow memory with kilotons of dead sockets,
        FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
        because they eat maximum 1.5K of memory, but they tend
        to live longer. Cf. tcp_max_orphans.

Sanırım, Linux'un TIME_WAIT soket numarasını, üzerlerinde belki 32k büyük harf gibi görünmesine karşı korumasına izin vermek zorundasınız ve bu, Linux'un onları geri dönüştürdüğü yer. Bu 32k, bu bağlantıda belirtilir :

Ayrıca, / proc / sys / net / ipv4 / tcp_max_tw_buckets'i kafa karıştırıcı buluyorum. Varsayılan ayar 180000 olarak ayarlanmış olmasına rağmen, maksimum tw kovadan bağımsız olarak sistemimde 32K TIME_WAIT soketi olduğunda bir TCP bozulması görüyorum.

Bu bağlantı aynı zamanda TIME_WAIT durumunun 60 saniye olduğunu ve proc ile ayarlanamadığını gösterir.

Rastgele eğlence gerçeği:
Her bir soket için zamanlayıcıda netstat bulunan zamanlayıcıları görebilirsiniznetstat -on | grep TIME_WAIT | less

Yeniden kullanma Vs Geri Dönüşümü:
Bunlar ilginçtir, yeniden kullanımı, time_Wait soketlerinin yeniden kullanılmasını mümkün kılar ve geri dönüşüm TURBO moduna geçirir:

tcp_tw_recycle - BOOLEAN
        Enable fast recycling TIME-WAIT sockets. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

tcp_tw_reuse - BOOLEAN
        Allow to reuse TIME-WAIT sockets for new connections when it is
        safe from protocol viewpoint. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

Net.ipv4.tcp_tw_recycle, NAT istemcilerinde sorunlara neden olduğu için kullanılmasını tavsiye etmem .

Belki ikisinin de açılmamasını deneyebilir ve ne gibi bir etkisinin olduğunu görebilirsiniz (Her seferinde bir tane deneyin ve kendi başlarına nasıl çalıştıklarını görün)? netstat -n | grep TIME_WAIT | wc -lMunin'den daha hızlı geri bildirim için kullanırdım .

— Kyle Brandt
kaynak

@Kyle: Hangi değeri önerirsiniz net.ipv4.tcp_fin_timeout?

— Alexander Gladysh,

@Kyle: istemci - TBM soketi -> nginx (yük dengeleyici ters proxy) - TCP-soket -> nginx (çalışan) - etki alanı soketi -> fcgi yazılımı

— Alexander Gladysh

Söylerdim 30ya da belki 20. Deneyin ve görün. Çok fazla yükünüz var, bu yüzden çok fazla TIME_WAIT mantıklı.

— Kyle Brandt

@Kyle: aptalca bir soru (şimdiye kadar maalesef burada bir kargo-kült seviyesine değilim) için üzgün, ama ben değiştirdiğinizde görmek için tam olarak ne beklemeliyim net.ipv4.tcp_fin_timeoutgelen 1için 20?

— Alexander Gladysh,

İşte güzel bir astar netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c. Yani, @Alex, eğer Munin beğenmiyorsa, belki de bu istatistikleri nasıl izlediğini araştırın. Belki de tek sorun Munin'in sana kötü veriler vermesi :-)

— Kyle Brandt

tcp_tw_reuse, TIME_WAIT bağlantılarının yeniden kullanılmasına izin verdiği için nispeten güvenlidir.

Ayrıca, eğer portların tükenmesi sorunsa, yük dengeleyicinizin arkasındaki farklı portları dinleyen daha fazla servis çalıştırabilirsiniz.

— andrew pate
kaynak