Замедление при копировании огромных (120 + ГБ) файлов

У меня есть приложение C#, и я использую класс FileStream для чтения 120-гигабайтного файла с * EDIT * isilon storage unit (отображается на z-диск) по гигабитной локальной сети. Я начинаю с скорости чтения со скоростью 45 мегабайт в секунду, но примерно в диапазоне 20 ГБ скорость чтения резко падает и оседает примерно до 9 мегабайт в секунду. Кто-нибудь есть идеи о том, что может вызвать замедление?Замедление при копировании огромных (120 + ГБ) файлов

Сервер Windows Server 2008 Enterprise R2 64-разрядная, 16 ГБ оперативная память, двухъядерный четырехъядерный процессор и мое приложение - это консольное приложение на платформе .NET Framework 4.0. Вот мой код:

 byte[] buffer = new byte[16777216]; 
     int count; 
     long totalBytes = 0; 
     FileStream file = File.OpenRead("z:\bigfile.dat"); 
     while ((count = file.Read(buffer, 0, buffer.Length)) > 0) 
     { 
      // I track megabyte/second here 
      totalBytes += count; 
     }

источник

2010-09-08 jjxtra

Смотрите, если же код имеет замедление в Mono, так вы знаете, если проблема с NTFS (и у меня такое ощущение, что это так) – alternative

Дефрагментация диска в любом случае. –

Это просто ОС с чашкой чая. Будь как будет. – slugster

Оказывается, я был фактически просматривая сеть. Я думал, что мой подключенный диск был локальным, но это не так. У меня все еще есть проблема при чтении по сети, но когда я сейчас действительно читаю файл с локального диска, скорость - это то, что я ожидаю. Всем спасибо.

EDIT Я исправил проблему при чтении по сети. Вы можете создать FileStream, который не использует кэш окна с этим кодом:

FileStream file = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.None, bufferSize, (FileOptions)0x20000000);

0x20000000 является флагом, который не имеет перечисления в рамках .NET, но она в основном говорит, чтобы не использовать кэш ,

http://msdn.microsoft.com/en-us/library/cc644950%28v=VS.85%29.aspx

источник

2010-09-08 14:37:46 jjxtra

Ну, это зависит от того, как вы управляете потоком. Вы читаете, пишите в новый файл, очищаете буфер? Потому что RAM, очевидно, не может хранить в нем 120 ГБ.

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

источник

2010-09-08 00:58:34 user441940

Это действительно все, что я есть, я не пишу никаких данных, я просто читаю их, сохраняю все прочитанные байты, а затем бросаю байты в сборщик мусора ... – jjxtra

Интересно, если сам цикл удерживает GC от сбора мусора, сгенерированного в цикле. Существует a Microsoft KB article, описывающий ситуацию для однопоточного консольного приложения. Я бы предложил добавить [MTAThread] к основному методу, как это предлагается в статье.

источник

2010-09-08 00:59:52 tia

Что было бы наиболее интересным, так это узнать, делает ли CopyFile то же самое. Не видя остальной части кода, сказать довольно сложно. Один из них не очень-то необычный, что случается с людьми, заключается в том, что они заполняют системный кеш грязными данными, поэтому он кричит какое-то время (просто делает кучу кэшированных ввода-вывода), а затем значительно замедляется, когда начинается запись. Вот когда вы узнаете, насколько быстро реализована ваша копия ... Тот факт, что он начинает идти на юг, когда размер находится в приблизительном размере объема ОЗУ машины, - довольно интересный намек ...

источник

2010-09-08 01:25:22 jrtipton

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

Посмотрите на метод BeginRead ...

источник

2010-09-08 17:22:20 stevenrcfox

Замедление при копировании огромных (120 + ГБ) файлов

ответ

Смежные вопросы