Файлы с отображением памяти вызывают нехватку физической памяти

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

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

Даже если вы не можете избавиться от необходимости в полном произвольном доступе ко всему диапазону базового файла, все же может быть полезно удалить и воссоздать представление по мере необходимости, чтобы переместить представление в раздел файла, который следующая операция требует доступа. Если ваши шаблоны доступа к данным, как правило, группируются вокруг частей файла, прежде чем двигаться дальше, вам не нужно перемещать представление так часто. Вам потребуется удалить и воссоздать объект представления, но, поскольку при разрыве представления также освобождаются все кэшированные страницы, связанные с представлением, похоже, что вы увидите чистый выигрыш в производительности, потому что представление меньшего размера значительно уменьшает нехватка памяти и подкачка страниц в масштабе всей системы. Попробуйте установить размер представления на основе части установленной системной ОЗУ и переместите представление по мере необходимости при обработке файла. Чем больше вид, тем меньше вам нужно его перемещать, но тем больше оперативной памяти он потребляет, что может повлиять на скорость отклика системы.

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

Очевидное решение (и, возможно, непрактичное) - использовать меньше памяти в вашем приложении. Я предполагаю, что это не вариант или, по крайней мере, не простой вариант. Альтернативой является попытка упреждающего сброса данных на диск, чтобы постоянно сохранять доступную физическую память для запуска других приложений. Общий объем памяти на компьютере можно узнать с помощью GlobalMemoryStatusEx. И GetProcessMemoryInfo вернет текущую информацию об использовании памяти вашим собственным приложением. Поскольку вы говорите, что используете файл с отображением памяти, вам может потребоваться дополнительно учесть это. Например, я считаю, что информация PageFileUsage, возвращаемая этим API, не будет включать информацию о вашем собственном файле с отображением памяти.

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

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

Изменить: это еще одно очевидное утверждение, но я забыл упомянуть его ранее. Это также может быть непрактичным для вас, но похоже, что одна из лучших вещей, которые вы могли бы сделать, учитывая, что вы работаете с 32-разрядными ограничениями, - это создать свое приложение как 64-разрядное и запустить его в 64-разрядной ОС ( и закинуть на машину еще чуть-чуть памяти).

Что ж, похоже, вашей программе требуется более 2 ГБ рабочего набора.

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

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

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

Я предлагаю попытаться уменьшить объем памяти, необходимый для вашей программы, и посмотреть, можно ли увеличить локальность ссылок, чтобы уменьшить объем необходимой подкачки.