Chuyển chậm trên khoảng cách

Từ NY Datacenter của chúng tôi, chuyển đến các địa điểm xa hơn đang có hiệu suất kém.

Sử dụng kiểm tra tốc độ để kiểm tra các địa điểm khác nhau, chúng tôi có thể bão hòa đường lên 100 mbit của chúng tôi đến Boston và Philadelphia một cách dễ dàng. Khi tôi sử dụng kiểm tra tốc độ để xác định vị trí trên bờ biển phía tây của Hoa Kỳ hoặc Châu Âu, tôi thường chỉ thấy khoảng 9 mbit / s.

Phản ứng đầu tiên của tôi là đây là một vấn đề mở rộng cửa sổ (Sản phẩm trễ băng thông). Tuy nhiên, tôi đã điều chỉnh với các tham số nhân Linux trên máy thử nghiệm ở bờ tây và sử dụng iperf đến điểm mà Window có kích thước đủ để hỗ trợ 100 MegaBytes một giây và vẫn có tốc độ chậm (Đã xác minh trong Capture). Tôi cũng đã thử vô hiệu hóa thuật toán Nagle.

Chúng tôi nhận được hiệu suất kém từ cả Linux và Windows, nhưng tốc độ sử dụng Windows kém hơn đáng kể (1/3).

Hình dạng của chuyển nhượng (không có Nagle) là:

Dip khoảng 10 giây có ~ 100 acks trùng lặp.

Hình dạng kích thước cửa sổ tối thiểu của máy thu theo thời gian là:

Bất kỳ ý tưởng về nơi để đi bên cạnh để ghim cổ chai của chúng tôi?

Một số kết quả kiểm tra tốc độ (Tải lên bằng speedtest.net):

• Philadelphia: 44 mbit (Những người sử dụng trang web của chúng tôi đang sử dụng phần còn lại ;-))
• Miami: 15 dặm
• Dallas: 14 dặm
• San Jose: 9 dặm
• Berlin: 5 dặm
• Sydney: 2,9 dặm

Nhiều dữ liệu hơn:
Miami: 69.241.6.18

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.579 ms  0.588 ms  0.594 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.562 ms  0.569 ms  0.565 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.634 ms  0.640 ms  0.637 ms
 5  vlan79.csw2.newyork1.level3.net (4.68.16.126)  4.120 ms  4.126 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.673 ms
 6  ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  1.236 ms ae-91-91.ebr1.newyork1.level3.net (4.69.134.77)  0.956 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  0.600 ms
 7  ae-10-10.ebr2.washington12.level3.net (4.69.148.50)  6.059 ms  6.029 ms  6.661 ms
 8  ae-1-100.ebr1.washington12.level3.net (4.69.143.213)  6.084 ms  6.056 ms  6.065 ms
 9  ae-6-6.ebr1.atlanta2.level3.net (4.69.148.105)  17.810 ms  17.818 ms  17.972 ms
10  ae-1-100.ebr2.atlanta2.level3.net (4.69.132.34)  18.014 ms  18.022 ms  18.661 ms
11  ae-2-2.ebr2.miami1.level3.net (4.69.140.141)  40.351 ms  40.346 ms  40.321 ms
12  ae-2-52.edge2.miami1.level3.net (4.69.138.102)  31.922 ms  31.632 ms  31.628 ms
13  comcast-ip.edge2.miami1.level3.net (63.209.150.98)  32.305 ms  32.293 ms comcast-ip.edge2.miami1.level3.net (64.156.8.10)  32.580 ms
14  pos-0-13-0-0-ar03.northdade.fl.pompano.comcast.net (68.86.90.230)  32.172 ms  32.279 ms  32.276 ms
15  te-8-4-ur01.northdade.fl.pompano.comcast.net (68.85.127.130)  32.244 ms  32.539 ms  32.148 ms
16  te-8-1-ur02.northdade.fl.pompano.comcast.net (68.86.165.42)  32.478 ms  32.456 ms  32.459 ms
17  te-9-3-ur05.northdade.fl.pompano.comcast.net (68.86.165.46)  32.409 ms  32.390 ms  32.544 ms
18  te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198)  33.938 ms  33.775 ms  34.430 ms
19  te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198)  32.896 ms !X * *

69.241.6.0/23 *[BGP/170] 1d 00:55:07, MED 3241, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 20214 I
> to 216.187.115.166 via xe-0/0/0.0

San Jose: 208,79,45,81

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.477 ms  0.549 ms  0.547 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.543 ms  0.586 ms  0.636 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.518 ms  0.569 ms  0.566 ms
 5  vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.620 ms vlan99.csw4.newyork1.level3.net (4.68.16.254)  9.275 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.759 ms
 6  ae-62-62.ebr2.newyork1.level3.net (4.69.148.33)  1.848 ms  1.189 ms ae-82-82.ebr2.newyork1.level3.net (4.69.148.41)  1.011 ms
 7  ae-2-2.ebr4.sanjose1.level3.net (4.69.135.185)  69.942 ms  68.918 ms  69.451 ms
 8  ae-81-81.csw3.sanjose1.level3.net (4.69.153.10)  69.281 ms ae-91-91.csw4.sanjose1.level3.net (4.69.153.14)  69.147 ms ae-81-81.csw3.sanjose1.level3.net (4.69.153.10)  69.495 ms
 9  ae-23-70.car3.sanjose1.level3.net (4.69.152.69)  69.863 ms ae-13-60.car3.sanjose1.level3.net (4.69.152.5)  69.860 ms ae-43-90.car3.sanjose1.level3.net (4.69.152.197)  69.661 ms
10  smugmug-inc.car3.sanjose1.level3.net (4.71.112.10)  73.298 ms  73.290 ms  73.274 ms
11  speedtest.smugmug.net (208.79.45.81)  70.055 ms  70.038 ms  70.205 ms

208.79.44.0/22 *[BGP/170] 4w0d 08:03:46, MED 0, localpref 59, from 216.187.115.12
AS path: 3356 11266 I
> to 216.187.115.166 via xe-0/0/0.0

Philly: 68,87,64,49

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.578 ms  0.576 ms  0.570 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.615 ms  0.613 ms  0.602 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.584 ms  0.580 ms  0.574 ms
 5  vlan79.csw2.newyork1.level3.net (4.68.16.126)  0.817 ms vlan69.csw1.newyork1.level3.net (4.68.16.62)  9.518 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  9.712 ms
 6  ae-91-91.ebr1.newyork1.level3.net (4.69.134.77)  0.939 ms ae-61-61.ebr1.newyork1.level3.net (4.69.134.65)  1.064 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  1.075 ms
 7  ae-6-6.ebr2.newyork2.level3.net (4.69.141.22)  0.941 ms  1.298 ms  0.907 ms
 8  * * *
 9  comcast-ip.edge1.newyork2.level3.net (4.71.186.14)  3.187 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.34)  2.036 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.2)  2.682 ms
10  te-4-3-ar01.philadelphia.pa.bo.comcast.net (68.86.91.162)  3.507 ms  3.716 ms  3.716 ms
11  te-9-4-ar01.ndceast.pa.bo.comcast.net (68.86.228.2)  7.700 ms  7.884 ms  7.727 ms
12  te-4-1-ur03.ndceast.pa.bo.comcast.net (68.86.134.29)  8.378 ms  8.185 ms  9.040 ms

68.80.0.0/13 *[BGP/170] 4w0d 08:48:29, MED 200, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 I
> to 216.187.115.166 via xe-0/0/0.0

Berlin: 194,29.226,25

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.483 ms  0.480 ms  0.537 ms
 3  oc48-po2-0.nyc-telx-dis-2.peer1.net (216.187.115.133)  0.532 ms  0.535 ms  0.530 ms
 4  oc48-so2-0-0.ldn-teleh-dis-1.peer1.net (216.187.115.226)  68.550 ms  68.614 ms  68.610 ms
 5  linx1.lon-2.uk.lambdanet.net (195.66.224.99)  81.481 ms  81.463 ms  81.737 ms
 6  dus-1-pos700.de.lambdanet.net (82.197.136.17)  80.767 ms  81.179 ms  80.671 ms
 7  han-1-eth020.de.lambdanet.net (217.71.96.77)  97.164 ms  97.288 ms  97.270 ms
 8  ber-1-eth020.de.lambdanet.net (217.71.96.153)  89.488 ms  89.462 ms  89.477 ms
 9  ipb-ber.de.lambdanet.net (217.71.97.82)  104.328 ms  104.178 ms  104.176 ms
10  vl506.cs22.b1.ipberlin.com (91.102.8.4)  90.556 ms  90.564 ms  90.553 ms
11  cic.ipb.de (194.29.226.25)  90.098 ms  90.233 ms  90.106 ms

194.29.224.0/19 *[BGP/170] 3d 23:14:47, MED 0, localpref 69, from 216.187.115.15
AS path: 13237 20647 I
> to 216.187.115.182 via xe-0/1/0.999

Cập nhật:

Đi sâu vào vấn đề này sâu hơn một chút với Tall Jeff, chúng tôi đã tìm thấy một điều kỳ lạ. Theo TCPDump về phía người gửi, nó gửi các gói dưới dạng 65k gói qua Internet . Khi chúng ta nhìn vào các bãi rác ở phía bên nhận, chúng sẽ bị phân mảnh 1448 như bạn mong đợi.

Đây là kết xuất của gói dữ liệu ở phía Người gửi:

Điều xảy ra sau đó là người gửi nghĩ rằng họ chỉ gửi các gói 64k, nhưng trong thực tế, theo như người nhận có liên quan thì họ đang gửi các gói dữ liệu. Kết quả cuối cùng là điều khiển tắc nghẽn. Bạn có thể thấy đây là một biểu đồ về độ dài gói của các gói dữ liệu được gửi bởi người gửi:

Bất cứ ai cũng biết những gì có thể khiến người gửi nghĩ rằng có một MTU 64k? Có lẽ một số /proc, ethtoolhoặc ifconfig parameter? ( ifconfighiển thị MTU là 1500). Dự đoán tốt nhất của tôi ngay bây giờ là một số loại tăng tốc phần cứng - nhưng tôi không chắc chắn cụ thể là gì.

Subedit 2-2 IV:
Chỉ cần có một suy nghĩ, vì các gói 64k này có bộ bit DF, có lẽ nhà cung cấp của tôi đang phân đoạn chúng bằng mọi cách và làm rối tung khám phá tự động MSS! Hoặc có lẽ tường lửa của chúng tôi bị cấu hình sai ...

Điều chỉnh Chỉnh sửa 9.73.4 20-60:
Lý do tôi thấy các gói 64k là vì giảm tải phân đoạn (tso và gso, xem ethtool -K) đang bật. Sau khi tắt chúng đi, tôi không thấy sự cải thiện nào về tốc độ chuyển tiền. Hình dạng thay đổi một chút và truyền lại trong các phân đoạn nhỏ hơn:

Tôi cũng đã thử tất cả các thuật toán tắc nghẽn khác nhau trên Linux mà không cải thiện. Nhà cung cấp NY của tôi đã thử tải các tệp lên máy chủ ftp thử nghiệm trong OR từ cơ sở chúng tôi đang ở và đang nhận được tốc độ gấp 3 lần.

Báo cáo MTR được yêu cầu từ NY đến OR:

root@ny-rt01:~# mtr haproxy2.stackoverflow.com -i.05 -s 1400 -c 500 -r
HOST: ny-rt01.ny.stackoverflow.co Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. stackoverflow-nyc-gw.peer1.n  0.0%   500    0.6   0.6   0.5  18.1   0.9
  2. gig4-0.nyc-gsr-d.peer1.net    0.0%   500    0.6   0.6   0.5  14.8   0.8
  3. 10ge.xe-0-0-0.nyc-telx-dis-1  0.0%   500    0.7   3.5   0.5  99.7  11.3
  4. nyiix.he.net                  0.0%   500    8.5   3.5   0.7  20.8   3.9
  5. 10gigabitethernet1-1.core1.n  0.0%   500    2.3   3.5   0.8  23.5   3.8
  6. 10gigabitethernet8-3.core1.c  0.0%   500   20.1  22.4  20.1  37.5   3.6
  7. 10gigabitethernet3-2.core1.d  0.2%   500   72.2  72.5  72.1  84.4   1.5
  8. 10gigabitethernet3-4.core1.s  0.2%   500   72.2  72.6  72.1  92.3   1.9
  9. 10gigabitethernet1-2.core1.p  0.4%   500   76.2  78.5  76.0 100.2   3.6
 10. peak-internet-llc.gigabiteth  0.4%   500   76.3  77.1  76.1 118.0   3.6
 11. ge-0-0-2-cvo-br1.peak.org     0.4%   500   79.5  80.4  79.0 122.9   3.6
 12. ge-1-0-0-cvo-core2.peak.org   0.4%   500   83.2  82.7  79.8 104.1   3.2
 13. vlan5-cvo-colo2.peak.org      0.4%   500   82.3  81.7  79.8 106.2   2.9
 14. peak-colo-196-222.peak.org    0.4%   499   80.1  81.0  79.7 117.6   3.3

Đảm bảo cửa sổ TCP đang mở đủ rộng để che Sản phẩm Trì hoãn Băng thông cũng sẽ là dự đoán đầu tiên của tôi. Giả sử được cấu hình đúng (và được hỗ trợ bởi cả hai đầu) tôi sẽ kiểm tra lần theo dấu vết gói để đảm bảo rằng cửa sổ thực sự đang mở và một trong những bước nhảy trong đường dẫn không bị tước tỷ lệ cửa sổ. Nếu điều đó là tốt, và bạn chắc chắn rằng bạn không va vào một bước nhảy bị hạn chế băng thông trong đường dẫn, nguyên nhân có thể gây ra vấn đề của bạn là các gói tin ngẫu nhiên. Giả thuyết này được hỗ trợ bởi dấu hiệu của các ACK trùng lặp mà bạn đã đề cập. (ACK trùng lặp thường là kết quả trực tiếp của dữ liệu bị mất). Cũng lưu ý rằng với một sản phẩm trễ băng thông lớn và do đó, một cửa sổ trượt mở lớn,

Lưu ý bên lề: Đối với việc truyền dữ liệu hàng loạt qua TCP và qua kết nối WAN nhiều bước, không cần hoặc không có lý do để vô hiệu hóa Nagle. Trong thực tế, kịch bản chính xác đó là lý do tại sao Nagle tồn tại. Nói chung, Nagle chỉ cần bị vô hiệu hóa cho các kết nối tương tác trong đó các datagram có kích thước MTU phụ cần phải được loại bỏ mà không có bất kỳ độ trễ nào. tức là: Để chuyển số lượng lớn, bạn muốn càng nhiều dữ liệu trong mỗi gói càng tốt.

bạn đã điều chỉnh gói sắp xếp của bạn threshould? Kiểm tra nó trên tcp numordering tại / Proc trên Linux. Trên các đường ống dài, thông thường là một hiệu ứng đa đường dẫn đến việc phát hiện mất gói tin sai, truyền lại và giảm tốc độ bạn đã gửi trong biểu đồ của mình. Nó cũng gây ra rất nhiều Acks trùng lặp, vì vậy nó đáng để kiểm tra. Đừng quên bạn phải điều chỉnh cả hai bên của đường ống để có độ co giãn tốt và sử dụng ít nhất là khối. Một giao thức tương tác, như ftp có thể gây hại cho bất kỳ tcp nào để tối ưu hóa đường ống dài mà bạn có thể làm. Trừ khi bạn chỉ chuyển các tập tin lớn.

Những gì bạn thấy có vẻ khá bình thường đối với tôi, dựa trên độ trễ bạn đang báo cáo cho các trang web khác nhau của mình. Độ trễ sẽ giết chết thông qua hầu hết mọi kết nối, bất kể băng thông có sẵn, rất nhanh chóng.

Silver Peak cung cấp công cụ ước tính nhanh và bẩn cho thông lượng mà bạn có thể thấy với một lượng băng thông nhất định có độ trễ nhất định tại đây: http://www.silver-peak.com/calculator/

Cắm kết nối 100mbit với độ trễ phù hợp mà bạn đang thấy và bạn sẽ thấy rằng tốc độ của bạn thực sự phù hợp (Khoảng) với những gì bạn sẽ thấy.

Đối với Windows cung cấp hiệu suất kém hơn so với Linux, thật không may, tôi không thể đưa ra bất kỳ đề xuất tốt nào ở đó. Tôi đoán bạn đang thực hiện một so sánh táo với phần cứng giống hệt nhau (cụ thể là các NIC)?