производительность при последовательном доступе к файлу на сетевом сервере после случайного обращения к нему - PullRequest
5 голосов
/ 09 января 2012

Я работаю над собственным приложением C ++ / Win32 / MFC для Windows 7. Я использую CFile, чтобы открыть файл, хранящийся на удаленном сервере (с флагами CFile :: modeRead | CFile :: shareDenyWrite).Сервер работает под управлением Windows Server 2008, и я получаю доступ к файлу на общем диске через обычный общий доступ к файлам Windows.Открывая файл, я читаю его, как описано ниже.

Сначала я ищу несколько мест в файле (10 мест) и читаю небольшие (128 байт) разделы.Затем я начинаю поиск и читаю последовательно весь файл.

Я заметил, что выполнение вышеописанного было НАМНОГО медленнее, чем просто открытие файла и его чтение.Первоначальный случайный поиск и выборка очень быстрые, почти мгновенные даже с большим файлом.Что интересно, хотя это и быстро, следующая часть, сканирование файла очень медленное по сравнению с простым сканированием без первоначального произвольного доступа.

Пытаясь выяснить, что происходит, яподтянул монитор производительности и следил за сетевым трафиком.Если я просто последовательно читаю файл, я получаю 3,5 МБ / с по беспроводному адаптеру.Если я сначала случайно ищу, то при последовательном чтении я получаю только 300 кБ / с во время последовательного чтения.

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

Таким образом, кажется, что чтение с произвольным доступом (поиск и чтение) сделало что-то на сервере, что затем привело к замедлению последовательного чтения.Мне интересно, кто-нибудь знает наверняка, что здесь происходит и какова действительная причина поведения, которое я вижу?Хотя у меня есть решение, я хотел бы лучше понять, что происходит под капотом, чтобы вызвать это.

1 Ответ

7 голосов
/ 09 января 2012

Mooing Duck * Комментарий 1002 * прав. Операционная система запускается, предполагая последовательный доступ в качестве «мягкой» опции - включается до тех пор, пока не будет доказано, что она вредна. Но случайный доступ приводит к ухудшению производительности при опережающем чтении, а «умное» кэширование отключает опережающее чтение.

Можно подумать, что несколько последовательных обращений заставят Windows снова включить его. Но, к сожалению, на этом этапе флаг больше не является «мягким». Windows считает случайный доступ проверенным с тех пор, как если бы вы перевели его в этот режим.

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

...