Использует ли boost managed_mapped_file мою физическую память? [Дубликат]

Question

Использует ли boost managed_mapped_file мою физическую память? [Дубликат]

0

Я хочу сопоставить файл (512 М) с общей памятью, чтобы каждый процесс мог получить к нему доступ. И я выбираю boost :: interprocess :: managed_mapped_file.

Я думаю, что общая память не должна воспринимать real память, поскольку она разделяется несколькими процессами. Но когда я запускаю свою программу, кажется, что каждый процесс использует 512M памяти. И не хватает памяти для 20 процессов.

Итак, почему boost :: interprocess :: managed_mapped_file принимает реальную память, а не виртуальную память?

amazingjxq 04 дек. 2014, в 16:56

Источник

0

Просто попробуйте. Я думаю, что вы ошиблись набором virt с зарезервированным / совершенным набором.
sehe 04 дек. 2014, в 16:33
0

Да, он использует вашу физическую память, но только столько, сколько доступно. В противном случае незаблокированные страницы (которые могут быть всеми ими) будут выгружены из физической памяти. Конечно, страницы будут по-прежнему отображаться в вашем виртуальном адресном пространстве, пока вы не удалите их. Замена грязных страниц требует записи, а замена страниц требует чтения, поэтому слишком мало физических страниц, доступных для «возврата» виртуального сопоставления файлов, может привести к очень плохой производительности.
sehe 04 дек. 2014, в 17:40

Теги:

c++

linux

boost

memory

mmap

1 ответ

Ещё вопросы

Просто попробуйте. Я думаю, что вы ошиблись набором virt с зарезервированным / совершенным набором.
Да, он использует вашу физическую память, но только столько, сколько доступно. В противном случае незаблокированные страницы (которые могут быть всеми ими) будут выгружены из физической памяти. Конечно, страницы будут по-прежнему отображаться в вашем виртуальном адресном пространстве, пока вы не удалите их. Замена грязных страниц требует записи, а замена страниц требует чтения, поэтому слишком мало физических страниц, доступных для «возврата» виртуального сопоставления файлов, может привести к очень плохой производительности.

Mike Seymour · Answer 1 · 2014-12-04T14-32-00.000Z

Я думаю, что общая память не должна принимать реальную память

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

кажется, что каждый процесс использовал 512 М памяти

Каждый из них будет иметь 512M разделяемой памяти, отображаемой в его виртуальное адресное пространство; по-видимому, то, что вы видите. Каждому отображению будет 512 МБ физической памяти.

И не хватает памяти для 20 процессов.

Вы говорите, что на самом деле у вас закончилась физическая память, как будто каждый процесс выделил 512M? Если каждый процесс принимает физическую память для себя, а не делится ею, то что-то происходит неправильно, когда вы создаете и обмениваетесь виртуальной памятью. Нам нужно будет понять, как вы это делаете, чтобы угадать, что может быть неправильным.

Нет, вам понадобится 512M «реальной» памяти - это не точно. Это требуется только в том случае, если вы используете VirtualLock или помните их
@sehe: Действительно, я немного ослабил свой язык и надеялся, что значение будет достаточно ясным. Под «вам понадобится реальная память», я имел в виду «вам понадобятся страницы, выделенные для той части памяти, которая используется, каждая из которых будет нуждаться в физической памяти в момент обращения к ней».
Дело в том, что вам нужно всего лишь сказать пару страниц (давайте возьмем 40 КБ), чтобы с пользой отобразить файл размером 21 ГБ. (Остальные будут просто заменены в зависимости от блокировки LRU)
@sehe: Хорошо, мы используем слово «реальный» для обозначения разных вещей. Надеюсь, я прояснил ответ достаточно, не требуя слишком много лекции по управлению памятью. Не стесняйтесь писать свои собственные, если вы не думаете, что это имеет достаточный уровень педантизма.
@sehe 40k может быть недостаточно для того, чтобы с пользой отобразить файл размером 21 ГБ, подумайте о базе данных, которую совместно используют 20 процессов, обслуживающих запросы в реальном времени, - это было бы очевидным случаем, когда обмен дешевой памяти на более низкие задержки - отличный компромисс.