Назад | Перейти на главную страницу

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

В настоящее время я запускаю FreeNAS и использую SMB 3 на машинах с Windows для копирования папок с более чем 80000 файлами, каждая из которых составляет около 35 МБ. Вот конфиг

FreeNAS

Рабочие станции

Итак, у меня есть эти диски RAID 0 с примерно 4 ТБ файлов каждый, и каждый файл имеет размер 35 МБ. В каждой папке около 80000 файлов. 8 одновременных переводов на 8 рабочих станций.

Когда я использую robocopy для копирования файлов. Я получаю около 1,8 Гбит / с при их передаче. Затем, по прошествии времени, копия становится все глубже и глубже в файлы, скорость которых падает примерно до 600 Мбит / с. Это происходит независимо от того, использую ли я / MT: 10 из / MT: 1 в robocopy. EMCopy не стал намного лучше, а freefilesync хочет умереть примерно через 3 часа. Я хочу, чтобы он хотя бы оставался стабильным на уровне 1,8 Гбит / с, а не постоянно падал. Во время этих передач также перестает отвечать на запросы просмотр общих ресурсов на рабочих станциях. Кто-нибудь еще испытал это?

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

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

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

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

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

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

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

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

Хорошо, похоже, проблема решена. Вот решение.

в /etc/samba/smb-shares.conf.local

Эта строка была добавлена ​​в общий ресурс, который мы используем

case sensitive = yes

Теперь мы передаем стабильные 200 Мбит / с. Хотя это не идеальная скорость, она не снижается со временем. Это устраняет проблему снижения скорости.

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

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

Предлагаю вам попробовать следующее:

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

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

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