Banyak koneksi TCP dalam keadaan TIME_WAIT di windows 2008 - berjalan di amazon AWS

OS: Windows Server 2008, SP2 (berjalan di EC2 Amazon).

Menjalankan aplikasi web menggunakan Apache httpd & tomcat server 6.02 dan server Web memiliki pengaturan tetap hidup.

Ada sekitar 69.250 (http port 80) + 15000 (selain port 80) koneksi TCP dalam keadaan TIME_WAIT (digunakan netstat & tcpview). Koneksi ini tampaknya tidak menutup bahkan setelah menghentikan server web (menunggu 24 jam)

Penghitung monitor kinerja:

• Koneksi Aktif TCPv4: 145K
• Koneksi Pasif TCPv4: 475K
• Koneksi Kegagalan TCPv4: 16K
• Reset Koneksi TCPv4: 23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters tidak memiliki kunci TcpTimedWaitDelay, jadi nilainya harus default (2 * MSL, 4 menit)

Bahkan jika ada ribuan permintaan koneksi yang datang pada saat yang sama, mengapa windows OS tidak dapat membersihkannya pada akhirnya?
Apa yang bisa menjadi alasan di balik situasi ini?
Apakah ada cara untuk secara paksa menutup semua koneksi TIME_WAIT ini tanpa memulai ulang OS windows?

Setelah beberapa hari, aplikasi kami berhenti mengambil koneksi baru.

Kami telah menangani masalah ini juga. Sepertinya Amazon menemukan akar masalahnya dan memperbaikinya. Ini info yang mereka berikan kepada saya.

Hai, saya menempelkan di bawah penjelasan tentang apa yang menyebabkan masalah ini. Berita baiknya adalah baru-baru ini diperbaiki oleh tim teknik kami. Untuk memperbaikinya, yang harus Anda lakukan adalah BERHENTI / MULAI contoh Windows Server 2008 di mana Anda melihat masalah ini. Sekali lagi, saya tidak berbicara tentang REBOOT yang berbeda. STOP / START menyebabkan instance berpindah ke host (sehat) yang berbeda. Ketika instance ini diluncurkan lagi, mereka akan berjalan di host yang memiliki perbaikan di tempat sehingga mereka tidak akan memiliki masalah ini lagi. Sekarang di bawah ini adalah penjelasan teknis tentang masalah ini. Setelah penyelidikan mendalam, kami menemukan bahwa ketika menjalankan Windows 2008 x64 pada sebagian besar jenis instance yang tersedia, kami telah mengidentifikasi masalah yang dapat mengakibatkan koneksi TCP yang tetap dalam TIME_WAIT / CLOSE_WAIT untuk periode waktu yang terlalu lama (dalam beberapa kasus, tetap dalam kondisi ini tanpa batas waktu). Sementara di negara-negara ini, pasangan soket tertentu tetap tidak dapat digunakan dan jika cukup menumpuk, akan menyebabkan kelelahan port untuk port yang dimaksud. Jika keadaan khusus ini terjadi, satu-satunya solusi untuk menghapus pasangan soket yang dimaksud adalah me-reboot instance yang dimaksud. Kami telah menentukan penyebabnya adalah nilai-nilai yang dihasilkan oleh fungsi pengatur waktu di API kernel Windows 2008 yang, pada banyak platform 64-bit kami, terkadang akan mengambil nilai yang sangat jauh di masa depan. Ini memengaruhi tumpukan TCP dengan menyebabkan cap waktu pada pasangan soket TCP dicap secara signifikan jauh di masa depan. Menurut Microsoft, ada penghitung kumulatif tersimpan yang tidak akan diperbarui kecuali nilai yang dihasilkan oleh panggilan API ini lebih besar dari nilai kumulatif. Hasil akhirnya adalah bahwa soket yang dibuat setelah titik ini semua akan dicap terlalu jauh di masa depan sampai waktu mendatang tercapai. Dalam beberapa kasus, kami telah melihat nilai ini beberapa ratus hari ke depan, sehingga pasangan soket tampaknya macet selamanya.

Jawaban Ryan adalah saran umum yang baik kecuali bahwa itu tidak berlaku untuk kondisi yang dialami Ravi di EC2. Kami juga telah melihat masalah ini dan untuk alasan apa pun Windows sepenuhnya mengabaikan TcpTimedWaitDelay dan tidak pernah melepaskan soket dari status TIMED_WAIT-nya.

Menunggu tidak membantu ... memulai ulang aplikasi tidak membantu ... satu-satunya obat yang kami temukan adalah memulai ulang OS. Jelek banget.

Saya benar-benar menemukan utas ini secara acak sambil mencari untuk men-debug masalah yang terpisah, tetapi ini adalah masalah kecil yang dibesarkan, tetapi terkenal dengan Windows pada EC2. Kami dulu memiliki dukungan premium, dan membahas hal ini dengan mereka dalam pengaturan non-publik melalui saluran itu, tapi ini adalah masalah terkait yang kita tidak bahas dalam forum publik .

Seperti yang telah disebutkan orang lain, Anda perlu menyeleksi Server Windows di luar kotak. Namun, dengan cara yang sama bahwa StopWatch tidak berfungsi di utas di atas, tumpukan TCP / IP juga menggunakan QueryPerformanceCounterpanggilan untuk menentukan kapan periode TCP_TIME_WAIT seharusnya berlangsung. Masalahnya adalah bahwa pada EC2, mereka telah mengalami, dan tahu tentang, masalah yang QueryPerformanceCountermenjadi kacau, dan mungkin kembali kali jauh, jauh ke masa depan; bukan karena negara TIME_WAIT Anda diabaikan, itu karena waktu kedaluwarsa TIME_WAIT berpotensi bertahun-tahun ke depan. Saat berjalan dalam pengaturan httpd, Anda dapat melihat bagaimana Anda dengan cepat mengakumulasikan soket zombie ini begitu negara ditemui (umumnya kita melihat bahwa ini adalah peristiwa yang terpisah, bukan berarti Anda secara perlahan mengakumulasi zombie).

Apa yang kami lakukan adalah menjalankan layanan di latar belakang yang menanyakan jumlah soket dalam status TIME_WAIT, dan setelah ini melayang di atas ambang batas tertentu, kami mengambil tindakan (reboot server). Entah bagaimana dalam 45 detik terakhir , seseorang menunjukkan bahwa Anda dapat menghentikan / memulai server untuk memperbaiki masalah - Saya sarankan Anda memasangkan dua pendekatan ini.

Pengaturan default untuk tumpukan TCP di Windows, untuk sedikitnya, tidak optimal untuk sistem yang akan meng-host server HTTP.

Untuk mendapatkan yang terbaik dari mesin windows Anda ketika digunakan sebagai server HTTP, ada beberapa parameter yang biasanya Anda ubah seperti MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval dll

Saya telah menulis catatan untuk diri sendiri tentang ini beberapa tahun yang lalu, kalau-kalau saya perlu default cepat untuk memulai. Jangan ragu untuk memahami parameternya dan kemudian mengubahnya.

Tidak terkait dengan AWS, kami hanya mengalami masalah ini, sepertinya merupakan hasil dari artikel KB ini:

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

Pada dasarnya, ini akan dimulai jika sistem menyala> 497 hari dan perbaikan terbaru belum diterapkan. Sebuah reboot telah, tentu saja, membersihkannya - kita mungkin tidak tahu untuk 16 bulan ke depan jika perbaikan terbaru berhasil, tetapi ini dapat membantu siapa saja yang memiliki server lama di luar sana.

Saya mengalami hal yang hampir persis sama pada sejumlah kotak dengan Windows Server 2008 R2 x64 dengan SP1, kebanyakan dengan CLOSE_WAIT (yang agak berbeda dari TIME_WAIT). Saya menemukan jawaban ini yang mereferensikan KB di Microsoft dan perbaikan terbaru jika server berjalan di belakang load balancer (milik saya). Setelah menginstal perbaikan terbaru dan me-reboot, semua hal CLOSE_WAIT diselesaikan.