Z naszego centrum danych w Nowym Jorku transfery do odległych miejsc mają słabą wydajność.
Korzystając z testu prędkości do testowania różnych lokalizacji, możemy łatwo nasycić nasze łącze wysyłające 100 Mb do Bostonu i Filadelfii. Kiedy używam testu prędkości do lokalizacji na zachodnim wybrzeżu USA lub Europy, często widzę tylko około 9 Mb / s.
Pierwszą moją reakcją jest to, że jest to problem ze skalowaniem okien (produkt opóźniający pasmo). Jednak dostosowałem parametry jądra Linux na maszynie testowej na zachodnim wybrzeżu i użyłem iperf do tego stopnia, że rozmiar okna jest wystarczający, aby obsłużyć 100 megabajtów na sekundę i nadal mam wolne prędkości (Verified in Capture). Próbowałem również wyłączyć algorytm Nagle.
Zarówno Linux, jak i Windows uzyskują słabą wydajność, ale jest to znacznie gorsza (1/3) prędkość w systemie Windows.
Kształt przelewu (bez Nagle) jest następujący:
Dip około 10s ma ~ 100 duplikatów.
Kształt minimalnego rozmiaru okna odbiornika w czasie jest następujący:
Jakieś pomysły, gdzie pójść dalej, aby przypiąć szyjkę butelki?
Niektóre wyniki testu prędkości (Prześlij za pomocą speedtest.net):
- Filadelfia: 44 mbit (reszta korzysta z naszej strony ;-))
- Miami: 15 Mb
- Dallas: 14 Mb
- San Jose: 9 mbit
- Berlin: 5 Mbit
- Sydney: 2,9 Mb
Jeszcze więcej danych:
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
Aktualizacja:
Zagłębiając się nieco głębiej w Tall Jeff, znaleźliśmy coś dziwnego. Według TCPDump po stronie nadawcy wysyła on pakiety w postaci 65 000 pakietów przez Internet . Kiedy patrzymy na zrzuty po stronie odbiornika, przybywają one rozdrobnione 1448, jak można się spodziewać.
Oto jak wygląda zrzut pakietu po stronie Sender:
To, co się wtedy dzieje, jest takie, że nadawca myśli, że po prostu wysyła 64 tys. Pakietów, ale w rzeczywistości, jeśli chodzi o odbiorcę, wysyła serie pakietów. Końcowym rezultatem jest pomieszanie kontroli przeciążenia. Możesz zobaczyć, że jest to wykres długości pakietów danych wysyłanych przez nadawcę:
Czy ktoś wie, co może spowodować, że Nadawca uzna, że istnieje 64k MTU? Może niektórzy /proc, ethtoolalbo ifconfig parameter? ( ifconfigpokazuje, że MTU wynosi 1500). Moim najlepszym przypuszczeniem jest teraz jakieś przyspieszenie sprzętowe - ale nie jestem pewien, co konkretnie.
Subedit 2-2 IV:
Właśnie pomyślałem, ponieważ te 64k pakiety mają ustawiony bit DF, być może mój dostawca i tak je fragmentuje i psuje automatyczne wykrywanie MSS! A może nasza zapora sieciowa jest źle skonfigurowana ...
Dodatkowa edycja 9.73.4 20-60:
Powodem, dla którego widzę pakiety 64k jest to, że włączone jest odciążanie segmentów (tso i gso, patrz ethtool -K). Po ich wyłączeniu nie widzę żadnej poprawy szybkości transferów. Kształt nieco się zmienia, a retransmisje są w mniejszych segmentach:
Próbowałem również wszystkich różnych algorytmów przeciążenia w systemie Linux bez poprawy. Mój nowojorski dostawca próbował przesłać pliki na testowy serwer ftp w OR z obiektu, w którym się znajdujemy i osiąga 3-krotną prędkość.
Żądany raport MTR z NY do 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
źródło
Odpowiedzi:
Upewnij się, że okno TCP otwiera się wystarczająco szeroko, aby pokryć Produkt Opóźnienia Przepustowości. Zakładając, że jest poprawnie skonfigurowany (i obsługiwany przez oba końce), następnie zbadam ślad pakietu, aby upewnić się, że okno naprawdę się otwiera i że jeden z przeskoków na ścieżce nie usuwa skalowania okna. Jeśli to wszystko dobrze i jesteś pewien, że nie uderzysz w przeskok o ograniczonej przepustowości na ścieżce, prawdopodobną przyczyną twoich problemów są przypadkowe spadki pakietów. Ta hipoteza jest poparta wskazaniem zduplikowanych ACK, o których wspomniałeś. (Zduplikowane potwierdzenia ACK są zazwyczaj bezpośrednim wynikiem utraty danych). Należy również pamiętać, że przy dużym opóźnieniu przepustowości, a tym samym dużym otwartym przesuwnym oknie,
Uwaga dodatkowa: W przypadku masowego przesyłania danych przez TCP i połączenie WAN z wieloma przeskokami nie powinno być potrzeby ani powodu, aby wyłączać Nagle. W rzeczywistości właśnie ten scenariusz jest powodem, dla którego istnieje Nagle. Zasadniczo Nagle należy wyłączyć tylko w przypadku połączeń interaktywnych, w których datagramy poniżej MTU muszą zostać bezzwłocznie usunięte. tzn .: w przypadku przesyłania zbiorczego chcesz mieć jak najwięcej danych w każdym pakiecie.
źródło
czy dostroiłeś swój pakiet zmieniający kolejność? Sprawdź to na tcp_reordering w / proc w systemie Linux. Na długich potokach efektem wielościeżkowym jest często wykrywanie fałszywej utraty pakietów, retransmisja i spadek prędkości wysyłany na wykresie. Powoduje to również wiele duplikatów Ack, więc warto to sprawdzić. Nie zapomnij, że musisz dostroić obie strony rury, aby mieć dobre wyniki i użyć co najmniej sześciennych. Interaktywny protokół, taki jak ftp, może zaszkodzić każdemu tcp w przypadku optymalizacji długich rur. Chyba że przesyłasz tylko duże pliki.
źródło
To, co widzisz, wydaje mi się całkiem normalne, biorąc pod uwagę opóźnienie, które zgłaszasz do różnych witryn. Opóźnienia mordują przepustowość niemal każdego pojedynczego połączenia, niezależnie od dostępnej przepustowości, bardzo szybko.
Silver Peak oferuje szybki i brudny estymator przepustowości, którego można oczekiwać przy danej przepustowości przy danym poziomie opóźnienia tutaj: http://www.silver-peak.com/calculator/
Podłącz 100mbitowe połączenie z odpowiednimi opóźnieniami, które zobaczysz, a przekonasz się, że Twoje prędkości faktycznie pasują (w przybliżeniu) do tego, czego powinieneś się spodziewać.
Jeśli chodzi o system Windows zapewniający gorszą wydajność niż Linux, niestety nie mogę zaoferować żadnych dobrych sugestii. Zakładam, że robisz porównanie jabłek z jabłkami z identycznym sprzętem (konkretnie NIC)?
źródło