Làm cách nào để giảm số lượng ổ cắm trong TIME_WAIT?


36

Máy chủ Ubuntu 10.04.1 x86

Tôi đã có một máy có dịch vụ HTTP FCGI phía sau nginx, phục vụ rất nhiều yêu cầu HTTP nhỏ cho nhiều khách hàng khác nhau. (Khoảng 230 yêu cầu mỗi giây trong giờ cao điểm, kích thước phản hồi trung bình với các tiêu đề là 650 byte, hàng triệu khách hàng khác nhau mỗi ngày.)

Kết quả là, tôi có rất nhiều ổ cắm, treo trong TIME_WAIT (biểu đồ được chụp với cài đặt TCP bên dưới):

THỜI GIAN CHỜ ĐỢI

Tôi muốn giảm số lượng ổ cắm.

Tôi có thể làm gì ngoài điều này?

$ cat / Proc / sys / net / ipv4 / tcp_fin_timeout
1
$ cat / Proc / sys / net / ipv4 / tcp_tw_recycle
1
$ cat / Proc / sys / net / ipv4 / tcp_tw numuse
1

Cập nhật: một số chi tiết về cách bố trí dịch vụ thực tế trên máy:

máy khách ----- TCP-socket -> nginx (proxy cân bằng tải) 
       ----- Ổ cắm TCP -> nginx (công nhân) 
       --domain-socket -> fcgi-phần mềm
                          --single-continent-TCP-socket -> Redis
                          --single-continent-TCP-socket -> MySQL (máy khác)

Có lẽ tôi cũng nên chuyển đổi bộ cân bằng tải -> kết nối worker sang socket miền, nhưng vấn đề về socket TIME_WAIT sẽ vẫn còn - Tôi dự định sớm thêm một worker thứ hai trên một máy riêng biệt. Sẽ không thể sử dụng ổ cắm tên miền trong trường hợp đó.


Có vẻ như Munin đang xấu hổ nói dối. Xem bình luận cho câu trả lời của Kyle. Nhìn vào đó bây giờ.
Alexander Gladysh

1
Tạo một câu hỏi về Munin: serverfault.com/questions/212200/ từ
Alexander Gladysh

Bây giờ có vẻ như Munin không nói dối, nhưng đúng hơn là tôi đang nhìn nhầm cốt truyện ...
Alexander Gladysh

Câu trả lời:


28

Một điều bạn nên làm để bắt đầu là sửa chữa net.ipv4.tcp_fin_timeout=1. Đó là cách thấp, có lẽ bạn không nên lấy mức đó thấp hơn 30.

Vì đây là đằng sau nginx. Điều đó có nghĩa là nginx đang hoạt động như một proxy ngược? Nếu đó là trường hợp thì các kết nối của bạn là 2 lần (một đến máy khách, một đến máy chủ web của bạn). Bạn có biết những ổ cắm này thuộc về cái nào không?

Cập nhật:
fin_timeout là thời gian họ ở trong FIN-WAIT-2 (Từ networking/ip-sysctl.txttrong tài liệu kernel):

tcp_fin_timeout - INTEGER
        Time to hold socket in state FIN-WAIT-2, if it was closed
        by our side. Peer can be broken and never close its side,
        or even died unexpectedly. Default value is 60sec.
        Usual value used in 2.2 was 180 seconds, you may restore
        it, but remember that if your machine is even underloaded WEB server,
        you risk to overflow memory with kilotons of dead sockets,
        FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
        because they eat maximum 1.5K of memory, but they tend
        to live longer. Cf. tcp_max_orphans.

Tôi nghĩ rằng bạn có thể chỉ cần để Linux giữ số ổ cắm TIME_WAIT so với số tiền trông giống như nắp 32k trên chúng và đây là nơi Linux tái chế chúng. 32k này được ám chỉ trong liên kết này :

Ngoài ra, tôi thấy / Proc / sys / net / ipv4 / tcp_max_tw_buckets gây nhầm lẫn. Mặc dù mặc định được đặt ở 180000, tôi thấy sự gián đoạn TCP khi tôi có ổ cắm 32K TIME_WAIT trên hệ thống của mình, bất kể tối đa hai nhóm.

Liên kết này cũng gợi ý rằng trạng thái TIME_WAIT là 60 giây và không thể điều chỉnh thông qua Proc.

Sự thật thú vị ngẫu nhiên:
Bạn có thể thấy các bộ hẹn giờ trên timewait với netstat cho mỗi ổ cắm vớinetstat -on | grep TIME_WAIT | less

Tái sử dụng Vs Tái chế:
Đây là một loại thú vị, nó đọc như tái sử dụng cho phép tái sử dụng ổ cắm time_Wait và tái chế đặt nó vào chế độ TURBO:

tcp_tw_recycle - BOOLEAN
        Enable fast recycling TIME-WAIT sockets. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

tcp_tw_reuse - BOOLEAN
        Allow to reuse TIME-WAIT sockets for new connections when it is
        safe from protocol viewpoint. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

Tôi không khuyên bạn nên sử dụng net.ipv4.tcp_tw_recycle vì nó gây ra sự cố với các máy khách NAT .

Có lẽ bạn có thể thử không bật cả hai thứ đó lên và xem nó có tác dụng gì (Hãy thử từng cái một và xem chúng hoạt động như thế nào)? Tôi sẽ sử dụng netstat -n | grep TIME_WAIT | wc -lđể phản hồi nhanh hơn Munin.


1
@Kyle: net.ipv4.tcp_fin_timeoutbạn muốn giới thiệu giá trị nào?
Alexander Gladysh

1
@ Kyle: client --TCP-socket -> nginx (load balancer reverse proxy) --TCP-socket -> nginx (công nhân) --domain-socket -> fcgi-phần mềm
Alexander Gladysh

2
Tôi sẽ nói 30hoặc có thể 20. Hãy thử nó và xem. Bạn có rất nhiều tải nên rất nhiều loại TIME_WAIT có ý nghĩa.
Kyle Brandt

1
@ Kyle: xin lỗi vì một câu hỏi ngu ngốc (Tôi đang trên một mức độ hàng hóa-giáo phái ở đây cho đến nay, không may), nhưng những gì chính xác tôi nên mong đợi để xem khi tôi thay đổi net.ipv4.tcp_fin_timeouttừ 1tới 20?
Alexander Gladysh

4
Oh, đây là một lót tốt đẹp : netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c. Vì vậy, @Alex, nếu Munin không thích, có thể đi sâu vào cách nó theo dõi các chỉ số này. Có lẽ vấn đề duy nhất là Munin đang cung cấp cho bạn dữ liệu xấu :-)
Kyle Brandt

1

tcp_tw numuse tương đối an toàn vì nó cho phép các kết nối TIME_WAIT được sử dụng lại.

Ngoài ra, bạn có thể chạy nhiều dịch vụ hơn khi nghe trên các cổng khác nhau phía sau bộ cân bằng tải của mình nếu hết cổng là vấn đề.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.