Медленная передача на расстояние
Из нашего центра обработки данных в Нью-Йорке переводы в более отдаленные местоположения имеют низкую производительность.
Используя тест скорости для тестирования различных мест, мы можем легко насыщать наш 100-мегабитный восходящий канал до Бостона и Филадельфии. Когда я использую тест скорости для определения местоположения на западном побережье США или Европы, я часто вижу только около 9 Мбит / с.
Моя первая реакция заключается в том, что это проблема масштабирования окна (произведение задержки полосы пропускания). Тем не менее, я настроил параметры ядра Linux на тестовой машине на западном побережье и использовал iperf до такой степени, что размер окна был достаточным для поддержки 100 мегабайт в секунду и все еще имел низкие скорости (проверено в захвате). Я также попытался отключить алгоритм Нэгла.
У нас низкая производительность как для Linux, так и для Windows, но это значительно хуже (1/3) скорости при использовании Windows.
Форма трансфера (без нагла):
У провала около 10 секунд есть ~ 100 дублированных подтверждений.
Форма размера минимального окна приемника с течением времени:
Есть идеи, куда пойти дальше, чтобы прижать горлышко бутылки?
Некоторые результаты теста скорости (загрузить с помощью speedtest.net):
- Филадельфия: 44 мбит (Остальные используют наш сайт ;-))
- Майами: 15 мбит
- Даллас: 14 мбит
- Сан-Хосе: 9 мбит
- Берлин: 5 мбит
- Сидней: 2,9 мбит
Еще больше данных:
Майами: 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
Сан-Хосе: 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
Филадельфия: 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
Берлин: 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
Обновить:
Изучив это немного глубже с Высоким Джеффом, мы обнаружили кое-что странное. Согласно TCPDump на отправитель сторона отправляет пакеты как пакеты 65k по Интернету. Когда мы смотрим на свалки на приемной стороне, они приходят фрагментированными 1448, как и следовало ожидать.
Вот как выглядит дамп пакета на стороне отправителя:
Тогда отправитель думает, что он просто отправляет пакеты размером 64 КБ, но в действительности, что касается получателя, он отправляет пакеты пакетов. Конечный результат - испорченный контроль перегрузки. Вы можете видеть, что это график длины пакетов данных, отправляемых отправителем:
Кто-нибудь знает, что может заставить отправителя подумать, что есть MTU 64k? Может быть, некоторые /proc, ethtool или ifconfig parameter? (ifconfig показывает, что MTU составляет 1500). Мое лучшее предположение сейчас - это какое-то аппаратное ускорение, но я не уверен, что конкретно.
Подраздел 2-2 IV:
Просто подумал, так как в этих пакетах 64k установлен бит DF, возможно, мой провайдер все равно их фрагментирует и испортил автоматическое обнаружение MSS! Или, возможно, наш брандмауэр неправильно настроен ...
Адъюнкт Edit 9.73.4 20-60:
Причина, по которой я вижу пакеты размером 64 КБ, заключается в том, что включена разгрузка сегментов (tso и gso, см. Ethtool -K). После их отключения я не вижу улучшений в скорости переводов. Форма немного меняется, и ретрансляции идут меньшими сегментами:
Я также пробовал все различные алгоритмы перегрузки в Linux без каких-либо улучшений. Мой провайдер из Нью-Йорка попытался загрузить файлы на тестовый ftp-сервер в операционной из помещения, где мы находимся, и получил в 3 раза большую скорость.
Запрошенный отчет MTR из NY в 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
Мое первое предположение - убедиться, что окно TCP открывается достаточно широко, чтобы покрыть продукт задержки полосы пропускания. Предполагая, что это настроено правильно (и поддерживается обоими сторонами), я бы затем изучил трассировку пакета, чтобы убедиться, что окно действительно открывается и что один из переходов на пути не обрезает масштабирование окна. Если все в порядке и вы уверены, что не сталкиваетесь с переходом с ограниченной пропускной способностью на пути, вероятной причиной ваших проблем является случайное отбрасывание пакетов. Эта гипотеза подтверждается указанием упомянутых вами дублированных ACK. (Дублированные ACK обычно являются прямым результатом потери данных). Также обратите внимание, что с большим произведением задержки в полосе пропускания и, следовательно, с большим открытым скользящим окном, даже низкие уровни случайных отбрасываний пакетов могут значительно снизить общую пропускную способность соединения.
Боковое примечание: для массовой передачи данных через TCP и через многопоточное WAN-соединение не должно быть необходимости или причины отключать Nagle. Фактически, именно по этому сценарию существует Нэгла. Как правило, Nagle нужно отключать только для интерактивных соединений, когда дейтаграммы размером менее MTU должны быть вытеснены без какой-либо задержки. то есть: для массовых передач вы хотите, чтобы в каждом пакете было как можно больше данных.
вы настроили порог переупорядочения пакетов? Проверьте это в tcp_reordering в / proc в Linux. На длинных трубопроводах часто возникает эффект многолучевого распространения, вызывающий ложное обнаружение потери пакетов, повторную передачу и падение скорости, отправленной вами в диаграмме. Это также вызывает много повторяющихся Acks, поэтому стоит проверить. Не забывайте, что вы должны настроить обе стороны трубы, чтобы получить хорошие результаты и использовать хотя бы кубический размер. Интерактивный протокол, такой как ftp, может нанести вред любому TCP для оптимизации длинных каналов, которую вы можете сделать. Если вы не переносите только большие файлы.
То, что вы видите, мне кажется вполне нормальным, учитывая задержку, которую вы сообщаете на свои различные сайты. Задержка очень быстро убьет пропускную способность практически любого отдельного соединения, независимо от доступной полосы пропускания.
Silver Peak предлагает быструю и грязную оценку пропускной способности, которую вы можете ожидать увидеть с заданным объемом полосы пропускания и заданным уровнем задержки здесь: http://www.silver-peak.com/calculator/
Подключите 100-мегабитное соединение с соответствующими задержками, которые вы видите, и вы обнаружите, что ваши скорости на самом деле совпадают (приблизительно) с тем, что вы должны ожидать.
Что касается Windows, которая обеспечивает более низкую производительность, чем Linux, к сожалению, я не могу предложить никаких хороших предложений. Я предполагаю, что вы проводите сравнение яблок с яблоками с идентичным оборудованием (в частности, с сетевыми адаптерами)?