Предел Памяти процесса 64-разрядного процесса
У меня в настоящее время есть 32-разрядное приложение .NET (на x86 Windows), которые требуют большой памяти. Недавно это начало бросать Систему. OutOfMemoryException.
Так, я планирую переместить его в x64 платформу как 64-разрядный процесс. Так будет эта справка с из исключений памяти. Я читал эту статью из пределов Памяти MSDN для Windows
Так, мой вопрос состоит в том, если я скомпилирую приложение .NET на 64 бита, то он будет иметь IMAGE_FILE_LARGE_ADDRESS_AWARE установленным по умолчанию (Как статья предполагает)? т.е. я буду в состоянии использовать в своих интересах виртуальное адресное пространство непривилегированного режима на 8 ГБ?
5 ответов
Максимальный предел памяти для процессов x64 составляет 8 ТБ, но практический предел намного меньше, поскольку он зависит от объема физической памяти и размера файла подкачки на ваша система. См. этот пост для более подробной информации.
IMAGE_FILE_LARGE_ADDRESS_AWARE влияет на процесс x86, запущенный в ОС x64 (или ОС x86 с директивой / 3GB). Вашему x64-приложению не нужно устанавливать флаг с учетом большого адреса, и оно сможет использовать всю доступную виртуальную память в вашей системе.
Вообще-то, в той статье говорится, что у вас будет доступ к 8 ТБ виртуального адресного пространства (и да, это правда).
На самом деле в ОС x64, если ваше приложение скомпилировано для AnyCPU, вам не нужно делать ничего особенного. JIT создаст образ x64 во время выполнения или образ x86 при запуске в 32-битной системе.
Переход на 64-битную версию определенно помогает исключить OutOfMemoryExceptions, но вы можете сосредоточиться на архитектуре вашей системы и механизмах кодирования, чтобы избежать этого, поскольку это только Будет вопросом времени, когда они появятся и на 64-битной машине.
Еще одно преимущество перехода на 64-битные машины заключается в том, что при виртуальном адресном пространстве 8 ТБ сборка мусора для .NET происходит нечасто. Это действительно улучшает производительность приложения за счет увеличения доступного виртуального пространства для вашей программы.
IMAGE_FILE_LARGE_ADDRESS_AWARE актуален только для 32-битных процессов. Причина в том, что адресное пространство в 32-битной Windows разделено на две части: 2 ГБ для пространства ядра и 2 ГБ для пользовательского пространства. Для адресации 2 ГБ вам понадобится 31 бит. Т.е. указателям в 32-битном приложении не нужен последний бит для адресации.
Некоторые приложения могли использовать этот дополнительный бит для специальных целей, поэтому, если диспетчер памяти Windows внезапно передаст им настоящий 32-битный адрес, они не смогут с этим справиться. Включив флаг IMAGE_FILE_LARGE_ADDRESS_AWARE , приложение в основном сообщает ОС, что оно может обрабатывать все 32-битное адресное пространство.
Если вы запустите приложение IMAGE_FILE_LARGE_ADDRESS_AWARE в 32-битной Windows, вы можете получить доступ к 3 ГБ. Если вы запустите то же 32-битное приложение в 64-битной Windows, процесс фактически получит все 4 ГБ адресного пространства.
Если вы запускаете 64-битное приложение в 64-битной Windows, адресное пространство пользователя составляет 8 ТБ (еще 8 ТБ отведено под адресное пространство ядра). Приложения .NET, для которых установлено значение AnyCPU, автоматически станут 64-битными приложениями на x64, поэтому вам не нужно ничего делать для обращения к дополнительной памяти.
Однако имейте в виду, что среда CLR налагает ограничение на 2 ГБ для любого отдельного объекта, поэтому, хотя ваше приложение может использовать много памяти, вы не можете создать, например, массив 2 ТБ. Дополнительная информация в этом вопросе: Размер отдельных объектов по-прежнему ограничен 2 ГБ в CLR 4.0?