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

Question

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

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

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

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

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

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

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

Приложение, встроенное в MVC, не обрабатывает записанное в него кэширование.

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

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

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

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

Answer 1

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

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

1. Запустите Windbg.exe с повышенными правами (от имени администратора)
2. Используйте «Файл-> Присоединить к процессу» и выберите w3wp.exe для приложения, которое вы пытаетесь выяснить. Если у вас их много, вы можете использовать диспетчер задач и добавить столбец командной строки, чтобы увидеть PID, или использовать IIS Manager-> Рабочие процессы, чтобы выяснить это, а затем выбрать этот процесс в WinDBG.
3. пробег:
4. .loadby SOS CLR
5. ! Dumpheap -stat

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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