Максимально достижимая .NET память? - PullRequest
13 голосов
/ 04 апреля 2009

Какой максимальный объем памяти можно получить в управляемом коде .NET? Зависит ли это от реальной архитектуры (32/64 бита)?

Ответы [ 9 ]

11 голосов
/ 04 апреля 2009

Точного и точного значения для кода .NET нет.

Если вы работаете в 32-битной Windows; ваш процесс может адресовать до 2 ГБ, 3 ГБ, если в Windows Server 2003 используется ключ / 3GB.

Если вы запускаете 64-битный процесс в 64-битном боксе, ваш процесс может адресовать до 8 ТБ адресного пространства, если имеется столько ОЗУ.

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

7 голосов
/ 04 апреля 2009

Объем памяти, который может обрабатывать ваш .NET-процесс, зависит как от того, работает ли он на 32/64-битной машине, так и от того, работает ли он как независимый от ЦП или специфичный для ЦП процесс.

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

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

  • 32-битный процесс может адресовать 2 ГБ
  • 64-битный процесс может адресовать 8 ТБ

Вот ссылка на полную разбивку адресуемого пространства, основанную на различных опциях, предоставляемых Windows.

http://msdn.microsoft.com/en-us/library/aa366778.aspx

7 голосов
/ 04 апреля 2009

В C # 2.0 и 3.0 также существует ограничение в 2G на размер одного объекта в управляемом коде.

5 голосов
/ 16 декабря 2009

Недавно я проводил обширное профилирование по ограничениям памяти в .NET для 32-битного процесса. Мы все засыпаем идеей, что мы можем выделить до 2,4 ГБ (2 ^ 31) в приложении .NET, но, к сожалению, это не так :(. Процесс приложения имеет так много места для использования, и операционная система делает большие Тем не менее, для нашей работы, связанной с управлением ею, сама .NET, похоже, имеет свои собственные издержки, которые составляют примерно 600–800 МБ для типичных реальных приложений, которые увеличивают ограничение памяти. 1,4 ГБ, следует ожидать появления исключения OutOfMemoryException ().

Очевидно, что в 64-битной версии это ограничение наступает гораздо позже (давайте поговорим через 5 лет :)), но общий размер всего в памяти также увеличивается (я нахожу, что это ~ 1,7-2 раза) из-за увеличенного размера слова .

Что я точно знаю, так это то, что идея виртуальной памяти из операционной системы определенно НЕ дает вам практически бесконечное пространство для выделения в одном процессе. Только в этом случае все 2,4 ГБ памяти можно адресовать всем (многим) приложениям, работающим одновременно.

Надеюсь, это понимание поможет.

Я первоначально ответил на что-то связанное здесь (я все еще новичок, поэтому не уверен, как я должен делать эти ссылки):

Есть ли ограничение памяти для одного процесса .NET

5 голосов
/ 04 апреля 2009

Для 64-битной Windows размер виртуальной памяти составляет 16 ТБ, поровну разделенных между режимами пользователя и ядра, поэтому пользовательские процессы могут адресовать 8 ТБ (8192 ГБ). Это меньше, чем все 16 EB пространство, адресуемое 64 битами, но это все же намного больше, чем мы привыкли с 32 битами.

3 голосов
/ 04 апреля 2009

Среда выполнения .NET может выделять всю свободную память, доступную для программ пользовательского режима на своем хосте. Имейте в виду, что это не означает, что вся эта память будет выделена для вашей программы, так как некоторые (относительно небольшие) части будут выделены для внутренних структур данных CLR. В 32-разрядных системах, при условии установки 4 ГБ или более (даже если включен PAE), вы сможете получить примерно 2 ГБ, выделенных для вашего приложения. На 64-битных системах вы должны получить 1 ТБ. Для получения дополнительной информации об ограничениях памяти Windows, пожалуйста, просмотрите эту страницу . Каждое упомянутое число должно быть разделено на 2, поскольку windows резервирует верхнюю половину адресного пространства для использования кодом, работающим в режиме ядра (кольцо 0). Кроме того, имейте в виду, что всякий раз, когда для 32-разрядной системы ограничение превышает 4 ГБ, подразумевается использование PAE , и, таким образом, вы все равно не сможете реально превысить ограничение 2 ГБ, если операционная система не поддерживает 4gt. может достигать до 3 ГБ.

2 голосов
/ 04 апреля 2009

Да, в 32-битной среде вы ограничены адресным пространством 4 ГБ, но Windows заявляет о половине. На 64-битной архитектуре она намного больше. Я считаю, что это 4G * 4G

А на Compact Framework обычно порядка нескольких сотен МБ

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

В следующем сообщении блога содержатся подробные сведения о памяти x86 и x64 max. Он также имеет небольшой инструмент (источник доступен), который позволяет легко использовать различные варианты памяти: http://www.guylangston.net/blog/Article/MaxMemory.

0 голосов
/ 04 апреля 2009

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...