.png)
В Windows 8.1 я использую Robocopy для сохранения данных 2 серверов на выделенном дисковом пространстве ПК. Объем данных составляет 147 314 файлов в 4 110 папках (66 841 845 760 байт).
Все 3 задействованных ПК оснащены процессором i7 с 4 ядрами и находятся в сети 1 Гбит. Целевое пространство хранения (зеркальное и чередующееся на D:) реализовано с использованием корпуса JBOD 4 x 4 ТБ.
Учитывая наличие у процессора 4 ядер и гиперпоточность, я ожидал, что лучше всего подойдет переключатель Robocopy /MT:8, а более 8 потоков будут излишними из-за неэффективного управления потоками.
Я это проверил. Я перечисляю данные четвертой серии тестов здесь (продолжительность в мм:сс):
1 thread: 59:19
2 threads: 39:12
4 threads: 29:13
8 threads: 24:36
16 threads: 24:19
32 threads: 24:27
Конечно, несколько секунд при использовании 16 потоков незначительны, ноони последовательныво всех сериях тестов, т.е. не из-за большей нагрузки на тесте с менее чем 16 потоками (если только это не было так во всех 4 сериях тестов). Также обратите внимание, что 32 потока почти всегда немного быстрее, чем 8 потоков.
Вопрос: по какой технической причине использование 16 потоков более эффективно, чем 8 потоков на i7 с 4 гиперпоточными ядрами?
решение1
TL;dr версия: если вы делаете что-то с высокой нагрузкой на процессор, например, перекодируете видео с помощью Handbrake, то вам не захочется использовать больше ядер, чем процессоров, так как негде будет выполнять работу. В этом случае, когда большинство потоков будут проводить 90% своего времени в спящем режиме в ожидании чтения или записи, наличие большего количества потоков работаетдлявы, а не против.
Копирование файлов — задача, не особенно связанная с ЦП. Хотя наличие большего количества ядер может помочь предотвратить блокировку инструмента копирования другими задачами, маловероятно, что каждый поток будет работать на 100% на каждом ядре.
Каждый копирующий поток отправит запрос на чтение на жесткий диск, а затем перейдет в спящий режим, ожидая выполнения запроса на чтение. Обычно время поиска вашего вращающегося ржавого диска составляет 9 миллисекунд, что практически вечность в терминах ЦП, и задача копирования не будет просто крутиться, говоря «он уже готов?» и тратить циклы ЦП. Это заблокирует этот поток на 100% ЦП и будет тратить ресурсы. Нет, происходит следующее: поток выдает запрос на чтение, и поток переходит в спящий режим до тех пор, пока чтение не завершится и данные не будут готовы для следующего шага.
В это время другой поток делает то же самое, блокируется на чтении и засыпает. Это происходит для всех 16 ваших потоков. (В действительности ваши чтения и записи будут происходить в случайное время, поскольку они рассинхронизируются, но вы поняли идею)
Как только один из потоков готов к данным, Windows перепланирует их и начинает обрабатывать для записи. Что касается потока, процесс тот же самый. Он говорит: «записать эти данные в файл x в местоположении y», и Windows берет данные и отменяет планирование потока. Windows выполняет фоновую работу, чтобы выяснить, где находится файл, перемещает данные (потенциально по сети, добавляя еще миллисекунды к задержке), а затем возвращает управление потоку, как только запись прошла успешно.
Ни один поток не будет гореть все время на ядре ЦП, поэтому больше потоков, чем у вас ЦП, не является проблемой. Ни один поток не будет бодрствовать достаточно долго, чтобы это стало проблемой.
Если у вас есть только один процессор и множество других запущенных потоков, то узким местом может оказаться процессор, но в многоядерной системе с такой рабочей нагрузкой я был бы удивлен, если бы проблема заключалась в процессоре.
Вы, скорее всего, будете ограничены производительностью жесткого диска и достигнете глубины очереди для буферов чтения или записи на дисках. Используя больше потоков, вы продвигаетечто-нибудьдо предела своих возможностей, будь то диск или сеть, и единственный способ узнать, какое количество потоков является наилучшим, — это сделать то, что вы сделали, и поэкспериментировать с этим.
В системе с копированием с SSD на SSD я бы предположил, что меньшее количество потоков может быть лучше, поскольку задержка будет меньше, чем при копировании файлов с жестких дисков Rust, передаче по сети и записи на жесткие диски Rust, но у меня нет доказательств, подтверждающих это предположение.