Максимальная память, которую может выделить процесс .NET

Windows can be configured to allocate more page file space on demand, or on request.
Job objects can prevent the consumption of more than a certain amount of memory.
Фрагментация кучи и ее поколенческий характер (плюс необходимость помещать большие объемы в кучу больших объектов)

Все это означает, что жесткое ограничение в действительности не очень полезно и означает ответ на вопрос «сколько памяти может Я теоретически выделяю "гораздо сложнее, чем вы думаете.

Поскольку это сложно, любой задающий этот вопрос, вероятно, пытается сделать что-то неправильно и должен перенаправить свой вопрос на что-то большее. полезно.

Что вы пытаетесь сделать, чтобы задать такой вопрос?

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

Верно. Это гораздо более решаемый вопрос.

Два решения в порядке сложности:

1. Заставьте ваши кеши использовать WeakReferences
   • Это означает, что некоторые вещи будут освобождены системой почти волшебным образом для вас, но у вас будет небольшой контроль над такими вещами, как политика замены
   • , это зависит от того, что кэшированные данные намного больше, чем ключ, и накладные расходы слабой ссылки
2. Зарегистрируйтесь для уведомления о сборке мусора.
   • Это позволяет вам контролировать освобождение вещей.
   • вы полагаетесь на систему, имеющую соответствующий максимальный размер для поколений сборщика мусора, что может занять некоторое время, чтобы добраться до устойчивое состояние.

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

В качестве примечания: в .Net нельзя использовать объекты переменного размера (строки, массивы). размером более 2 ГБ из-за ограничений основных структур CLR для управления памятью. (и любое из приведенных выше решений выиграет от этого)

Разве это не зависит от того, сколько у вас оперативной памяти?

Теоретически процесс x64 может выделять EB (этабайты?) RAM, я думаю - то есть МНОГО. Но если вы это сделаете, ваша машина должна начать пейджинг как сумасшедший и вообще умереть.

В 32-битном режиме все было по-другому, поскольку вы не могли выделить более 1 ГБ ОЗУ ни в одном процессе в Windows (да, есть способы обойтись) это, но это некрасиво). На практике это примерно 7-800 мегабайт на процесс .NET, поскольку .NET зарезервировал некоторое пространство.

В любом случае, в 32-битном формате максимум, что вы можете использовать, - это 3 ГБ - ОС резервирует для себя 1 ГБ виртуального пространства.

В 64-битной версии это должно быть 2 ^ 64, что является большим числом, но http: //en.wikipedia. org / wiki / X86-64 говорит, что это 256 ТБ виртуального пространства и 1 ТБ РЕАЛЬНОЙ ОЗУ. В любом случае, его намного больше, чем у вас, вероятно, будет на вашем компьютере, поэтому он попадет в файл подкачки.

В 64-битной ОС и 64-битной среде выполнения, Приложения на базе .NET 2.0 теперь могут использовать в 500 раз больше памяти для данных такие как серверные кеши.

Здесь тоже есть полезная информация http://www.theserverside.net/tt/articles/showarticle.tss?id=NET2BMNov64Bit

Кстати, если вы используете машина x64 (т.е. машина x64 + ОС x64), компиляция для AnyCPU и x64 делает то же самое - она ​​работает в режиме x64. Единственная разница в том, если вы используете AnyCPU vrs x86:

• x64 OS / .NET, AnyCpu: x64 app
• x64 OS / .NET, x64: x64 app

• x64 OS / .NET, x32: x32 app (Платформа x64 .NET, так как установлены ОБЕ x32 и x64 версии Fx)

• x32 OS / NET, AnyCPU: x32 app

• x32 OS / .NET, x64: CRASH AND BURN BABY! (на самом деле, он просто изящно умирает)
• x32 OS / .NET, x32: x32 app.