ASP.NET не видит обновления RAM?
В течение нескольких лет мы размещали приложение ASP.NET 4.5 на той же виртуальной машине, что и база данных SQL Server 2008R2, в 4 ГБ ОЗУ. Производительность была хорошей.
Наше приложение представляет собой каталог, и мы активно используем кеш памяти .NET для создания «рабочего набора» частей и связанных данных. Обычно 80 000-90 000 записей в кэше.
За прошедшие выходные мы увеличили объем оперативной памяти до 8 ГБ и наблюдаем странное поведение памяти в приложении ASP.NET.
После обновления диспетчер задач сообщает нам, что мы используем только 60% оперативной памяти. SQL очень отзывчивый. Но количество записей в кеше увеличивается до 15 000, а затем уменьшается до 7-8 000. Есть много активности GC. Это как если бы приложение ASP.NET испытывало нехватку памяти, и при этом оставалось еще 3+ ГБ неиспользуемой оперативной памяти.
Почему это могло быть? Все 64 бит. Больше ничего не изменилось. Для SQL или пула приложений ограничений памяти нет. Приложение не перерабатывает, просто очень агрессивно обрезает кеш. Любые идеи?
Активность сборщика мусора не всегда напрямую связана с тем, сколько у вас памяти, но может зависеть от того, работает ли пул приложений в 32-битном или 64-битном (источник). Если вы выполняете много распределений объектов, тогда у вас будет много активности GC.
Мы запускаем все наши процессы в 64-битном режиме (так как часть нашей обработки данных занимает до 12 ГБ ОЗУ), и у нас нет проблем с этим, и мы не замечаем, что производительность падает. Это правда, что все ваши ссылки на память теперь занимают вдвое больше памяти, но это может происходить за счет меньшего количества сборок мусора, поэтому вы никогда не должны доверять никаким правилам, которые говорят: «Это всегда лучший способ». Что касается производительности, вы всегда хотите измерять вещи самостоятельно.
По умолчанию, начиная с IIS 7, AppPools настроен на работу в 64-битном режиме. Инструкции по проверке / изменению вашего AppPool для работы в 64-битной версии можно найти здесь (в разделе Advanced App Pool Settings):
Что касается кеширования, рассматривали ли вы возможность использования внепроцессного кеша, например Windows Server Appfabric чтобы они были доступны на разных хостах и не зависели от вашего пула приложений IIS? На вашем веб-сайте, скорее всего, будет меньше проблем с сборкой мусора, если проблемы с памятью будут размещены в специальном приложении.
Стандартный процесс SASp.NET - 32-битный согласно рекомендации Microsoft, даже на 64-битных хостах. Не используйте 64-битную версию без уважительной причины - у нее есть недостатки. если нужно - поменяйте настройку. Предпочтительны настройки веб-фермы - несколько запущенных процессов.
Оказывается, SQL занимал гораздо больше памяти, чем я думал. Раньше, когда у машины было всего 4 ГБ, я позволял SQL работать с настройками минимального и максимального объема памяти по умолчанию. Он отлично работал более двух лет. После обновления до 8 ГБ ОЗУ он все сожрал, и ASP.NET БЫЛ голоден. Вчера вечером я установил максимальный объем памяти 5 ГБ, и сегодня утром все хорошо и тихо. Я не хочу сглазить, но я думаю, что отчеты о памяти диспетчера задач лежат как чертов коврик! Я собираюсь попрактиковаться в 5 ГБ в течение следующих нескольких дней в поисках оптимального варианта.