Có nguy hiểm khi thay đổi giá trị của / Proc / sys / net / ipv4 / tcp_tw_Vuse không?

Chúng tôi có một vài hệ thống sản xuất gần đây đã được chuyển đổi thành máy ảo. Có một ứng dụng của chúng tôi thường xuyên truy cập cơ sở dữ liệu MySQL và với mỗi truy vấn, nó tạo ra một kết nối, truy vấn và ngắt kết nối đó.

Nó không phải là cách thích hợp để truy vấn (tôi biết), nhưng chúng ta có những ràng buộc mà chúng ta dường như không thể giải quyết được. Dù sao, vấn đề là ở đây: trong khi máy là máy chủ vật lý, chương trình vẫn chạy tốt. Sau khi chuyển đổi thành máy ảo, chúng tôi nhận thấy các sự cố kết nối không liên tục đến cơ sở dữ liệu. Tại một thời điểm, có hơn 24000 kết nối ổ cắm trong TIME_WAIT (trên máy chủ vật lý, thứ tôi thấy nhiều nhất là 17000 - không tốt, nhưng không gây ra sự cố).

Tôi muốn các kết nối này được sử dụng lại, để chúng ta không thấy vấn đề kết nối đó, và vì vậy:

Câu hỏi:

Bạn có thể đặt giá trị của tcp_tw numuse thành 1 không? Những mối nguy hiểm rõ ràng là gì? Có bất kỳ lý do tôi không bao giờ nên làm điều đó?

Ngoài ra, có cách nào khác để hệ thống (RHEL / CentOS) ngăn chặn rất nhiều kết nối đi vào TIME_WAIT hoặc khiến chúng được sử dụng lại không?

Cuối cùng, việc thay đổi tcp_tw_recycle sẽ làm gì và điều đó có giúp tôi không?

Trước, cảm ơn!

Bạn có thể giảm thời gian xuống một cách an toàn, nhưng bạn có thể gặp phải sự cố với các kết nối bị đóng không hoàn hảo trên các mạng bị mất gói hoặc jitter. Tôi sẽ không bắt đầu điều chỉnh trong 1 giây, bắt đầu lúc 15-30 và làm theo cách của bạn.

Ngoài ra, bạn thực sự cần phải sửa ứng dụng của bạn.

RFC 1185 có một lời giải thích tốt trong phần 3.2:

Khi kết nối TCP bị đóng, độ trễ 2 * MSL ở trạng thái TIME-WAIT sẽ kết nối cặp ổ cắm trong 4 phút (xem Phần 3.5 của [Postel81]. Các ứng dụng được xây dựng trên TCP đóng một kết nối và mở một kết nối mới (ví dụ: , kết nối truyền dữ liệu FTP bằng chế độ Luồng) phải chọn một cặp ổ cắm mới mỗi lần. Sự chậm trễ này phục vụ hai mục đích khác nhau:

 (a)  Implement the full-duplex reliable close handshake of TCP. 

      The proper time to delay the final close step is not really 
      related to the MSL; it depends instead upon the RTO for the 
      FIN segments and therefore upon the RTT of the path.* 
      Although there is no formal upper-bound on RTT, common 
      network engineering practice makes an RTT greater than 1 
      minute very unlikely.  Thus, the 4 minute delay in TIME-WAIT 
      state works satisfactorily to provide a reliable full-duplex 
      TCP close.  Note again that this is independent of MSL 
      enforcement and network speed. 

      The TIME-WAIT state could cause an indirect performance 
      problem if an application needed to repeatedly close one 
      connection and open another at a very high frequency, since 
      the number of available TCP ports on a host is less than 
      2**16.  However, high network speeds are not the major 
      contributor to this problem; the RTT is the limiting factor 
      in how quickly connections can be opened and closed. 
      Therefore, this problem will no worse at high transfer 
      speeds. 

 (b)  Allow old duplicate segements to expire. 

      Suppose that a host keeps a cache of the last timestamp 
      received from each remote host.  This can be used to reject 
      old duplicate segments from earlier incarnations of the 

---

* Lưu ý: Có thể lập luận rằng bên gửi FIN có mức độ tin cậy cần thiết, và do đó, có thể xác định độ dài của độ trễ TIME-WAIT cho người nhận FIN. Điều này có thể được thực hiện với một tùy chọn TCP thích hợp trong các phân đoạn FIN.

      connection, if the timestamp clock can be guaranteed to have 
      ticked at least once since the old conennection was open. 
      This requires that the TIME-WAIT delay plus the RTT together 
      must be at least one tick of the sender's timestamp clock. 

      Note that this is a variant on the mechanism proposed by 
      Garlick, Rom, and Postel (see the appendix), which required 
      each host to maintain connection records containing the 
      highest sequence numbers on every connection.  Using 
      timestamps instead, it is only necessary to keep one quantity 
      per remote host, regardless of the number of simultaneous 
      connections to that host.

Điều này không trả lời câu hỏi của bạn (và trễ 18 tháng), nhưng gợi ý một cách khác để làm cho các cổng sử dụng lại ứng dụng cũ của bạn:

Một thay thế hữu ích cho cài đặt tcp_tw_reuse(hoặc tcp_tw_recycle) trên hệ thống là chèn thư viện dùng chung (sử dụng LD_PRELOAD) vào ứng dụng của bạn; thư viện đó sau đó có thể cho phép tái sử dụng cổng. Điều này làm cho ứng dụng cũ của bạn cho phép tái sử dụng cổng mà không buộc điều này trên tất cả các ứng dụng trên hệ thống của bạn (không yêu cầu sửa đổi ứng dụng của bạn), do đó hạn chế tác động của tinh chỉnh. Ví dụ,

    LD_PRELOAD=/opt/local/lib/libreuse.so ./legacy_app

Thư viện chia sẻ này sẽ chặn socket()cuộc gọi, gọi ổ cắm thực () và đặt SO_REUSEADDR và ​​/ hoặc SO_REUSEPORT trên ổ cắm được trả về. Hãy xem http://libkeepalive.sourceforge.net để biết ví dụ về cách thực hiện việc này (điều này bật thủ tục, nhưng bật SO_REUSEPORT rất giống nhau). Nếu ứng dụng cũ bị lỗi của bạn sử dụng IPv6, hãy nhớ thay đổi dòng 55 libkeepalive.ctừ

    if((domain == PF_INET) && (type == SOCK_STREAM)) {

đến

    if(((domain == PF_INET) || (domain == PF_INET6)) && (type == SOCK_STREAM)) {

Nếu bạn bị kẹt, hãy gửi email cho tôi và tôi sẽ viết mã và gửi cho bạn.

Tôi nghĩ sẽ ổn khi thay đổi giá trị này thành 1. Cách thích hợp hơn có thể là sử dụng lệnh:

[root@server]# sysctl -w net.ipv4.tcp_tw_reuse=1

Không có mối nguy hiểm rõ ràng nào mà tôi biết, nhưng một tìm kiếm nhanh của Google tạo ra liên kết này khẳng định đó tcp_tw_reuselà sự thay thế tốt hơn tcp_tw_recycle, nhưng nên thận trọng khi sử dụng.

Không thể sử dụng lại kết nối nếu chúng ở trạng thái THỜI GIAN. Nếu bạn không bị mất gói trên mạng giữa ứng dụng và MySQL, bạn có thể giảm thời gian chờ.

Tuy nhiên, giải pháp tốt nhất là sử dụng các kết nối liên tục đối với cơ sở dữ liệu và nhóm kết nối.