Чтение файла по сети медленное из-за дополнительных чтений

Question

Я читаю файл, и я либо читаю строку данных (1600 последовательных чтений из 17 байт), либо столбец данных (1600 прочтений из 17 байт, разделенных 1600 * 17 = 27,200 байт). Файл находится либо на локальном диске, либо на удаленном диске. Я читаю 10 раз, поэтому в каждом случае я ожидаю читать 272 000 байт данных.

На локальном диске я вижу то, что ожидаю. На удаленном диске при чтении последовательно я также вижу то, что ожидаю, но при чтении столбца я вижу тонну дополнительных чтений. Они имеют длину 32 768 байт и, похоже, не используются, но они делают сканирование количества данных с 272 000 байт в любом месте от 79 МБ до 106 МБ. Вот вывод с помощью Process Monitor:

 
1:39:39.4624488 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,390,069, Length: 17 
1:39:39.4624639 PM DiskSpeedTest.exe 89628 FASTIO_CHECK_IF_POSSIBLE \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Operation: Read, Offset: 9,390,069, Length: 17 
1:39:39.4624838 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,388,032, Length: 32,768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal 
1:39:39.4633839 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,417,269, Length: 17 
1:39:39.4634002 PM DiskSpeedTest.exe 89628 FASTIO_CHECK_IF_POSSIBLE \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Operation: Read, Offset: 9,417,269, Length: 17 
1:39:39.4634178 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,444,469, Length: 17 
1:39:39.4634324 PM DiskSpeedTest.exe 89628 FASTIO_CHECK_IF_POSSIBLE \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Operation: Read, Offset: 9,444,469, Length: 17 
1:39:39.4634529 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,441,280, Length: 32,768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal 
1:39:39.4642199 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,471,669, Length: 17 
1:39:39.4642396 PM DiskSpeedTest.exe 89628 FASTIO_CHECK_IF_POSSIBLE \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Operation: Read, Offset: 9,471,669, Length: 17 
1:39:39.4642582 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,498,869, Length: 17 
1:39:39.4642764 PM DiskSpeedTest.exe 89628 FASTIO_CHECK_IF_POSSIBLE \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Operation: Read, Offset: 9,498,869, Length: 17 
1:39:39.4642922 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,498,624, Length: 32,768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal 

Обратите внимание на дополнительные считываний 32768 с I/O устанавливаются флаги не-кэшируются, Paging I/O, Синхронный Paging I/O, Priority: Normal. Эти дополнительные чтения - это то, что занимает от 272 КБ до 106 МБ и вызывает медленность. Они не происходят при чтении из локального файла, или если я читаю строку, так что это все последовательное.

Я попытался установить FILE_FLAG_RANDOM_ACCESS, но он, похоже, не помогает. Любые идеи о том, что вызывает эти дополнительные чтения и как их остановить?

Тесты выполняются на 64-битной системе Vista. Я могу предоставить исходный код для программы, чтобы продемонстрировать проблему, а также консольную программу, которая выполняет тесты.

Answer 1

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

Я не уверен, есть ли способ просто потянуть весь файл, прочитать строки из этого файла в локальной копии, а затем отбросить изменения или нет.

Вы прочитаете некоторые кошмары о oplocks и базах данных с плоскими файлами.

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

Не уверен, если это решит вашу проблему, но это может заставить вас в правильном направлении. Удачи!

Answer 2

Я вижу это все время, и это не под вашим контролем: сеть делает то, что хочет.

Если вы знаете, что файл будет меньше 1 МБ, просто потяните все это в память.

Answer 3

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

Отметьте caching behavoir раздел API CreateFile.

Возможно, вы захотите попробовать 'FILE_FLAG_NO_BUFFERING', чтобы проверить, не прекращает ли он лишние чтения. Будьте осторожны, использование этого флага может замедлить ваше приложение. Обычно вы используете этот флаг, если вы понимаете, как быстро передавать данные с диска, и кэширование ОС только мешает.

Также вы можете получить такое же поведение, как сетевой файл с локальными файлами, если используете флаг FILE_FLAG_SEQUENTIAL_SCAN. Этот флаг указывает на диспетчер кэша Windows, что вы будете делать, и попытается получить данные за вас досрочно.

Answer 4

Я думаю, что SMB всегда передает блок, а не небольшой набор байтов.

Информацию о согласовании размера блока можно найти здесь. http://support.microsoft.com/kb/q223140

Итак, вы видите прочитанное, чтобы скопировать соответствующий блок, за которым следуют локальные чтения (ов) из 17 байтов в блоке. (Если вы посмотрите на шаблон, есть несколько пар из 17 байтов, где два чтения попадают в один и тот же блок).

Исправление, очевидно, зависит от элемента управления, который у вас есть над приложением, а также от размера и структуры базы данных. (например, если в базе данных был один столбец на каждый файл, тогда все чтения будут последовательными. Если вы использовали сервер базы данных, вы не будете использовать SMB и т. д.)

Если это утешение, iTunes performs abysmally when using a network drive too.

Answer 5

Я нашел ответ на этот вопрос. Windows делает чтение файлов через кеш страниц, поэтому, когда я читаю 17 байтов, сначала нужно перенести полную страницу с 32 КБ, а затем можно скопировать 17 байтов, которые я хочу из кеша страниц. Неприятный результат по производительности!

То же самое происходит в первый раз, когда чтение выполняется в локальном файле, так как в этом случае он все равно загружает полную страницу за раз в кеш страницы. Но во второй раз, когда я запускаю тест локально, все файлы уже находятся в кэше страниц, поэтому я не вижу его. И если SuperFetch включен, и я делал эти тесты некоторое время, Windows начнет загружать файл в кеш до Я даже запускаю свое тестовое приложение, так что я снова не вижу, как читается страница.

Таким образом, операционная система делает много вещей за кулисами, что затрудняет хорошее тестирование производительности!