Почему скорость передачи файлов Windows достигает 1,5 гигабайт в секунду?

389
Matt

Я заметил, что передача файлов на одной и той же машине между быстрой nvme m.2 ssd (общая скорость чтения 3,2 ГБ / с и запись 2,7 ГБ / с) и максимальным объемом оперативной памяти составляет 1,4-1,5 ГБ / с. Почему это так? Я запускаю Windows 10 Pro Workstation в качестве ОС и отключаю любые брандмауэры, антивирусные сканеры или другие служебные программы. Диски по отдельности оценивают как выше 2,5 ГБ / с для чтения и записи. Почему передача файлов Windows одного большого файла ограничена скоростью около 1,5 ГБ / с? Я просто оцениваю последовательную производительность чтения и записи. Есть ли в Windows 10 ограничение на передачу файлов?

1
Каждый буфер в передаче должен быть как для чтения, так и для записи, поэтому в лучшем случае следует ожидать половину средней скорости чтения и записи. AFH 5 лет назад 2
Дополнительные ограничения: скорость шины, скорость драйвера, скорость памяти, скорость процессора (команды прерывания медленные). В общем, очень сложно вычислить реальный верхний предел. harrymc 5 лет назад 0
@AFH: запись в память, так что в теории должно быть намного быстрее. harrymc 5 лет назад 0
Какая файловая система используется для источника и цели? Использование NTFS или FAT32 может быть серьезной разницей из-за журналирования NTFS. И с каким инструментом сделать копию? Например, Windows File Explorer, как известно, работает медленно. Tonny 5 лет назад 0
Извините, я неправильно понял ваш вопрос. Попробуйте скопировать в `NUL:` и SSD, и RAM-диск, и это даст вам представление о системных издержках. AFH 5 лет назад 1
@AFH, это не может быть узким местом. У меня на самом деле есть конфигурация raid 0 nvme, скорость чтения которой превышает 10 гигабайт в секунду, и я также могу быстро записывать на оперативный диск. Скорость передачи файлов с помощью проводника Windows достигает 1,5 ГБ / с. Matt 5 лет назад 0
@harrymc, я профилировал все сырые исполнения ssd (на самом деле настройка raid 0, как упомянуто выше) и ram disk. Производительность чтения и записи значительно выше 8 гигабайт в секунду. Там определенно что-то еще происходит с Windows 10 File Explorer передачи файлов. Matt 5 лет назад 0
@ Тонни, я отформатировал оба с помощью ntfs. Но также попробовал FAT32. Не большая разница. ОС да Windows 10 файловый менеджер кажется медленным, что вызвало мой вопрос, мой квест, чтобы выяснить, почему. Matt 5 лет назад 0
Вы копируете большой файл или много маленьких файлов? Если первое, попробуйте `xcopy / J`; если последнее, доступ к каталогу сильно замедлит работу. И я не могу представить, какие интерфейсы вы используете для этих показателей производительности (я полагаю, вы имеете в виду ** Гбит / с **): SATA [ограничен до 6 Гбит / с] (http://www.tested.com/tech / шт / 457172-почему-хранение-диск-скорость-Dont-бей-их-теоретических пределы /). AFH 5 лет назад 0
Проводник Windows, как известно, работает медленно. Попробуйте использовать cmd с robocopy или TeraCopy. harrymc 5 лет назад 0
@AFH, я имел в виду гигабайты. Я запускаю рейд 0 из 4 Evo 970, каждый из которых получает по 4 шт. Диски не sata, я думал, что это было видно из содержания в моем вопросе. Непревзойденная производительность чтения с помощью печально известного инструмента Intel для тестирования производительности составляет 10 ГБ в секунду, а запись - более 7 ГБ в секунду. Я делаю одну копию файла. Matt 5 лет назад 0
@harrymc, весь мой вопрос состоит в том, почему копирование файлового проводника Windows происходит медленно. Я попробую копию / xcopy, как предложено AFH. Matt 5 лет назад 0
TeraCopy и Robocopy работают быстрее. Говорят, что самой быстрой программой копирования файлов является бесплатная [FastCopy] (https://fastcopy.jp/en/). harrymc 5 лет назад 0
@ harrymc, внешние приложения для передачи не вариант для меня. Мне нужно выяснить, почему копии проводника Windows 10 так невероятно медленны. То же самое использование копии файла проводника Windows на Windows Server 2016 не было ограничено. Здесь есть что-то еще, и, кажется, до сих пор никто не знает почему. Matt 5 лет назад 0
Я много лет избегал нетривиального копирования с помощью проводника Windows. Это медленно и медленно по крайней мере с десятилетия. Вот почему я и другие использую сторонние приложения. Robocopy, по крайней мере, является частью Windows, если это помогает. FastCopy - единственный, кто знает, что утверждает, что делает параллельное чтение и запись. harrymc 5 лет назад 0
@harrymc, некоторые выводы: копирование / копирование происходит так же медленно / быстро, как копирование через проводник Windows. TeraCopy и даже FastCopy работают в 2,5–3 раза медленнее. 3 файла по 10 ГБ каждый, скопированные с nvme raid0 на RAM-диск на той же машине, заняли 18 секунд для копирования через copy / xcopy / windows-file-explorer. Теракопия и Fastcopy заняли почти 60 секунд. Matt 5 лет назад 0
Исправление: FastCopy был на самом деле быстрее и занимал всего 8,5 секунд = 3,5 ГБ / с Все остальные надстройки, которые я тестировал, были намного медленнее, чем проводник Windows. К сожалению, все эти тесты не объясняют, почему однопоточное копирование файла так ограничено. Большинство людей могут не жаловаться на скорость передачи 1,5 ГБ / с, но это невероятно расстраивает, когда вы используете сеть 100 Гбит и вам требуется передача данных из кластера nvme m.2 raid0 со скоростью чтения более 10 ГБ / с. Я почти испытываю желание пройти через драйверы ssd на виртуальную машину под Linux. Matt 5 лет назад 0
Таким образом, многопоточные копии увеличивают производительность до 5,8 ГБ / с. Это означает, что все аппаратные компоненты работают как положено. На данный момент мне остается верить, что буферы данных Windows Explorer и связанные с ними параметры являются статическими и не позволяют использовать чрезвычайно быстрые аппаратные ресурсы. Matt 5 лет назад 0
Я обобщил ваши результаты ниже. Не стесняйтесь редактировать мой ответ, если хотите. harrymc 5 лет назад 0

1 ответ на вопрос

1
harrymc

Сводка комментариев к посту и результатов тестов, проведенных постером:

  • Было обнаружено, что все утилиты копирования работают примерно с одинаковой скоростью: Windows Explorer, copy, xcopy, robocopy, TeraCopy.

  • Единственной утилитой, которой удалось достичь максимальной скорости чтения диска, была FastCopy.

Утилита FastCopy отличается тем, что выполняет чтение и запись параллельно и не использует кэш Windows для перемещения данных.

Таким образом, вывод заключается в том, что медлительность копирования файлов при использовании стандартных механизмов Windows обусловлена:

  • Отсутствие параллелизма, так что чтение приостановлено во время записи
  • Врожденная неэффективность механизма кэширования Windows.

Проблема медленного копирования файлов была вокруг Windows с очень давних времен и с самых ранних версий Windows. Приведенные выше результаты могут также объяснить, почему Linux, как сообщается, более эффективен при работе с дисками, чем Windows.

при всем уважении, но это вопиющий плагиат и к тому же совершенно ошибочно заключенный. Robocopy может выполнять многопоточное копирование. Кроме того, ваши выводы нигде не приблизились даже к ответу на вопрос. «Медленные копии файлов Windows существуют уже давно», так что ... зачем? Это ваш честный вывод? Как вы заработали 229 тысяч повторений? Невероятный. Matt 5 лет назад 0
Прочитав ваш ответ еще раз, я решил отказаться от вашего ответа. Я, как правило, не голосую никакими ответами на вопросы, которые я сам задаю. Но в этом случае ... вы снова прочитали свой ответ? Linux более эффективен из-за вышеуказанных результатов? Разве не было бы лучше участвовать только в вопросах, в которых можно требовать некоторого опыта? Я являюсь одним из лучших участников форума по количественным финансам StackExchange, но никогда не осмелюсь вникать в темы, о которых я не знаю. Я думаю, что вы сделаете себе отличную услугу, полностью удалив здесь свой ответ ... Matt 5 лет назад 0
Я всегда пробую Windows Explorer в любой новой версии Windows, и они всегда медленные - личный опыт чего-то значит. Linux быстрее управляет файлами - мой личный опыт и опыт многих дата-центров. Плагиат чего? Я тщательно не цитировал ваши результаты, только мои предложения. Напоминаю вам - ваши результаты * были * из-за моих предложений, и спасибо за то, что мои убеждения и опыт здесь количественно проверены. Для многопоточности в Robocopy - он все еще проходит через кеш Windows, не так ли, так что, очевидно, все еще замедляется. harrymc 5 лет назад 1
На этом сайте часто случается, что я исследую проспект с плакатом, и мы вместе приходим к объяснению или решению. Затем, как правило, плакат попросит меня подвести итоги, что я и сделал здесь. Так я получаю большую часть своей репутации. Очевидно, это не ваш стиль, но, пожалуйста, будьте разумнее. harrymc 5 лет назад 1
Примечание. Если вы хотите добавить свои числовые результаты в мой ответ, сделайте это, либо вы можете разрешить мне это сделать. Если нет, то нет проблем. harrymc 5 лет назад 1
Ваш пост не отвечает на поставленный вопрос. Это только повторяет то, что я уже сказал. Я спросил, почему передача файлов проводника Windows происходит медленно. Смотря на то, что они всегда были медленными, не отвечает на вопрос вообще. Если вы обсуждали потенциальные узкие места в потоке данных между устройствами pcie и памятью или узкие места, когда данные направляются через ЦП или указывали на потенциальные решения, такие как smb direct / rmda, тогда ваш ответ повысил бы ценность. В его нынешнем виде он не освещает, не разъясняет, не предлагает решения и не предлагает другие средства правовой защиты. Достаточно сказано. Matt 5 лет назад 0
Редактировать: Имеется ввиду SMB direct / RDMA Matt 5 лет назад 0
Я понимаю, что это не ваш тип ответа. Вы хотели теоретический дискурс и анализ, но, к сожалению, здесь нет узких мест в устройствах pcie, памяти или процессоре, поскольку такие общие ограничения были бы применимы и к FastCopy. Некоторое время назад я изучил источник FastCopy и обнаружил, что здесь нет волшебных уловок, прямого доступа к оборудованию, только обращения к стандартному Windows API. Это действительно, действительно, получает свою скорость, избегая кеша и выпуская чтение и запись параллельно, используя низкоуровневый Windows API. Что еще сказать о плохом программировании в кеше Windows и драйверах? harrymc 5 лет назад 1

Похожие вопросы