При копировании больших файлов в среде WINDOWS (число файлов мало <15, а их суммарный объем в разы превышает объем оперативной памяти хоста куда происходит копирование) вот уже несколько лет наблюдаю следующую картину:
Например, копируем с того хоста куда идет копирование один 90Гб-й файл, т.е. диск куда сохраняются файлы при копировании расположен на той же машине - которая выполняет операции копирование файлов с удаленного хосте по сети. Сетевые интерфейсы при этом подняты со скоростью по 1Gb/s и ещё объединены в Teaming по 2 в основном по LACP в режиме Round Robin.
Машина куда сохраняются файлы некоторое время с большой скоростью принимает их, примерно до того момента, как создается ощущение, что пока не заполниться кэш оперативной памяти под дисковое копирование, а после этого начинается резкое замедление - поскольку этот самый "кэш" начинает сбрасывать данные на диск и резко замедляет скорость забора данных с сетевого источника, о чем свидетельствует наблюдение за сетевой нагрузкой (Windows Task Manager->Networking).
На рисунке приведено поведение при использовании eseutil.exe
После чего счетчик копирования в виндовом окошке копирования начинает резко давить на нервы админов увеличение времени, почти в двое.
Иногда есть возможность отключить кэширование записи на диск, делается это в "Диспетчере устройств"(devmgmt.msc)->"Дисковые устройства"->свойства диска->вкладка "Политика":
но у некоторых подключенных дисковых устройств (у самого нужного сервера) такой возможности нету, например СХД EMC CLARiiON CX4-120:
а у некоторых есть, например HP EVA4000:
Есть альтернативные методы копирования - в частности средством eseutil.exe, которая обычно входит в состав Exchange и служит для дефрагментации почтовых баз. Взять дистрибутив можно здесь.
Фактически нужно только два файла eseutil.exe и ese.dll
синтаксис команды:
eseutil.exe /y {source-file} /d {destination-file}
В моем случае упирались в производительность дисковой подсистемы
, а средствами винды вообще не могли нормально скопировать только теряли время - несколько часов, были ошибки вида:
на Win2003:
"Cannot copy
на Win2008:
"An unexpected error is keeping you from copying the file. If you continue to receive this error, you can use the error code to search for help with this problem. Error 0x8007046A:Not enough server storage is available to proceed this command"
После использования eseutil, смогли начать копирование. Индикация процесса копирования происходит так же, как при дефрагментации баз:
Ощющение что с ней происходит всё быстрее и надежнее не покидало. Скорее всего это происходит из-за того что eseutil принудительно сбрасывает "кэш" копирования на диск по каким-то условиям.
Но и в этом случае eseutil не помогла...
Иногда никак не получается скопировать, так eseutil где-то на 95-98% копирования может выдать ошибку вида:
FAILURE: GetOverlappedResult (read): Not enough server storage is available to process this command.
где-нибудь в конце 90Гбайтного файла.
Тогда есть вариант поделить файл (WinRAR, 7zip, GNU SPLIT) и копировать по частям, а потом эти части собрать (copy, 7zip).
Когда ничего не помогает - как было в моем случае - заливаем бэкап на другой диск и форматим сбойный.
Есть ещё варианты с поднятием ftp-сервера на источнике и докачкой на приемнике. в общем случае - это через другие - протоколы - не SMB: fpt, p2p(torrent например)
либо пользоваться утилитами, позволяющими прерывать копирование по сети (SMB) и продолжать с места остановки, например "CopyFile 2", KillCopy, Real Total Copy и т.п.
В нашем случае смогли скопировать файл только после перезагрузки обоих серверов и на другой диск средствами обычного виндового копирования.
Похоже что реальная причина была в отключенном кэше на дисковом сторадже, и луны задыхались от нехватки производительности.
ссылки по теме:
http://blogs.technet.com/b/askperf/archive/2007/05/08/slow-large-file-copy-issues.aspx
http://support.microsoft.com/kb/198386/
http://support.microsoft.com/kb/106167
http://support.microsoft.com/kb/332023/ru
Комментариев нет:
Отправить комментарий