Câu hỏi Ứng dụng bị mắc kẹt trong TCP truyền lại


Tôi đang chạy Linux kernel 3.13 (Ubuntu 14.04) trên hai Máy ảo, mỗi máy trong số đó hoạt động bên trong hai máy chủ khác nhau chạy ESXi 5.1. Có một ứng dụng máy khách-máy chủ zeromq chạy giữa hai máy ảo. Sau khi chạy trong khoảng 10-30 phút, ứng dụng này liên tục bị treo do không có khả năng truyền lại gói bị mất.

Khi tôi chạy cùng một thiết lập trên Ubuntu 12.04 (Linux 3.11), ứng dụng không bao giờ thất bại (CẬP NHẬT: Cũng không thành công trên 12.04 nhưng mất nhiều thời gian hơn)

Nếu bạn nhận thấy dưới đây, "ss"(số liệu thống kê socket) hiển thị 1 gói bị mất, sk_wmem_queued của 14110 (tức là w14110) và rto (120000) cao.

State      Recv-Q Send-Q                                      Local Address:Port                                          Peer Address:Port

ESTAB      0      **12350**                                       192.168.2.122:41808                                        192.168.2.172:55550    

timer:(on,16sec,10) uid:1000 ino:35042 

sk:ffff880035bcb100 <->
         skmem:(r0,rb648720,t0,tb1164800,f2274,**w14110**,o0,bl0) ts sack cubic wscale:7,7 rto:120000 rtt:7.5/3 ato:40 mss:8948 cwnd:1 ssthresh:21 send 9.5Mbps **unacked:1 retrans:1/10 lost:1** rcv_rtt:1476 rcv_space:37621

Vì điều này đã xảy ra một cách nhất quán nên tôi đã có thể nắm bắt được nhật ký TCP trong wireshark. Tôi thấy rằng gói bị mất không được truyền lại và thậm chí được TCP xác nhận trong hệ điều hành khác (số thứ tự được nhìn thấy trong ACK), nhưng người gửi dường như không hiểu ACK này và tiếp tục truyền lại.

MTU là 9000 trên cả hai máy ảo và phát triển tuyến đường. Các gói được gửi có kích thước lớn.

Như tôi đã nói trước đó, điều này không xảy ra trên Ubuntu 12.04 (kernel 3.11). Vì vậy, tôi đã làm một khác biệt trên các tùy chọn cấu hình TCP (nhìn thấy thông qua "sysctl -a | grep tcp") giữa 14.04 và 12.04 và tìm thấy những khác biệt sau đây.

Tôi cũng nhận thấy rằng net.ipv4.tcp_mtu_probing = 0 trong cả hai cấu hình.

Bên trái là 3,11, bên phải là 3,13

<<net.ipv4.tcp_abc = 0
<<net.ipv4.tcp_cookie_size = 0
<<net.ipv4.tcp_dma_copybreak = 4096

14c11
<< net.ipv4.tcp_early_retrans = 2
---
>> net.ipv4.tcp_early_retrans = 3

17c14
<< net.ipv4.tcp_fastopen = 0
>> net.ipv4.tcp_fastopen = 1

20d16
<< net.ipv4.tcp_frto_response = 0
26,27c22
<< net.ipv4.tcp_max_orphans = 16384
<< net.ipv4.tcp_max_ssthresh = 0

>> net.ipv4.tcp_max_orphans = 4096
29,30c24,25
<< net.ipv4.tcp_max_tw_buckets = 16384
<< net.ipv4.tcp_mem = 94377 125837  188754

>> net.ipv4.tcp_max_tw_buckets = 4096
>> net.ipv4.tcp_mem = 23352 31138   46704
34a30
>> net.ipv4.tcp_notsent_lowat = -1

Câu hỏi của tôi cho các chuyên gia mạng trên diễn đàn này: Có bất kỳ công cụ gỡ lỗi hoặc tùy chọn nào khác mà tôi có thể cài đặt / bật để tìm hiểu thêm tại sao lỗi truyền lại TCP này xảy ra một cách nhất quán không? Có bất kỳ thay đổi cấu hình nào có thể giải thích cho hành vi kỳ lạ này không.

CẬP NHẬT (đối với những người có thể gặp vấn đề tương tự sau này): Tôi cũng có thể tái tạo vấn đề trên 3,11 và sau đó có thể tránh được vấn đề này bằng cách giảm MTU.

Một vấn đề tương tự đã được báo cáo ở đây https://serverfault.com/questions/488893/how-do-i-prevent-tcp-connection-freezes-over-an-openvpn-network. Các mô tả cho phù hợp với những gì tôi thấy:

"Tuy nhiên, tại một số điểm với các máy khách Ubuntu, kết thúc từ xa sẽ bắt đầu   truyền lại cùng một phân đoạn TCP (với truyền   trì hoãn tăng dần giữa mỗi lần truyền lại). Khách hàng gửi những gì   trông giống như một TCP ACK hợp lệ cho mỗi lần truyền lại, nhưng kết thúc từ xa   vẫn tiếp tục truyền cùng một phân đoạn TCP định kỳ. "

Có thể bài viết liên quan: https://blogs.kent.ac.uk/unseenit/2013/10/18/stalled-scp-and-hanging-tcp-connections/


2
2018-06-02 11:39


gốc


Nó có thể là một lỗi. Bạn có thể thử cài đặt hạt nhân dòng chính mới nhất để xem sự cố có bị mất hay không. - bain
Không thành công trên 3.14.0-031400-chung chung! Ai đó có thể cho tôi một vài upvotes để tôi có được đặc quyền để thêm thẻ, vv? - SandeepJ
Hạt nhân đáng tin cậy mới nhất từ đường chính PPA là 3,15-rc2 - bain
Bạn có thể thử khởi động hạt nhân 12.04 của bạn (hoạt động) trong 14.04? - bain
có, sẽ đăng cập nhật sau đó - SandeepJ


Các câu trả lời:


Ông ta nhận thấy cùng một vấn đề: hạt nhân Linux 3.2 trên Ubuntu 12.04 đã làm việc mà không gặp bất kỳ vấn đề gì, Linux 3.13 trên Unbuntu 14.02 cũng có cùng một vấn đề.

Tôi không chắc chắn nếu điều này thực sự là một lỗi trong hạt nhân, với tôi nó trông giống như một vấn đề với ACK chọn lọc (SACK). Bạn có thể giải quyết vấn đề bằng cách vô hiệu hóa TCP SACK với:

sysctl net.ipv4.tcp_sack = 0

Điều này làm việc xung quanh vấn đề. Trong trường hợp của chúng tôi, điều đó xảy ra là các khách hàng có kết nối bị mất hoặc xa (ví dụ: các trung tâm dữ liệu khác, các đường DSL) không còn có thể tải xuống các tệp lớn nữa. Sau khoảng một vài megabyte tải xuống kết nối HTTP bị trì hoãn. TCDump cho thấy rất nhiều ACKS chọn lọc (SACK) được truyền đi.

Và có, khởi động hạt nhân 12.04 trong 14.04 đã giúp, quá.

Tôi nghĩ chúng ta nên mở một vấn đề trong Ubuntu. Tôi đã không chắc chắn nếu vấn đề chỉ xảy ra vì phần cứng mạng / bộ định tuyến của chúng tôi, nhưng có vẻ như một vấn đề thường gặp là TCP SACK là sai.


2
2017-12-21 12:22



Uwe, đây có phải là một cái máy ảo không? Tôi đã gặp vấn đề với vmware và nó đã được quan sát bởi những người khác. Xem ở đây để theo dõi community.vmware.com/message/2390611#2390611 - SandeepJ