SMB2 более 1 Гб PTP Link - задержка 10 мс

Может быть, я ожидаю гораздо большего от SMB2, чем то, что реально. Вот сценарий.

  • Клиент Windows 7 (локальный)
  • A) Сервер Win2008R2 (LAN - 1 ГБ, <1 мс)
  • B) Сервер Win2008R2 (WAN - 1 ГБ, 10 мс)
  • (Идентичное серверное оборудование)

Сценарий 1:
У меня есть один файл размером 1 ГБ.
Перенос с Win7 на сервер A: 10 секунд
Перенос с Win7 на сервер B: 18 секунд

Сценарий 2:
У меня есть каталог, размером 275 МБ, примерно 2700 файлов.
Переход с Win7 на сервер A: 57 секунд
Переход с Win7 на сервер B: 551 секунда

Неужели задержка в 10 мс действительно вызывает огромный удар по SMB2 в сценарии 2? Я полагаю, что это имело бы смысл, если бы SMB2 болтал взад-вперед о каждом отдельном файле (несколько вызовов на файл), в дополнение к времени, которое требуется для фактической передачи файла, и это занимает 10 мс в каждом направлении (клиент-> сервер, server-> клиент).

Итак, я думаю, все, что я просто спрашиваю - действительно ли это так хорошо, как SMB2 преодолевает WAN, не пытаясь играть в игры с ускорением SMB2 или другие сторонние приемы?


Update1:
Чтобы уточнить: я не спрашиваю, почему много файлов занимает больше времени, чем один большой - я понимаю, что это добавит накладных расходов, несмотря на средний. В частности, я спрашиваю, достаточно ли 10 мс для учета разницы в 10 минут между сервером A и сервером B в сценарии 2. Я понимаю, что нет точного ответа "да" или "нет".

На самом деле просто не знаком с тем, как конкретно болтливый SMB2. Я признаю, что ДОЛЖЕН быть болтливым, по характеру того, что он делает. Просто интересно, что другие наблюдали в подобных ситуациях. (передача сложной структуры каталогов - более 10 мс на 1 ГБ или выше)

2 ответа

Нет, это не проблема SMB2, это проблема передачи большого количества маленьких файлов поверх любого протокола. В дополнение к дополнительным сетевым издержкам вам приходится иметь дело с гораздо большим временем поиска и, по сути, случайным чтением, а не последовательным чтением, поэтому дисковые операции также выполняются намного медленнее. Проверьте себя, например, с помощью USB-накопителя или внешнего жесткого диска. И, если хотите, другой сетевой протокол, например FTP.

Ваши результаты будут очень похожи - передача большого количества маленьких файлов в целом занимает намного больше времени, чем передача одного большого файла. SMB2 может быть плохо оптимизирован (слишком болтлив) для передачи большого количества файлов и WAN-ссылок, но основная проблема с производительностью, которую вы видите, будет сохраняться, независимо от протокола.

10мк задержка приходит откуда? Это слишком высоко для локальной сети и очень мало для глобальной сети.

И да, это вызывает проблемы - SMB2 довольно болтлив и не оптимизирован для высокой задержки. Много файлов - это МНОГО операций. Много. Все работает один за другим. ВАМ было бы лучше в случае сценария 2 разделить 2700 файлов и выполнить несколько операций копирования параллельно. Есть причина, по которой MS сделал SMB3..

Другие вопросы по тегам