Необходим быстрый доступ к файлам

Question

Я хочу, чтобы мой код обрабатывал файл очень быстро. Этот размер файла будет варьироваться от одного КБ до даже 2 ГБ.

Даже я готов создать отдельную файловую систему для этого отдельного файла.

Я разделю файл на блоки постоянного размера (вероятно, 8 КБ) и получу доступ к нему для чтения и записи данных. Что касается кода, алгоритм не может быть изменен, поскольку он дает хорошую производительность, а также стабильную. поэтому я не хочу меняться Я также использую mmap () для отображения блоков в память по требованию.

Можно ли получить файловую систему в виде одного блока, чтобы операции доступа к файлу, чтения и записи могли выполняться быстрее?

Пожалуйста, дайте все ваши предложения, даже небольшая вещь, которая поможет мне.

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

Спасибо, Naga

Answer 1

Общие, ОС независимые общие правила:

• Используйте физические чтения (а не потоки)

• Используйте большие буферы ввода / вывода для чтения. Инициализация операции ввода / вывода (и синхронизация с вращающимся оборудованием) требует больших затрат времени. Несколько маленьких чтений занимают больше времени, чем большое.

• Создайте тест для определения наиболее эффективного размера буфера. После заданного размера эффективность не улучшится, и вы не захотите тратить всю свою драгоценную оперативную память без необходимости. Оптимальный размер буфера зависит от вашего оборудования и ОС. На современном оборудовании обычно достаточно эффективно использовать размеры буферов в диапазоне от 500 КБ до 1 МБ.

• Минимизирует поиск головки диска. То есть если вам нужно записать данные обратно, чередование чтения / записи может быть очень дорогостоящим, если они находятся на одном физическом диске.

• если вам нужно выполнить значительную обработку, используйте двойную буферизацию и асинхронный ввод-вывод для перекрытия ввода-вывода и обработки.

Answer 2

Windows позволяет открыть раздел для необработанных чтений и записей. Это также позволит вам открыть физическое устройство для необработанного ввода-вывода. Поэтому, если вы хотите рассматривать жесткий диск или раздел как один файл, вам будет гарантировано, что «файл» логически непрерывен на диске. (Из-за способа, которым жесткие диски исправляют неисправные сектора, на самом деле он не может быть физически непрерывным).

Если вы решите использовать raw io, вам придется читать и записывать кратно размеру блока устройства. Обычно это 512 байт, но, вероятно, было бы разумнее использовать 4k в качестве размера вашего блока, так как это то, что используют более новые диски, и это размер страницы для Win32.

Чтобы открыть раздел для необработанных чтений, вы используете CreateFile с именем файла "\. \ X:", где X: буква диска раздела. См. Документацию CreateFile под заголовком Физические диски и тома

.

С другой стороны, довольно сложно превзойти производительность отображаемых в памяти файлов, см. Этот вопрос для примера. Как сканировать действительно огромные файлы на диске?

Answer 3

Всегда старайтесь обращаться к вашему файлу последовательно, в блоках 64 КБ-1 МБ. Таким образом, вы можете воспользоваться преимуществами предварительной выборки и максимально увеличить объем данных на одну операцию ввода-вывода.

Кроме того, постарайтесь сначала убедиться, что файл является смежным, чтобы головке диска не приходилось много перемещаться между последовательными чтениями. Многие файловые системы создадут файл как можно более смежным, если вы начнете с установки конца файла или выполнения write() всего файла за один раз. В Windows вы можете использовать утилиту sysinternals.com contig.exe, чтобы создать непрерывный файл.

Answer 4

mmap или MapViewOfFile позволяют получать доступ к файлам непосредственно в памяти. ОС будет прозрачно отображать ошибки на страницах по мере необходимости или, возможно, даже читать вперед (на что можно указать с помощью madvise или FILE_FLAG_*). В зависимости от шаблона доступа и размера файлов это может быть заметно быстрее, чем при обычном чтении / записи файлов.

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