Медленное копирование терабайт сотен тысяч файлов в папку

Основная причина низкой скорости передачи, возможно, заключается в том, что дискам M2 рабочей станции необходимо выполнять много случайных чтений.

Быстрые NVMe M2 (которые вам больше всего нравятся) вероятно, использую, я думаю) рекламируются со скоростью до нескольких ГБ / ср / Вт.Это верно для последовательного чтения для больших файлов, но в вашей ситуации вместо этого будет случайное чтение. Скорость случайного чтения для обычных потребительских / полупрофессиональных твердотельных накопителей NVMe M2 составляет от 70 МБ / с до 110 МБ / с, что соответствует вашей скорости 600 Мбит / с. Обзоры твердотельных накопителей часто включают результаты случайной скорости чтения, откуда я и получил этот диапазон.

Существуют твердотельные накопители, такие как твердотельные накопители Intel Optane, которые могут обеспечивать произвольную скорость чтения примерно на уровне 500 МБ / с.

Кроме того, вы заявить, что вы подключаете диски через USB-C. В зависимости от того, какая технология используется, USB3.0, 3.1, 3.2 или Thunderbolt, это соединение также может вызывать замедление. Внутренние диски NVMe M2 (или другие более быстрые диски на базе PCI-e) могут решить проблему.

Чтобы подтвердить или опровергнуть мое предположение, вы можете использовать диспетчер задач Windows 10 или монитор производительности. Диспетчер задач покажет вам процент загруженности дисков. Если у рассматриваемого диска (ов) установлено 100% или что-либо выше 80%, то они, вероятно, ограничивают скорость. С другой стороны, если он на холостом ходу, то это не ограничение. Отказ от ответственности: я не знаю, насколько надежны проценты занятости диспетчера задач Windows, особенно для внешних дисков.

Если окажется, что диски на исходной стороне вообще не заняты, вы можете проверить на стороне назначения и посмотрите, как там работают диски (для этого можно использовать инструмент iostat).

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

Или попробуйте исключить некоторые компоненты, подключив устройства напрямую без дополнительного переключения между ними. или что угодно, что вы можете удалить из сценария для тестирования.

Без подробного профилирования как источника, так и пункта назначения, он Трудно дать однозначный ответ. Тем не менее, я не думаю, что исходный диск NVMe является узким местом; в конце концов, вы читаете довольно большие файлы со значительным объемом последовательного чтения.

Из-за большого количества задействованных файлов я больше склоняюсь к неэффективности в NTFS и / или самом протоколе SMB.

Я предлагаю попробуйте следующее:

• на целевом хосте создайте выделенный набор данных с отключенными синхронизацией, контрольной суммой и сжатием (например: zfs set sync = disabled и т. д.). Примечание: вы должны рассматривать это только как тестовое и / или временное решение, я не предлагаю постоянно работать с этими настройками;

• на исходном хосте попробуйте загрузиться с linux live cd / usb и к передавать файлы по протоколу NFS (а не SMB). Вам следует в основном выполняются следующие действия:

  • загрузка с живого компакт-диска;
  • установка утилит nfs и ntfs-3g;
  • монтирование файловой системы NTFS (то есть: в / mnt / localdir );
  • ] настроить экспорт NFS в месте назначения;
  • смонтировать его на исходном хосте (например: mount xxxx: / dstdir / mnt / localdir );
  • использовать cp или ] rsync для передачи этих файлов;
  • на другом терминале попробуйте запустить dstat -d -f -n на обоих хостах на контролировать передачу файлов.