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

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

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

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

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

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

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

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

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

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

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

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

Примечание! Оптимальное количество выдающихся ввода / ОС и о том, как вы прокладываете и записи, будут сильно зависеть от самой системы хранения. Ваша программа должна быть очень настраиваемой, чтобы вы могли настроить ее.

Примечание - я верю, что робокопия улучшилась - вы попробовали это? I

А пока обратно я написал блог, публикующий async-файл ввода / вывода, и как он часто имеет тенденцию к тому, чтобы на самом деле был синхронно, если вы не делаете все правильно ( http://www.lenholgate.com/blog/ 2008/02 / Когда-асинхронные-файловые пишетки-не-асинхронные .html ).

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

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

Тогда ...

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

Вам следует использовать асинхронный ввод-вывод, чтобы получить наилучшую производительность. То есть открыть файл с помощью 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 Мб, чтобы понять, какой из них быстрее. А можно подумать о тестировании, чтобы убедиться, что одни буферы стабильно быстрее других - это неслыханно.

Ошибка - это то, что неправильно, просто неправильно, нет пути обойти ее, ее нужно исправить.

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

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

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

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

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

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

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

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

1) Network Reader -> Эта программа просто читает файлы по сети. Цель программы - найти максимальную скорость чтения n/w. Я выполняю NON BUFFERED чтение с помощью CreateFile & ReadFile.

2) Disk Writer -> Эта программа сравнивает скорость RAID 5 путем записи данных. Запись НЕ БУФФЕРЕДНАЯ производится с помощью CreateFile & WriteFile.

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

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

NETWORK READER:-

100 Mbps NIC

Took 148344 ms to read 768 MB with chunk size 8 KB.

Получило 89359 мс на чтение 768 МБ с размером лотка 64 KB

Получило 82625 мс на чтение 768 МБ с размером лотка 128 KB

Получило 79594 мс на чтение 768 МБ с размером лотка 256 KB

Получило 78687 мс на чтение 768 МБ с размером лотка 512 KB

Получило 79078 мс на чтение 768 МБ с размером лотка 1024 КБ

Took 78594 мс для чтения 768 МБ с размером лотка 2048 КБ

Took 78406 мс для чтения 768 МБ с размером лотка 4096 КБ

Took 78281 мс для чтения 768 МБ с размером лотка 8192 КБ

1 Гбит/с NIC

Took 206203 мс для чтения 5120 МБ (5GB) с размером лотка 8 KB

Took 77860 ms для чтения 5120 MB с размером лотка 64 KB

Took 74531 ms для чтения 5120 MB с размером лотка 128 KB

Took 68656 ms для чтения 5120 MB с размером лотка 256 KB

Took 64922 ms для чтения 5120 MB с размером лотка 512 KB

Получило 66312 мс на чтение 5120 МБ с размером лотка 1024 KB

Получило 68688 мс на чтение 5120 МБ с размером лотка 2048 KB

Получило 64922 мс на чтение 5120 МБ с размером лотка 4096 KB

Получило 66047 мс на чтение 5120 МБ с размером лотка 8192 KB

DISK WRITER: -

Запись на RAID 5 с NO_BUFFERING & WRITE_THROUGH

Запись 2048MB (2GB) данных размером 4MB заняла 68328мс.

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

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

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

Запись на RAID 5 с NO_BUFFERING

Запись 2048MB (2GB) данных с размером куска 4MB заняла 57484мс.

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

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

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

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

BLITZ COPY:-

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

Time Taken to complete copy : 2236735 мс. Т.е. 37,2 мин. Скорость ~ 97 Гб/ч.

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

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

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

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

100 Мбит/с NIC : Блиц-копирование и робокопирование выполняют @ ~ 30 ГБ в час.

1 Гб в секунду NIC : Блиц-копия идет @ ~ 97 Гб в час, а робокопия @ ~ 50 Гб в час.