Файлы с отображенной памятью вызывают недостаток физической памяти - PullRequest
1 голос
/ 11 мая 2010

У меня 2 ГБ ОЗУ, запущено приложение, интенсивно использующее память, и выполняется переход к состоянию низкой доступной физической памяти, и система не реагирует на действия пользователя, такие как открытие любого приложения или вызов меню и т. Д.

Как мне запустить или сказать системе поменять память на файл подкачки и освободить физическую память? Я использую Windows XP.

Если я запускаю одно и то же приложение на машине с 4 ГБ ОЗУ, это не так, реакция системы хорошая. После удушья доступной физической памяти система автоматически переходит на файл подкачки и освобождает физическую память, не так плохо, как система 2 ГБ.

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

Несмотря на то, что отображенный в память файл не сопоставлен с обрабатываемой виртуальной памятью, системный кэш высок. Зачем???!!! (

Любая помощь приветствуется. Спасибо.

Ответы [ 3 ]

1 голос
/ 12 мая 2010

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

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

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

0 голосов
/ 12 мая 2010

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

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

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

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

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

0 голосов
/ 12 мая 2010

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

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

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

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

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

...