Улучшить скорость записи для высокоскоростного копирования файлов?

Question

Я пытался найти самый быстрый способ кодирования процедуры копирования файлов для копирования большого файла на оборудование RAID 5.

Средний размер файла составляет около 2 ГБ.

Есть 2 окна (оба работают под win2k3). Первое поле - это источник, где находится большой файл. А во второй коробке есть хранилище RAID 5.

http://blogs.technet.com/askperf/archive/2007/05/08/slow-large-file-copy-issues.aspx

Приведенная выше ссылка ясно объясняет, почему копирование windows, robocopy и другие распространенные утилиты копирования снижают производительность записи. Поэтому я написал программу на C / C ++, которая использует API CreateFile, ReadFile & WriteFile с флагами NO_BUFFERING & WRITE_THROUGH. Программа имитирует ESEUTIL.exe, в том смысле, что она использует 2 потока, один для чтения и один для записи. Поток читателя читает 256 КБ из источника и заполняет буфер. Как только 16 таких блоков по 256 КБ заполнены, поток записи записывает содержимое буфера в файл назначения. Как видите, поток записи записывает 8 МБ данных за 1 кадр. Программа выделяет 32 таких 8-мегабайтных блока ... следовательно, запись и чтение могут происходить параллельно. Подробную информацию о ESEUtil.exe можно найти по ссылке выше. Примечание: я забочусь о проблемах выравнивания данных при использовании NO_BUFFERING.

Я использовал утилиты для разметки, такие как ATTO, и обнаружил, что наше оборудование RAID 5 имеет скорость записи 44 МБ в секунду при записи блока данных 8 МБ. Что составляет около 2,57 ГБ в минуту .

Но моя программа может достичь только 1,4 ГБ в минуту.

Может кто-нибудь помочь мне определить, в чем проблема? Существуют ли более быстрые API, кроме CreateFile, ReadFile, WriteFile, доступные?

Answer 1

Вы должны использовать асинхронный ввод-вывод для достижения максимальной производительности. Это открывает файл с FILE_FLAG_OVERLAPPED и использует LPOVERLAPPED аргумент WriteFile. Вы можете или не можете получить лучшую производительность с FILE_FLAG_NO_BUFFERING. Вам придется проверить, чтобы увидеть.

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

Вам также следует проверить, какой размер больше подходит для каждого блока ввода-вывода. По моему опыту Существует огромная разница в производительности между копированием файла 4k за раз и копированием 1Mb за раз.

В моем прошлом тестировании этого (несколько лет назад) я обнаружил, что на размерах блоков ниже около 64 КБ преобладали служебные данные, и общая пропускная способность продолжала улучшаться при увеличении размеров блоков до 512 КБ. Я не удивлюсь, если для сегодняшних накопителей вам понадобится использовать блоки размером более 1 МБ для получения максимальной пропускной способности.

Числа, которые вы используете в настоящее время, представляются разумными, но могут быть неоптимальными. Также я вполне уверен, что FILE_FLAG_WRITE_THROUGH предотвращает использование кеша на диске и, следовательно, будет стоить вам немало производительности.

Вам также необходимо знать, что копирование файлов с использованием CreateFile / WriteFile не приведет к копированию метаданных, таких как метки времени или альтернативные потоки данных в NTFS. Вам придется заниматься этими вещами самостоятельно.

На самом деле замена CopyFile вашим собственным кодом - довольно большая работа.

Приложение:

Вероятно, мне следует упомянуть об этом, когда я попробовал это с программным обеспечением Raid 0 в WindowsNT 3.0 (около 10 лет назад). Скорость была ОЧЕНЬ чувствительна к выравниванию в памяти буферов. Оказалось, что в то время драйверы SCSI должны были использовать специальный алгоритм для выполнения DMA из списка разброса / сбора, когда в DMA было более 16 физических областей памяти (64 КБ). Для гарантированной оптимальной производительности требуются физически непрерывные выделения - это то, что могут запрашивать только водители. Это было в основном обходным путем для ошибки в контроллере DMA популярного чипсета в то время, и вряд ли все еще будет проблемой.

НО - я все равно настоятельно рекомендую вам проверить ВСЕ мощности 2 блоков размером от 32 КБ до 32 МБ, чтобы увидеть, какая из них быстрее. И вы можете подумать о том, чтобы проверить, работают ли некоторые буферы последовательно быстрее других - это не случайно.

Answer 2

Некоторое время назад я написал в блоге сообщение о вводе-выводе асинхронных файлов и о том, как часто это приводит к синхронности, если вы все не делаете правильно (http://www.lenholgate.com/blog/2008/02/when-are-asynchronous-file-writes-not-asynchronous.html).

Ключевым моментом является то, что даже когда вы используете FILE_FLAG_OVERLAPPED и FILE_FLAG_NO_BUFFERING, вам все равно необходимо предварительно расширять файл, чтобы асинхронным операциям записи не приходилось расширять файл по мере его появления; по соображениям безопасности расширение файла всегда синхронно. Для предварительного продления необходимо сделать следующее:

• Включить привилегию SE_MANAGE_VOLUME_NAME.
• Открыть файл.
• Найти нужную длину файла с помощью SetFilePointerEx().
• Установить конец файла с помощью SetEndOfFile().
• Установить конец действительных данных в файле SetFileValidData().
• Закройте файл.

Тогда ...

• Откройте файл для записи.
• Выпуск записи

Answer 3

Я провел несколько тестов и получил некоторые результаты. Тесты проводились на 100 Мбит / с и 1 Гбит / с. Исходный компьютер - сервер Win2K3 (SATA), а целевой компьютер - сервер Win2k3 (RAID 5).

Я провел 3 теста:

1) Network Reader -> Эта программа просто читает файлы по сети. Цель программы - найти максимальную скорость чтения н / ж. Я выполняю операции чтения без буфера, используя CreateFile & ReadFile.

2) Disk Writer -> Эта программа измеряет скорость RAID 5 путем записи данных. Не буферизированные записи выполняются с использованием CreateFile и WriteFile.

3) Blitz Copy -> Эта программа является механизмом копирования файлов. Копирует файлы по сети. Логика этой программы обсуждалась в первоначальном вопросе. Я использую синхронный ввод-вывод с NO_BUFFERING для чтения и записи. Используются следующие API-интерфейсы: CreateFile, ReadFile & WriteFile.

---

Ниже приведены результаты:

ЧИТАТЕЛЬ СЕТИ: -

100 Мбит / с NIC

Потребовалось 148344 мсек для чтения 768 МБ с размером фрагмента 8 КБ.

Потребовалось 89359 мсек для чтения 768 МБ с размером фрагмента 64 КБ

Потребовалось 82625 мсек для чтения 768 МБ с размером фрагмента 128 КБ

Потребовалось 79594 мсек для чтения 768 МБ с размером фрагмента 256 КБ

Потребовалось 78687 мсек для чтения 768 МБ с размером фрагмента 512 КБ

Потребовалось 79078 мс для чтения 768 МБ с размером фрагмента 1024 КБ

Потребовалось 78594 мсек для чтения 768 МБ с размером фрагмента 2048 КБ

Потребовалось 78406 мсек для чтения 768 МБ с размером фрагмента 4096 КБ

Потребовалось 78281 мс для чтения 768 МБ с размером фрагмента 8192 КБ

1 Гбит / с NIC

Потребовалось 206203 мсек для чтения 5120 МБ (5 ГБ) с размером фрагмента 8 КБ

Потребовалось 77860 мс для чтения 5120 МБ с размером фрагмента 64 КБ

Потребовалось 74531 мс для чтения 5120 МБ с размером фрагмента 128 КБ

Потребовалось 68656 мсек для чтения 5120 МБ с размером фрагмента 256 КБ

Потребовалось 64922 мс для чтения 5120 МБ с размером фрагмента 512 КБ

Потребовалось 66312 мсек для чтения 5120 МБ с размером фрагмента 1024 КБ

Потребовалось 68688 мс для чтения 5120 МБ с размером фрагмента 2048 КБ

Потребовалось 64922 мсек для чтения 5120 МБ с размером фрагмента 4096 КБ

Потребовалось 66047 мс для чтения 5120 МБ с размером фрагмента 8192 КБ

ДИСКОВЫЙ ПИСАТЕЛЬ: -

Запись выполнена на RAID 5 с NO_BUFFERING & WRITE_THROUGH

Запись 2048 МБ (2 ГБ) данных с размером блока 4 МБ заняла 68328 мс.

Запись 2048 МБ данных с размером блока 8 МБ заняла 55985 мс.

Запись 2048 МБ данных с размером фрагмента 16 МБ заняла 49569 мс.

Запись 2048 МБ данных с размером фрагмента 32 МБ заняла 47281 мс.

Запись выполняется на RAID 5 только с NO_BUFFERING

Запись 2048 МБ (2 ГБ) данных с размером блока 4 МБ заняла 57484 мс.

Запись 2048 МБ данных с размером блока 8 МБ заняла 52594 мс.

Запись 2048 МБ данных с размером фрагмента 16 МБ заняла 49125 мс.

Запись 2048 МБ данных с размером фрагмента 32 МБ заняла 46360 мс.

Производительность записи линейно снижается по мере уменьшения размера чанка. И флаг WRITE_THROUGH вводит некоторое снижение производительности

BLITZ COPY: -

1 Гбит / с NIC, копирование 60 ГБ файлов с NO_BUFFERING

Время завершения копирования: 2236735 мс. То есть 37,2 мин. Скорость ~ 97 ГБ / чел.

100 Мбит / с NIC, копирование 60 ГБ файлов с NO_BUFFERING

Время, затраченное на завершение копирования: 7337219 мс. Т.е. 122 мин. Скорость ~ 30 ГБ / чел.

Я попытался использовать программу 10-FileCopy от Джеффри Ритчера, которая использует Async-IO с NO_BUFFERING. Но результаты были плохими. Я предполагаю, что причиной может быть размер куска 256 КБ ... 256 КБ запись на RAID 5 ужасно медленная.

Сравнение с робокопией:

100 Мбит / с NIC: Blitz Copy и robocopy выполняют @ ~ 30 ГБ в час.

Сетевая карта 1 Гбит / с: Blitz Copy работает со скоростью ~ 97 ГБ в час, а при робокопии - ~ 50 ГБ в час.

Answer 4

Правильный способ сделать это с небуферизованным полностью асинхронным вводом / выводом. Вы захотите выполнить несколько операций ввода-вывода, чтобы поддерживать очередь. Это позволяет файловой системе, драйверу и подсистеме Raid-5 более оптимально управлять операциями ввода-вывода.

Вы также можете открывать несколько файлов и выполнять чтение и чтение нескольких файлов.

ВНИМАНИЕ! Оптимальное количество ожидающих операций ввода-вывода и способ чередования операций чтения и записи будут в значительной степени зависеть от самой подсистемы хранения. Ваша программа должна быть сильно параметризована, чтобы вы могли ее настроить.

Примечание - я верю, что Robocopy был улучшен - вы пробовали это? Я

Answer 5

Если скорость записи так важна, почему бы не рассмотреть RAID 0 для конфигурации вашего оборудования?

• Заказчик хочет RAID 5.
• Предпочтительнее RAID 0 из-за лучшей отказоустойчивости.
• Заказчик удовлетворен тем, что может предложить RAID 5. Вопрос здесь тестирование аппаратного обеспечения с использованием ATTO показывает скорость записи 2,57 ГБ в минуту (8 МБ кусок записать), почему инструмент копирования не может достичь близко к нему? Что-то вроде 2 ГБ на Мин это то, на что мы смотрим. До сих пор нам удавалось достичь только ~ 1,5 ГБ в минуту.

Answer 6

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

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

Если на вашей платформе установлены контроллеры DMA, попробуйте использовать их.

Answer 7

Как быстро вы можете прочитать исходный файл, если не пишете место назначения?

Является ли исходный файл фрагментированным? Фрагментированное чтение может быть на порядок медленнее, чем непрерывное чтение. Вы можете использовать утилиту "contig", чтобы сделать ее непрерывной:

http://technet.microsoft.com/en-us/sysinternals/bb897428.aspx

Как быстро сеть, соединяющая две машины?

Вы пробовали просто писать фиктивные данные, не читая их сначала, как это делает ATTO?

Есть ли у вас более одного запроса на чтение или запись во время полета?

Каков размер полосы вашего массива RAID-5? Запись полной полосы за раз - это самый быстрый способ записи в RAID-5.