Блог

У меня есть куча больших файлов, каждый файл может быть более 100 ГБ, общий объем данных может составлять 1 ТБ, и все они доступны только для чтения (просто для случайного чтения).

Моя программа выполняет небольшие операции чтения в этих файлах на компьютере с объемом оперативной памяти около 8 ГБ.

Чтобы повысить производительность (без поиска () и без копирования в буфер), я подумал об использовании сопоставления памяти и, по сути, о сопоставлении с памятью всего 1 ТБ данных.

Хотя на первый взгляд это звучит безумно, поскольку основная память << диск, имея представление о том, как работает виртуальная память, вы должны увидеть, что на 64-битных машинах проблем возникнуть не должно.

Все страницы, прочитанные с диска в ответ на мои read ()-ы, будут считаться «чистыми» в ОС, поскольку эти страницы никогда не перезаписываются. Это означает, что все эти страницы могут напрямую переходить к списку страниц, которые могут использоваться ОС, без обратной записи на диск ИЛИ замены (стирания их). Это означает, что операционная система фактически может хранить в физической памяти только страницы LRU и будет выполнять функцию just reads (), когда страницы нет в основной памяти.

Это означало бы отсутствие подкачки и увеличения ввода-вывода из-за огромного отображения памяти.

Это теория; я ищу любого из вас, кто пробовал или использовал такой подход на практике в производстве и может поделиться своим опытом: есть ли какие-либо практические проблемы с этой стратегией?

То, что вы описываете, верно. В 64-разрядной ОС вы можете сопоставить файлу 1 ТБ адресного пространства и позволить ОС управлять чтением и записью в файл.

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

Не было бы увеличения ввода-вывода только потому, что отображение велико. Это будет зависеть от объема данных, к которым вы фактически получаете доступ. Большинство операционных систем, включая Linux и Windows, имеют унифицированную модель кэша страниц, в которой кэшированные блоки используют те же физические страницы памяти, что и страницы, отображенные в памяти. Я бы не ожидал, что ОС будет использовать больше памяти при отображении памяти, чем при кэшированном вводе-выводе. Вы просто получаете прямой доступ к кэшированным страницам.

Одна из проблем, с которой вы можете столкнуться, связана с удалением измененных данных на диск. Я не уверен, какая политика конкретно установлена в вашей ОС, но время между изменением страницы и тем, когда ОС действительно запишет эти данные на диск, может быть намного больше, чем вы ожидаете. Используйте flush API для принудительной записи данных на диск, если важно, чтобы они были записаны к определенному времени.

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