Làm thế nào để KHÔNG nhận được nhiều kết nối apache CLOSE_WAIT?

netstat cho thấy có 153 kết nối đang ở trạng thái CLOSE_WAIT. Các kết nối không bao giờ bị đóng. Vì vậy, quá giờ máy chủ chứa đầy các kết nối này sẽ lấp đầy RAM và bây giờ các trang web không tải.

netstat hiển thị nhiều như sau:

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

Nếu tôi nhìn vào appache error_log, trước khi tình huống CLOSE_WAIT xuất hiện, có những dòng như sau

[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)

Thiết lập của tôi Apache 2.2.3 RAM 1024 MB (nổ 2048 MB) Bản phát hành CentOS 5.3 (Bản cuối) chạy 2 cài đặt WPMU 2.9.2

Lý lịch

Ổ cắm vào trạng thái CLOSE_WAIT khi đầu từ xa chấm dứt kết nối gửi gói với cờ FIN được đặt. Sau đó, nó chờ trong trạng thái này cho ứng dụng cục bộ đến close()ổ cắm và sau đó gửi FIN của chính nó đến máy khách và chuyển ổ cắm sang trạng thái LAST_ACK. Xem thêm sơ đồ chuyển trạng thái TCP và RFC 793 .

Cũng lưu ý rằng CLOSE_WAIT không liên quan đến TIME_WAIT khét tiếng vì trước đây xảy ra trên nhánh đóng thụ động (đầu cuối đóng trước) trong khi đầu sau trên nhánh đóng hoạt động (đầu cuối cục bộ đóng trước).

Mô tả vấn đề

Thông thường các kết nối chuyển từ CLOSE_WAIT sang LAST_ASK khá nhanh. Nếu địa chỉ và cổng từ xa tiếp tục thay đổi nhanh thì một số lượng kết nối hợp lý ở trạng thái CLOSE_WAIT có thể chỉ đơn giản là hậu quả của một số lượng lớn kết nối được mở, sử dụng và đóng. Hiệu năng hệ thống nên được kiểm tra, nhưng bản thân nó không phải là một vấn đề.

Nếu địa chỉ từ xa và cổng thay đổi chậm, điều đó cho thấy rằng các quy trình ứng dụng cần chờ CPU trong trường hợp trung bình tải cao sẽ xác nhận điều này.

Mặt khác, nếu địa chỉ và cổng từ xa không đổi và số lượng kết nối ở trạng thái CLOSE_WAIT tiếp tục tăng thì rất có thể nó chỉ ra sự cố với ứng dụng. Đây là trường hợp đặc biệt của lỗi rò rỉ tài nguyên: ứng dụng rò rỉ các ổ cắm mở thay vì đóng chúng kịp thời. Điều này tiêu tốn bộ nhớ kernel và cuối cùng sẽ làm cho ứng dụng bị lỗi một khi nó đạt đến số lượng mô tả tệp mở tối đa.

Tuy nhiên, lưu ý rằng tốc độ rò rỉ có thể chậm. Thông thường các lỗi như lỗi này là do không xử lý được một ngoại lệ ở giữa yêu cầu, làm gián đoạn luồng thực thi trong luồng công nhân mà sau đó có thể ngăn chặn việc dọn dẹp (bao gồm cả đóng ổ cắm). Ngoại lệ vi phạm có thể xảy ra hiếm khi.

Giải pháp tạm thời

Giải pháp tạm thời cho vấn đề là tăng các giới hạn đối với các bộ mô tả tệp đang mở và định kỳ khởi động lại ứng dụng khi (tốt nhất là trước đó) vấn đề bắt đầu ảnh hưởng đến hiệu suất. Lưu ý rằng điều này có thể vô tình tác động đến các kết nối hiện đang mở. Sự tồn tại của các máy chủ dự phòng và cân bằng tải có thể giúp che giấu vấn đề khỏi người dùng.

Giải pháp lâu dài

Giải pháp vĩnh viễn cho vấn đề này là triển khai phiên bản của ứng dụng mà không gặp lỗi. Mức độ mà giải pháp tạm thời gây hại cho người dùng và doanh nghiệp, mức độ sẵn sàng của bản phát hành được vá và trạng thái của bản phát hành làm việc cuối cùng giúp quyết định xem có nên quay lại phiên bản làm việc cuối cùng của ứng dụng hay chờ khắc phục.