Hàng tấn kết nối TCP ở trạng thái TIME_WAIT trên windows 2008 - chạy trên amazon AWS

HĐH: Windows Server 2008, SP2 (chạy trên EC2 Amazon).

Chạy ứng dụng web bằng máy chủ Apache httpd & tomcat 6.02 và máy chủ Web có các cài đặt duy trì.

Có khoảng 69.250 (cổng http 80) + 15000 (trừ cổng 80) kết nối TCP ở trạng thái TIME_WAIT (đã sử dụng netstat & tcpview). Các kết nối này dường như không đóng ngay cả sau khi dừng máy chủ web (đợi 24 giờ)

Quầy giám sát hiệu suất:

• Kết nối hoạt động TCPv4: 145K
• Kết nối thụ động TCPv4: 475K
• Kết nối thất bại TCPv4: 16K
• Thiết lập lại kết nối TCPv4: 23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters không có khóa TcpTimedWaitDelay, vì vậy giá trị phải là mặc định (2 * MSL, 4 phút)

Ngay cả khi có hàng ngàn yêu cầu kết nối đến cùng một lúc, tại sao Windows OS cuối cùng không thể làm sạch chúng?
Điều gì có thể là lý do đằng sau tình huống này?
Có cách nào để đóng mạnh tất cả các kết nối TIME_WAIT này mà không cần khởi động lại hệ điều hành windows không?

Sau vài ngày, ứng dụng của chúng tôi ngừng nhận bất kỳ kết nối mới.

Chúng tôi cũng đã xử lý vấn đề này. Có vẻ như Amazon đã tìm ra nguyên nhân gốc rễ và khắc phục nó. Đây là thông tin họ đã cho tôi.

Xin chào, tôi đang dán bên dưới một lời giải thích về những gì đã gây ra vấn đề này. Tin tốt là điều này đã được sửa chữa rất gần đây bởi đội ngũ kỹ thuật của chúng tôi. Để khắc phục, tất cả những gì bạn phải làm là DỪNG / BẮT ĐẦU các phiên bản Windows Server 2008 mà bạn đang gặp vấn đề này. Một lần nữa, tôi không nói về REBOOT khác. STOP / START làm cho cá thể di chuyển đến một máy chủ (khỏe mạnh) khác. Khi các phiên bản này khởi chạy lại, chúng sẽ chạy trên các máy chủ có khắc phục sự cố để chúng không gặp sự cố này nữa. Bây giờ dưới đây là lời giải thích kỹ thuật về vấn đề này. Sau khi điều tra chuyên sâu, chúng tôi thấy rằng khi chạy Windows 2008 x64 trên hầu hết các loại phiên bản có sẵn, chúng tôi ' đã xác định được một vấn đề có thể dẫn đến các kết nối TCP tồn tại trong TIME_WAIT / CLOSE_WAIT trong thời gian quá dài (trong một số trường hợp, vẫn ở trạng thái này vô thời hạn). Mặc dù ở các trạng thái này, các cặp ổ cắm cụ thể vẫn không sử dụng được và nếu tích lũy đủ, sẽ dẫn đến cạn kiệt cổng cho các cổng được đề cập. Nếu trường hợp cụ thể này xảy ra, giải pháp duy nhất để xóa các cặp ổ cắm được đề cập là khởi động lại thể hiện trong câu hỏi. Chúng tôi đã xác định nguyên nhân là các giá trị được tạo bởi chức năng hẹn giờ trong API kernel của Windows 2008, trên nhiều nền tảng 64 bit của chúng tôi, đôi khi sẽ lấy một giá trị cực kỳ xa trong tương lai. Điều này ảnh hưởng đến ngăn xếp TCP bằng cách làm cho dấu thời gian trên các cặp ổ cắm TCP được đóng dấu đáng kể trong tương lai. Theo Microsoft, có một bộ đếm tích lũy được lưu trữ sẽ không được cập nhật trừ khi giá trị được tạo bởi lệnh gọi API này lớn hơn giá trị tích lũy. Kết quả cuối cùng là các ổ cắm được tạo ra sau thời điểm này tất cả sẽ được đóng dấu quá xa trong tương lai cho đến khi đạt được thời gian trong tương lai. Trong một số trường hợp, chúng tôi đã thấy giá trị này trong vài trăm ngày trong tương lai, do đó các cặp ổ cắm dường như bị kẹt mãi mãi.

Câu trả lời của Ryan là lời khuyên chung tốt ngoại trừ việc nó không áp dụng cho điều kiện Ravi đang gặp phải trong EC2. Chúng tôi cũng đã thấy vấn đề này và vì bất kỳ lý do gì, Windows hoàn toàn bỏ qua TcpTimedWaitDelay và không bao giờ giải phóng ổ cắm từ trạng thái TIMED_WAIT của nó.

Chờ đợi không giúp ích gì ... khởi động lại ứng dụng không giúp ích gì ... biện pháp khắc phục duy nhất chúng tôi tìm thấy là khởi động lại hệ điều hành. Rất xấu.

Tôi hoàn toàn ngẫu nhiên tìm thấy chủ đề này trong khi tìm cách gỡ lỗi một vấn đề riêng biệt, nhưng đây là một vấn đề ít được đưa ra, nhưng nổi tiếng với Windows trên EC2. Chúng tôi đã từng có hỗ trợ cao cấp và thảo luận vấn đề này với họ trong một môi trường không công khai thông qua kênh đó, nhưng đây là vấn đề liên quan mà chúng tôi đã thảo luận trên các diễn đàn công cộng .

Như những người khác đã đề cập, bạn cần phải điều chỉnh Windows Servers ra khỏi hộp. Tuy nhiên, giống như cách StopWatch không hoạt động trong luồng trên, ngăn xếp TCP / IP cũng sử dụng lệnh QueryPerformanceCountergọi để xác định chính xác thời gian TCP_TIME_WAIT sẽ kéo dài. Vấn đề là trên EC2, họ đã gặp phải và biết về một vấn đề QueryPerformanceCounterxảy ra haywire và có thể quay trở lại thời gian rất xa trong tương lai; không phải là trạng thái TIME_WAIT của bạn đang bị bỏ qua, đó là thời gian hết hạn của TIME_WAIT có khả năng trong tương lai nhiều năm. Khi chạy trong cài đặt httpd, bạn có thể thấy cách bạn nhanh chóng tích lũy các ổ cắm zombie này khi trạng thái gặp phải (chúng ta thường thấy rằng đây là một sự kiện riêng biệt, không phải là bạn từ từ tích lũy zombie).

Những gì chúng tôi làm là chạy một dịch vụ trong nền truy vấn số lượng ổ cắm ở trạng thái TIME_WAIT và một khi điều này vượt qua một ngưỡng nhất định, chúng tôi sẽ hành động (khởi động lại máy chủ). Bằng cách nào đó trong 45 giây qua , ai đó đã chỉ ra rằng bạn có thể dừng / khởi động máy chủ để khắc phục sự cố - Tôi khuyên bạn nên kết hợp hai cách tiếp cận này.

Cài đặt mặc định cho ngăn xếp TCP trong Windows là, ít nhất, không tối ưu cho các hệ thống sẽ lưu trữ máy chủ HTTP.

Để tận dụng tốt nhất máy Windows của bạn khi được sử dụng làm máy chủ HTTP, có một vài tham số mà bạn thường điều chỉnh như MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDocateBacklog, KeepAliveInterval, v.v.

Tôi đã viết một ghi chú cho bản thân về điều này một vài năm trước, chỉ trong trường hợp tôi cần một số mặc định nhanh chóng để bắt đầu. Hãy hiểu các thông số và sau đó tinh chỉnh chúng.

Không liên quan đến AWS, chúng tôi mới gặp phải vấn đề này, có vẻ như là kết quả của bài viết KB này:

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

Về cơ bản, nó hoạt động nếu hệ thống hoạt động được> 497 ngày và hotfix không được áp dụng. Tất nhiên, việc khởi động lại đã xóa nó đi - chúng tôi có thể không biết trong 16 tháng tới nếu hotfix hoạt động, nhưng điều này có thể giúp bất cứ ai có máy chủ hoạt động lâu năm ngoài kia.

Tôi đã trải nghiệm điều tương tự chính xác trên một số hộp với Windows Server 2008 R2 x64 với SP1, chủ yếu là với CLOSE_WAIT (hơi khác so với TIME_WAIT). Tôi đã vấp phải câu trả lời này trong đó tham chiếu KB tại Microsoft và hotfix nếu các máy chủ đang chạy phía sau bộ cân bằng tải (là của tôi). Sau khi cài đặt hotfix và khởi động lại, tất cả nội dung CLOSE_WAIT đã được giải quyết.