У нас есть пара новых Ethernet-каналов с разнесенной маршрутизацией 1 Гбит / с, расположенных на расстоянии около 200 миль друг от друга. «Клиент» - это новая достаточно мощная машина (HP DL380 G6, два E56xx Xeon, 48 ГБ DDR3, пара R1 из 300 ГБ SAS-дисков со скоростью 10 оборотов в минуту, W2K8R2-x64), а «сервер» - тоже достаточно приличная машина (HP BL460c G6 , два процессора Xeon E55xx, 72 ГБ, пара R1 из 146 ГБ дисков SAS со скоростью 10 оборотов в минуту, двухпортовый адаптер главной шины Emulex 4 Гбит / с FC, подключенный к двум Cisco MDS9509, а затем к выделенному HP EVA 8400 с дисками 128 x 450 ГБ 15 оборотов в минуту, RHEL 5.3-x64).
Используя SFTP от клиента, мы видим только пропускную способность около 40 Кбит / с при использовании больших (> 2 ГБ) файлов. Мы выполнили тесты «сервер для« другого локального сервера »» и увидели около 500 Мбит / с через локальные коммутаторы (Cat 6509), мы собираемся сделать то же самое на стороне клиента, но это примерно через день.
Какие еще методы тестирования вы бы использовали, чтобы доказать поставщикам ссылок, что проблема в них?
Тюнинг слона:
Это может потребовать настройки, вероятно, не здесь, как говорит pQd. Этот вид связи известен как «длинная толстая трубка» или «слон» (см. RFC 1072). Поскольку это толстый гигабитный канал, идущий на расстояние (в данном случае расстояние - это время / задержка), окно приема tcp должно быть большим (см. Изображения TCP / IP, иллюстрированный том 1, раздел расширений TCP).
Чтобы выяснить, каким должно быть окно приема, вы вычисляете произведение задержки полосы пропускания:
Bandwidth * Delay = Product
Если есть задержка 10MS, этот калькулятор По оценкам, вам нужно окно приема размером около 1,2 МБ. Мы можем сами произвести расчет по приведенной выше формуле:
echo $(( (1000000.00/.01)/8 ))
12500000
Так что вы можете запустить дамп пакета, чтобы увидеть, масштабирование окна tcp (расширение TCP, которое допускает большие окна) происходит правильно, чтобы настроить это, как только вы выясните, в чем заключается большая проблема.
Граница окна:
Если проблема заключается в том, что размер окна ограничен без масштабирования, я бы ожидал следующих результатов, если масштабирование окна не выполняется и существует задержка около 200 мс независимо от размера канала:
Throughput = Recieve Window/Round Trip Time
Так:
echo $(( 65536/.2 ))
327680 #Bytes/second
Чтобы получить результаты, которые вы видите, вам просто нужно определить задержку, которая будет:
RTT = RWIN/Throughput
Итак (для 40 кБайт / с):
echo $(( 65536.0/40000.0 ))
1.63 #Seconds of Latency
(Пожалуйста, проверьте мою математику, и они, конечно, не включают в себя все накладные расходы протокола / заголовка)
40 кбит / с - это очень мало [до такой степени, что я подозреваю неисправные медиаконвертеры / несоответствие дуплексного режима [но у вас есть гигабит, поэтому для полудуплекса нет места!] И т. Д.]. должны быть потери пакетов или очень высокий джиттер.
iperf - это первый инструмент, который приходит мне на ум для измерения доступной пропускной способности. бегать в сторону
iperf -s
а с другой:
iperf -t 60 -c 10.11.12.13
затем вы можете поменять местами роли клиент / сервер, использовать -d для дуплекса и т. д. запустить mtr между обеими машинами перед началом теста и посмотреть, какие задержки / потери пакетов у вас есть на неиспользуемом канале и как они меняются во время передачи данных.
вы хотели бы видеть: очень небольшой джиттер и отсутствие потерь пакетов до тех пор, пока канал не будет насыщен на 90 с лишним процентов его пропускной способности.
tracepath может показать вам проблемы маршрутизации между двумя сайтами.
iperf, ttcp и bwping могут предоставить вам полезную информацию.
Вы знаете, как предоставляется ссылка на 1 ГБ? вы используете мост или маршрутизируете по этой ссылке? Какое у вас соглашение об уровне обслуживания для ссылки? вы могли быть сформированы вашим провайдером ссылок?
если вы получаете только 40 Кбайт, то это серьезная проблема, вы уверены, что это не ссылка 1 МБ, а не ссылка 1 ГБ / с. Вероятно, вы обнаружите, что скорость ссылки не такая, как вы думаете :-)
RFC 2544 или Y.156sam
Это сетевые тесты, которые проводятся для подтверждения SLA оператором связи. IPERF и подобные методы тестирования сети не поддаются проверке.