Файлы с отображенной памятью вызывают недостаток физической памяти
У меня 2 ГБ ОЗУ, запущено приложение, интенсивно использующее память, и происходит переход в состояние низкой доступной физической памяти, и система не реагирует на действия пользователя, такие как открытие любого приложения или вызов меню и т. Д.
Как мне запустить или сказать системе поменять память на файл подкачки и освободить физическую память? Я использую Windows XP.
Если я запускаю одно и то же приложение на машине с 4 ГБ ОЗУ, это не так, реакция системы хорошая. После удушья доступной физической памяти система автоматически переходит на файл подкачки и освобождает физическую память, не так плохо, как система 2 ГБ.
Чтобы преодолеть эту проблему (на машине 2 ГБ), попытался использовать файлы отображения памяти для большого набора данных, которые выделяются приложением. В этом случае виртуальная память приложения (процесса) в порядке, но системный кэш высок, и проблема та же, что и выше, в том, что физическая память меньше.
Несмотря на то, что отображенный в память файл не сопоставлен с обрабатываемой виртуальной памятью, системный кэш высок. Зачем???!!!:(
Любая помощь приветствуется. Благодарю.
3 ответа
Если ваш шаблон доступа к данным для использования файла с отображенной памятью является последовательным, вы могли бы немного улучшить рециркуляцию страниц, указав флаг FILE_FLAG_SEQUENTIAL_SCAN при открытии базового файла. Если ваш шаблон данных обращается к отображенному файлу в случайном порядке, это не поможет.
Вы должны рассмотреть вопрос об уменьшении размера вашей карты. Вот где вся память фактически потребляется и кешируется. Так как кажется, что вам нужно обрабатывать файлы, размер которых превышает доступную непрерывную свободную физическую память, вы, вероятно, можете лучше справиться с управлением памятью, чем подкачка страниц виртуальной памяти, поскольку вы знаете больше о том, как вы используете память, чем виртуальную менеджер памяти делает. Если это вообще возможно, попробуйте настроить свой дизайн так, чтобы вы могли работать с частями большого файла, используя уменьшенный вид.
Даже если вы не можете избавиться от необходимости полного произвольного доступа ко всему диапазону базового файла, все равно может быть полезно разорвать и воссоздать представление по мере необходимости, чтобы переместить представление в раздел файла, который Следующая операция должна получить доступ. Если ваши шаблоны доступа к данным имеют тенденцию кластеризоваться вокруг частей файла, прежде чем двигаться дальше, вам не нужно будет перемещать представление так часто. Вы попытаетесь разрушить и воссоздать объект представления, но, поскольку разделение представления также освобождает все кэшированные страницы, связанные с представлением, вероятно, вы увидите чистый выигрыш в производительности, поскольку уменьшенное представление значительно уменьшает Давление памяти и система подкачки всей системы. Попробуйте установить размер представления на основе части установленной системной оперативной памяти и переместите представление в соответствии с требованиями обработки файлов. Чем больше изображение, тем меньше вам нужно будет его перемещать, но чем больше ОЗУ будет потребляться, тем самым потенциально влияя на быстродействие системы.
Как я думаю, вы намекаете в своем посте, медленное время отклика, вероятно, по крайней мере частично из-за задержек в системе, в то время как ОС записывает содержимое памяти в файл подкачки, чтобы освободить место для других процессов в физической памяти.
Очевидное решение (и, возможно, не практичное) состоит в том, чтобы использовать меньше памяти в вашем приложении. Я предполагаю, что это не вариант или, по крайней мере, не простой вариант. Альтернатива состоит в том, чтобы попытаться активно сбрасывать данные на диск, чтобы постоянно поддерживать доступную физическую память для запуска других приложений. Вы можете найти общий объем памяти на машине с GlobalMemoryStatusEx. А GetProcessMemoryInfo будет возвращать текущую информацию об использовании памяти вашим собственным приложением. Поскольку вы говорите, что используете файл с отображением памяти, вам, возможно, придется учесть это дополнительно. Например, я считаю, PageFileUsage информация, возвращаемая этим API, не будет включать информацию о вашем собственном файле отображения памяти.
Если ваше приложение отслеживает использование, вы можете использовать FlushViewOfFile для принудительной принудительной принудительной загрузки данных на диск из памяти. Существует также API (EmptyWorkingSet), который, я думаю, пытается записать как можно больше грязных страниц на диск, но кажется, что это очень сильно повредит производительности вашего собственного приложения. Хотя это может быть полезно в ситуации, когда вы знаете, что ваше приложение переходит в некое состояние ожидания.
И, наконец, еще одним API, который может быть полезен, является SetProcessWorkingSetSizeEx. Вы можете рассмотреть возможность использования этого API, чтобы дать подсказку о верхнем пределе размера рабочего набора вашего приложения. Это может помочь сохранить больше памяти для других приложений.
Изменить: Это еще одно очевидное утверждение, но я забыл упомянуть об этом ранее. Это также может быть непрактичным для вас, но, похоже, одна из лучших вещей, которую вы можете сделать, учитывая, что у вас 32-битные ограничения, - это создать приложение как 64-битное и запустить его на 64-битной ОС (и кидай чуть больше памяти на машину).
Что ж, похоже, вашей программе требуется более 2 ГБ рабочего набора.
Современные операционные системы спроектированы так, чтобы постоянно использовать большую часть оперативной памяти для чего-то, оставляя лишь небольшое количество свободного места, чтобы его можно было немедленно передать процессам, которые нуждаются в большем количестве. Остальное используется для хранения страниц памяти и блоков кэшированных дисков, которые использовались недавно; все, что не было использовано недавно, сбрасывается на диск для пополнения пула свободных страниц. Короче говоря, не должно быть много свободной физической памяти.
Принципиальное различие между использованием обычного выделения памяти и отображением памяти в файлах заключается в том, где данные сохраняются, когда они должны быть выгружены из памяти. Это не обязательно влияет на то, когда память будет выгружена, и мало повлияет на время, необходимое для ее извлечения.
Реальная проблема, которую вы видите, вероятно, не в том, что у вас слишком мало свободной физической памяти, а в том, что скорость подкачки слишком высока.
Мое предложение будет заключаться в том, чтобы попытаться уменьшить объем памяти, необходимый вашей программе, и посмотреть, сможете ли вы увеличить местность ссылок, чтобы уменьшить объем необходимой подкачки.