Windows 2008'de TIME_WAIT durumunda tonlarca TCP bağlantısı - amazon AWS'de çalışıyor

İşletim Sistemi: Windows Server 2008, SP2 (EC2 Amazon üzerinde çalışıyor).

Apache httpd & tomcat server 6.02 ve Web sunucusunu kullanarak web uygulamasını çalıştırmak, canlı tutma ayarlarına sahiptir.

TIME_WAIT durumunda 69.250 (http bağlantı noktası 80) + 15000 (bağlantı noktası 80 dışında) TCP bağlantısı vardır (netstat & tcpview kullanılır). Web sunucusunu durdurduktan sonra bile bu bağlantılar kapanmıyor gibi görünüyor (24 saat bekledi)

Performans izleme sayaçları:

• TCPv4 Aktif Bağlantılar: 145K
• TCPv4 Pasif Bağlantılar: 475K
• TCPv4 Hata Bağlantıları: 16K
• TCPv4 Bağlantıları Sıfırla: 23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters TcpTimedWaitDelay anahtarı olmadığından değer varsayılan olmalıdır (2 * MSL, 4 dk.)

Aynı anda binlerce bağlantı isteği gelse bile, Windows işletim sistemi neden bunları sonunda temizleyemiyor?
Bu durumun arkasındaki nedenler neler olabilir?
Tüm bu TIME_WAIT bağlantılarını Windows işletim sistemini yeniden başlatmadan zorla kapatmanın bir yolu var mı?

Birkaç gün sonra uygulama yeni bağlantılar almayı bırakır.

Biz de bu konuyu ele alıyoruz. Amazon'un kök nedenini bulup düzelttiği anlaşılıyor. İşte bana verdikleri bilgiler.

Merhaba, ben bu soruna neyin neden olduğunu açıklayan bir açıklama yapıştırıyorum. İyi haber şu ki, bu son zamanlarda mühendislik ekibimiz tarafından düzeltildi. Düzeltmek için tek yapmanız gereken, bu sorunu gördüğünüz Windows Server 2008 örneklerini DURDUR / BAŞLATMAK. Yine farklı olan REBOOT'tan bahsetmiyorum. DURDUR / BAŞLAT, örneğin farklı (sağlıklı) bir ana bilgisayara taşınmasına neden olur. Bu örnekler yeniden başlatıldığında, düzeltmeyi içeren ana bilgisayarlarda çalışırlar, böylece bu sorunu tekrar yaşamayacaklardır. Şimdi bu sorunun mühendislik açıklaması aşağıdadır. Ayrıntılı bir araştırmadan sonra, Windows 2008 x64'ü en uygun örnek türlerinde çalıştırdığımızda, TIME_WAIT / CLOSE_WAIT içinde aşırı uzun süre kalan (bazı durumlarda bu durumda süresiz olarak kalan) TCP bağlantılarına neden olabilecek bir sorun belirlediler. Bu durumlarda, belirli soket çiftleri kullanılamaz halde kalır ve yeterli miktarda birikirse, söz konusu portlar için portun tükenmesine neden olur. Bu özel durum meydana gelirse, söz konusu soket çiftlerini temizlemenin tek çözümü söz konusu örneği yeniden başlatmaktır. Bunun nedenini, Windows 2008 çekirdek API'sinde, 64 bit platformlarımızın çoğunda, zaman zaman gelecekte çok uzak bir değer alacak olan bir zamanlayıcı işlevi tarafından üretilen değerler olarak belirledik. Bu, TCP soketi çiftlerindeki zaman damgalarının gelecekte önemli ölçüde damgalanmasına neden olarak TCP yığınını etkiler. Microsoft'a göre, bu API çağrısı tarafından üretilen değer kümülatif değerden büyük olmadığı sürece güncellenmeyecek depolanmış bir kümülatif sayaç vardır. Nihai sonuç, bu noktadan sonra oluşturulan soketlerin, gelecekteki zamana ulaşılana kadar gelecekte çok fazla damgalanmasıdır. Bazı durumlarda, bu değeri birkaç yüz gün sonra gördük, böylece soket çiftleri sonsuza kadar sıkışmış görünüyor.

Ryan'ın yanıtı, Ravi'nin EC2'de yaşadığı durum için geçerli olmaması dışında iyi bir genel tavsiye. Biz de bu sorunu gördük ve herhangi bir nedenle Windows TcpTimedWaitDelay'ı tamamen görmezden geliyor ve soketi asla TIMED_WAIT durumundan serbest bırakmıyor.

Beklemek işe yaramaz ... uygulamayı yeniden başlatmak işe yaramaz ... Bulduğumuz tek çözüm işletim sistemini yeniden başlatmaktır. Gerçekten çirkin.

Ayrı bir sorunu ayıklamak için çalışırken bu konuyu tamamen rasgele buldum, ancak bu biraz getirildi, ancak EC2'de Windows ile bilinen bir sorundur. Biz prim desteği için kullanılır ve bu kanal aracılığıyla bir halka açık olmayan bir ortamda onlarla tartıştık, ama bu biz bir diğer konu etmedi kamu forumlarda tartışmak .

Diğerlerinin de belirttiği gibi, Windows Sunucularını kutudan çıkarmanız gerekir. Ancak, StopWatch'un yukarıdaki iş parçacığında çalışmadığı gibi, TCP / IP yığını da QueryPerformanceCounterTCP_TIME_WAIT süresinin tam olarak ne zaman süreceğini belirlemek için çağrıyı kullanır . Sorun şu ki, EC2'de, samanlaşan bir sorunla karşılaşmışlar ve bunu biliyorlar QueryPerformanceCounterve zamanları geleceğe çok geri döndürebilirler; TIME_WAIT durumunuz göz ardı edilmiyor, TIME_WAIT'in sona erme süresinin gelecekteki potansiyel yıllar olduğu değil. Bir httpd ayarında çalışırken, durumla karşılaşıldığında bu zombi soketlerini nasıl hızlı bir şekilde biriktirdiğinizi görebilirsiniz (genellikle bunun yavaş bir zombi biriktirdiğini değil, ayrı bir olay olduğunu görüyoruz).

Yaptığımız şey, arka planda TIME_WAIT durumundaki soket sayısını sorgulayan bir hizmet çalıştırmaktır ve bu belirli bir eşiğin üzerine geldiğinde harekete geçeriz (sunucuyu yeniden başlatın). Bir şekilde son 45 saniye içinde , birisi sorunu çözmek için sunucuyu durdurabileceğinizi / başlatabileceğinizi belirtti - bu iki yaklaşımı birleştirmenizi öneririm.

Windows'daki TCP yığını için varsayılan ayarlar, en azından, bir HTTP sunucusu barındıracak sistemler için en uygun seçenek değildir.

HTTP sunucusu olarak kullanıldığında windows makinenizden en iyi şekilde yararlanmak için, normalde MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval vb.

Başlamak için bazı hızlı varsayılanlara ihtiyacım olması durumunda, birkaç yıl önce bu konuda bir not yazmıştım . Parametreleri anlamaktan çekinmeyin ve sonra onları değiştirin.

AWS ile ilgili olmayan, sadece bu problemle karşılaştık, bu KB makalesinin bir sonucu gibi görünüyor:

http://support.microsoft.com/kb/2553549/en-us

Temel olarak, bir sistem> 497 güne kadar çalışırsa ve düzeltme uygulanmamışsa devreye girer. Bir yeniden başlatma, elbette, onu temizledi - düzeltmenin işe yarayıp yaramadığını önümüzdeki 16 ay boyunca bilmiyor olabiliriz, ancak bu, orada uzun süreli çalışma sunucuları olan herkese yardımcı olabilir.

Windows Server 2008 R2 x64 SP1 ile, çoğunlukla CLOSE_WAIT (ki bu biraz TIME_WAIT biraz farklı) ile kutuları üzerinde hemen hemen aynı şeyi yaşıyordu. Sunucular bir yük dengeleyici (ki benim olan) arkasında çalışıyorsa , Microsoft'ta bir KB ve bir düzeltme başvurulan bu cevap çarptı . Düzeltmeyi yükleyip yeniden başlattıktan sonra tüm CLOSE_WAIT şeyler çözüldü.