В настоящее время мы думаем о создании системы кэширования для хранения данных, извлеченных из базы данных SQL, и сделать их доступными для нескольких других приложений (веб-сайт, веб-сервис и т.д.). Мы полагаем, что кеш работает как служба Windows и в основном состоит из интеллектуального словаря, который содержит записи кэша. Мой вопрос в том, есть ли предел для рабочего набора приложения (он будет работать под Windows Server 2003)? Или количество физической памяти ограничено?
Ограничение памяти для одного .NET-процесса
Ответ 1
32bit или 64bit? 32bit - 2gb (для процесса), 64 бит - 1TB (сервер Enterprise Edition 2003).
Однако максимальный размер объекта CLR составляет 2gb даже на 64-битной версии.
Обновление: приведенная выше информация была правильной в 2008 году. См. Ответ Оша для получения более подробной информации. Сервер Windows 2016 может иметь максимум 24TB.
Ответ 2
Недавно я делал обширное профилирование по ограничениям памяти в .NET на 32-битном процессе. Мы все обманываем мыслью, что мы можем выделить до 2,4 ГБ (2 ^ 31) в .NET-приложении, но, к сожалению, это неверно:( Прикладной процесс имеет столько места для использования, и операционная система отлично справляется работа по управлению им для нас, однако сама .NET, похоже, имеет свои собственные накладные расходы, что составляет примерно 600-800 МБ для типичных приложений реального мира, которые вызывают ограничение памяти. Это означает, что как только вы выделите массив целых чисел, который принимает 1.4 ГБ, вы должны ожидать увидеть OutOfMemoryException().
Очевидно, что в 64-битном листе это происходит позже (пусть чат через 5 лет:)), но общий размер всего в памяти также растет (я нахожу его от 1,7 до ~ 2 раза) из-за увеличенного размера слова.
То, что я точно знаю, это то, что идея виртуальной памяти от операционной системы определенно НЕ дает вам практически бесконечное пространство для размещения в рамках одного процесса. Он доступен только для того, чтобы полные 2,4 ГБ были адресованы всем (многим) приложениям, запущенным за один раз.
Ответ 3
Следующая таблица из MSDN является наиболее точным ответом на ваш запрос. Обратите внимание, что флаг IMAGE_FILE_LARGE_ADDRESS_AWARE не может быть установлен непосредственно из управляемого компилятора, хотя, к счастью, его можно установить post build с помощью утилиты editbin. 4GT обозначает флаг /3gb.
Ответ 4
На 32-битной Windows вы можете получить немного больше памяти, загрузив Windows с флагом /3gb и отметив ваше приложение как "большой адрес"
Ответ 5
Маттиас,
На самом деле это не ответ на прямой вопрос, а еще один способ приблизиться к этой проблеме, которая обойдется вокруг некоторых крупных подводных камней, которые могут стать основной головной болью с кешированием решений. (Извините, у меня нет никаких рекомендаций по этому вопросу.)
Мы реализовали это в предыдущем проекте, и это создало другие проблемы.
Для автономного доступа вы можете использовать sql express на рабочих столах, чтобы создать зеркало вашей базы данных (или просто бит, который вам нужно кэшировать)? Тогда все, что вам нужно сделать, это переключить базу данных, на которую указывает ваше приложение. Вы даже можете использовать его, чтобы хранить различия и воспроизводить их на сервере, хотя у этого есть другие проблемы. Вы можете изменить разрешения для локальной копии, чтобы сделать это доступным только для чтения, если это так.
Словари, которые вы думаете о создании звука замечательно, как индексы Sql. Я бы опирался на sql, чтобы выполнить эту работу за вас, если вы можете ее создать. Зачем изобретать это колесо? Если вы это сделаете, вам нужно будет тщательно подумать об истечении срока действия кеша и управлении памятью, особенно если это служба Windows.
Удачи,
Сэм
Ответ 6
Как и в любой другой программе Windows, вы ограничены адресным пространством. То есть: на 32-битном, вы можете иметь 2 ГБ адресного пространства. На x64 вы можете иметь 8TB.
Если у вас нет 8 ТБ физической памяти, он начнет страницу.