Bagaimana TIDAK mendapatkan banyak apache koneksi CLOSE_WAIT?

netstat menunjukkan bahwa ada 153 koneksi yang berstatus CLOSE_WAIT. Koneksi tidak pernah ditutup. Jadi lembur server dipenuhi dengan koneksi ini yang mengisi RAM dan sekarang situs web tidak memuat.

netstat menunjukkan banyak hal seperti berikut:

tcp      160      0 my_server_name:http         my_server_name:51584        CLOSE_WAIT
tcp      160      0 my_server_name:http         my_server_name:51586        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50827        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50830        CLOSE_WAIT
tcp      312      0 my_server_ip.static.:http rate-limited-proxy-72:61249 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:58663 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:34655 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:56681 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:40829 CLOSE_WAIT
tcp      576      0 my_server_ip.static.:http b3090792.crawl.yahoo.:38278 CLOSE_WAIT
tcp       47      0 my_server_ip.static.:http 203.200.5.143.ill-bgl:49379 CLOSE_WAIT

Jika saya melihat appache error_log, sebelum situasi CLOSE_WAIT datang ada garis-garis seperti berikut

[warn] child process 15670 still did not exit, sending a SIGTERM
[error] child process 15670 still did not exit, sending a SIGKILL
[notice] child pid 3511 exit signal Segmentation fault (11)

Setup saya Apache 2.2.3 RAM 1024 MB (burst 2048 MB) rilis CentOS 5.3 (Final) menjalankan 2 instalasi WPMU 2.9.2

Latar Belakang

Socket memasuki keadaan CLOSE_WAIT ketika ujung jarak jauh mengakhiri koneksi mengirim paket dengan set FIN flag. Kemudian menunggu dalam kondisi ini untuk aplikasi lokal ke close()soket dan kemudian mengirimkan FIN sendiri ke klien dan mentransisikan soket ke keadaan LAST_ACK. Lihat juga diagram transisi keadaan TCP dan RFC 793 .

Perhatikan juga bahwa CLOSE_WAIT tidak terkait dengan TIME_WAIT yang terkenal karena yang pertama terjadi pada cabang tutup pasif (ujung jauh ditutup terlebih dahulu) sedangkan yang kedua pada cabang tutup aktif (ujung lokal ditutup lebih dulu).

Deskripsi masalah

Biasanya transisi koneksi dari CLOSE_WAIT ke LAST_ASK cukup cepat. Jika alamat dan port jarak jauh terus berubah dengan cepat, maka sejumlah koneksi dalam status CLOSE_WAIT mungkin merupakan konsekuensi dari sejumlah besar koneksi yang dibuka, digunakan, dan ditutup. Kinerja sistem harus diperiksa, tetapi dengan sendirinya ini bukan merupakan masalah.

Jika alamat jarak jauh dan port berubah secara lambat, ini menunjukkan bahwa proses aplikasi perlu menunggu CPU yang mana hal ini akan menyebabkan rata-rata beban tinggi.

Jika di sisi lain alamat jarak jauh dan port tetap konstan dan jumlah koneksi dalam keadaan CLOSE_WAIT terus bertambah, kemungkinan besar mengindikasikan masalah dengan aplikasi tersebut. Ini adalah kasus khusus dari bug kebocoran sumber daya: aplikasi bocor soket terbuka dan bukannya menutupnya tepat waktu. Ini menghabiskan memori kernel dan pada akhirnya akan membuat aplikasi gagal setelah mencapai jumlah maksimum deskriptor file terbuka.

Namun perlu dicatat bahwa laju kebocoran mungkin lambat. Seringkali bug seperti ini merupakan hasil dari kegagalan untuk menangani pengecualian di tengah permintaan, mengganggu aliran eksekusi di utas pekerja yang selanjutnya dapat mencegah pembersihan (termasuk penutupan soket). Pengecualian yang menyinggung mungkin jarang terjadi.

Solusi sementara

Solusi sementara untuk masalah ini adalah dengan meningkatkan batasan pada deskriptor file terbuka dan secara berkala restart aplikasi ketika (lebih disukai sebelum) masalah mulai mempengaruhi kinerja. Perhatikan bahwa ini dapat secara tidak sengaja memengaruhi koneksi yang sedang dibuka. Keberadaan server yang berlebihan dan load balancing dapat membantu menyembunyikan masalah dari pengguna.

Solusi permanen

Solusi permanen untuk masalah ini adalah menggunakan versi aplikasi tanpa bug. Sejauh mana solusi sementara membahayakan pengguna dan bisnis, kesiapan rilis yang ditambal dan keadaan rilis kerja terakhir membantu memutuskan apakah akan mengembalikan ke versi kerja aplikasi yang terakhir atau menunggu perbaikan.