Высокое использование памяти с пулом приложений w3wp IIS 7

У меня есть приложение веб-сайта, работающее в своем собственном пуле приложений в IIS 7.0. Приложение представляет собой веб-сайт ASP.NET MVC 3.

Я заметил, что использование памяти для этих приложений связано с тем, что рабочая станция w3wp IIS довольно высока (800 МБ, с некоторыми колебаниями).

Я пытаюсь диагностировать проблему и попробовал следующее:

Я отключил кэширование выходных страниц для веб-сайта на уровне IIS, а затем переработал пул приложений. Это приводит к перезапуску процесса w3wp. Использование памяти для этого процесса постепенно увеличивается до 800 МБ, для этого требуется около 30 секунд. В настоящее время запросы страниц не обрабатываются. Когда я перезапускаю сайт из IIS, размер памяти процесса не изменяется.

Я попытался запустить отладочную копию приложения из VS 2010, нет проблем с использованием памяти.

Некоторые идеи, которые у меня есть/вопросы:

Эта проблема связана с кодом веб-сайтов? - Учитывая, что ракеты памяти перед любыми запросами страницы отправлены/обработаны, я бы предположил, что это НЕ проблема с кодом?

В приложении, созданном в MVC, нет обработки кэширования, написанной на нем.

Веб-сайт использует отображение данных в режиме реального времени, периодически использует ajax-запросы и обычно остается "открытым" в течение длительных периодов времени.

Почему загрузка памяти запускается после того, как приложение переработано и запросы пользователя не отправляются? Это потому, что он загружает в него информацию о старом кеше с диска?

Приложение НЕ сбой, меня просто беспокоит использование памяти, это не так уж важно для веб-сайта...

Любые идеи/помощь в решении этой проблемы будут оценены.

Ответ 1

Я просто смотрю, что мой сервер и мои пулы используют память виртуального размера 900-1000 МБ и рабочий набор 380 МБ. Мои сайты работают без проблем в течение нескольких лет, и я проверяю их со всех сторон. Мой пул никогда не перерабатывается, и сервер работает до следующего обновления с 40% стабильной свободной физической памятью.

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

Вы можете использовать explorer для просмотра рабочей и виртуальной памяти.

Вы также можете подумать, чтобы запустить профиль против вашего кода, чтобы узнать, есть ли у вас "утечка памяти" или другая проблема. Найдите один из Google: https://www.google.com/search?hl=en&q=asp.net+memory+profiler.

Ответ 2

Лучшее, что можно сделать, если вы можете позволить себе использовать отладчик, - установить Инструменты для отладки Windows и использовать что-то вроде WinDbg и SOS.dll точно определить, что это в памяти.

после установки инструментов, вы можете:

Запустить запуск Windbg.exe(как администратора)
Используйте "File- > Attach To Process" и выберите w3wp.exe для приложения, которое вы пытаетесь выяснить. Если у вас есть много, вы можете использовать диспетчер задач и добавить столбец командной строки, чтобы увидеть PID или использовать IIS Manager- > Worker Processs, чтобы понять это, а затем выбрать этот процесс в WinDBG.
запуск:
.loadby sos clr
! dumpheap -stat

В этот момент вы сможете увидеть все типы, отсортированные по наибольшему объему памяти, поэтому вы можете начать с тех, что внизу. (Я бы рекомендовал исключить строки и объект, поскольку они обычно являются побочным эффектом, а не причиной). Используйте "! Dumpheap-type type-here", чтобы найти экземпляры и использовать! Gcroot для тех, кто выясняет, почему они находятся в памяти, может быть, из-за статического поля или обработчика события просочились, каналы WCF не удалены или что-то вроде которые являются общими источниками.

Ответ 3

Вероятно, здесь это не относится, но я подумал, что я бы выбрал его для хорошей меры. В последнее время у меня была проблема, когда моя память пошла бы вверх и максимизировалась, когда она действительно смогла очистить 80% от нее. Проблема: он подумал о еще двух концертах, чем на самом деле, так что GC был довольно ленив. (Это связано с ошибкой VMware -windows, которая сообщала 8 Gig, но физически было всего 6,4). См. Блог. http://www.worthalook.net/2014/01/give-back-memory/

Ответ 4

Что-то, что может помочь: если вы переписываете (открываете/сохраняете) файл web.config, то ваше приложение будет reset, вы должны отслеживать использование памяти с этой точки. Если он будет расти во время использования, это может означать утечку памяти или безумное кэширование. Возможно, вы сможете определить, какие действия на вашем сайте приводят к увеличению памяти. В течение длительного времени использование памяти в приложении должно быть стабильным.