Приложение ASP.NET, съедая память. Приложение / Сессия возражает причине?
Perfmon.exe
Сначала посмотрите на тип объекта Процесса. Это имеет экземпляр для каждого процесса в системе и содержит метрики как Виртуальные Байты, Виртуальный Пик Байтов, Рабочий набор и Пик Рабочего набора. Экземпляр SQL Server назовут в честь имени процесса, 'sqlservr'. Рассмотрение всех экземпляров, которые можно быстро видеть, какой процесс вызывает большую часть потребления памяти.
Следующий взгляд на собственные счетчики SQL Server. В SQL менеджер по Server:Buffer возражает, что Вы найдете SQL Server собственными счетчиками. Необходимо посмотреть на счетчик Общего количества страниц, который считает всю память прослеженной SQL Server внутренне. Счетчик находится на страницах, таким образом, необходимо умножиться на 8 192 для получения байтов.
Там может быть большим несоответствие между Процессом Виртуальный счетчик Байтов и Общим количеством страниц own's SQL. Это может произойти, когда SQL использует AWE для отображения памяти, и SQL может использовать AWE на x64 платформах также.
Можно также отследить SQL Server moemory потребление с внутренней части, посмотреть на sys.dm_os_memory_clerks или выполнить DBCC MEMORYSTATUS.
Если Вы находите, что SQL Server использует память: закройте свой сеанс, установите руки с клавиатуры и уйдите. Это - нормальное, намеченное и желаемое поведение. Если Вы нуждаетесь в памяти для какого-либо другого процесса, отодвигаете тот процесс от того же хоста как SQL. Никогда не выполняйте ничто больше на том же хосте, Вы выполняете SQL Server (никакой IIS, никакой ASP, никакой обмен, никакой DC, никакой DNS/ветры, ничто).
Возможно, разработчики правы. В мире .Net сборка мусора и освобождение памяти происходит по мере необходимости. Т.е. если приложению доступно много памяти, оно может потреблять все больше и больше, пока операционная система не позволит выделить больше. Вы не должны беспокоиться об этом, если это действительно не вызовет проблем.
Конечно, могут быть утечки памяти, если приложение не удаляет должным образом неуправляемые ресурсы, такие как сокеты, обработчики файлов и т. Д. Посмотрите на объекты операционной системы (в диспетчере задач вы можете включить дескрипторы и столбцы пользовательских объектов), чтобы увидеть, как они растут.
Как вы сказали, неправильное использование объекта Application или Session также может быть причиной.
Мне интересно, почему у вас должно быть 48 пулы приложений (рабочие процессы). Это перебор, и это вам совсем не нужно.
GC управляет памятью для каждого процесса, а 400 МБ на процесс - это совсем немного. Уменьшите количество пулов приложений до nr. ядер - 1, а затем стресс-тест приложения. Если затем он станет слишком большим, вы можете быть обеспокоены утечкой памяти.
На основании вашей дополнительной информации, да, в этом случае список истории будет расти бесконечно. Статические объекты создаются один раз для каждого домена приложения и живут до тех пор, пока не будет работать домен приложения.
Я не советую вам произвольно удалять ключевое слово static, если вы не знаете, что не нарушаете логику приложения. Узнайте, почему все равно собираются эти данные и для чего они используются. У кода есть еще одна проблема - он не является потокобезопасным, его поведение не определено, когда 2 запроса поступают одновременно и решают добавить данные в этот список.
Утечки памяти, в общем смысле, - это отрицательные / непредвиденные результаты логики кодирования, которая не высвобождает свои неиспользуемые (или больше не используемые) ресурсы правильно (или вообще), при этом все еще резервируя дополнительные ресурсы для нового / продолжающегося использования / требований обработки. Общий объем ресурсов затем продолжает расти, даже несмотря на то, что фактические требования не обязательно увеличиваются, если надлежащий "