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.
sumber
QueryPerformanceCounter
akar masalah masih ada dan hanya masalah TCP yang sudah diatasi? Terima kasih atas wawasan Anda!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.
sumber
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
QueryPerformanceCounter
panggilan untuk menentukan kapan periode TCP_TIME_WAIT seharusnya berlangsung. Masalahnya adalah bahwa pada EC2, mereka telah mengalami, dan tahu tentang, masalah yangQueryPerformanceCounter
menjadi 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.
sumber
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.
sumber
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.
sumber
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.
sumber