О каких подводных камнях следует опасаться при отображении памяти в БОЛЬШИХ файлах? - PullRequest
4 голосов
/ 24 мая 2011

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

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

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

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

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

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

1 Ответ

3 голосов
/ 23 сентября 2011

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

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

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

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

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

...