Выявление проблем с памятью в приложении ASP.NET

Question

У меня запущено приложение ASP.NET, и на рабочем месте оно использует около 450 МБ ОЗУ, однако оно не должно использовать слишком много, и со временем оно увеличивается, так что, возможно, утечка или, по крайней мере, что-то не выпускается должным образом.

Я посмотрел с PerfMon, и в GC Gen2 было 416 МБ.

У кого-нибудь есть идея узнать, что хранится в памяти? Могу ли я просто взять dotTrace / ANTS и каким-то образом подключить его к моему IIS (6 - на Windows Server 2003) - или есть лучший способ? : -)

Спасибо.

Answer 1

Классическая проблема обновления группы строк в цикле может вызвать проблему, которую вы видите из-за большого объема памяти, выделяемой для новых строк без их освобождения. Вы используете StringBuilder, где это уместно?

Answer 2

Просмотр этой презентации TecheEd от Тесс будет хорошим началом.

Она демонстрирует использование adplus для создания дампа приложения ASP.NET, которое потребляет много оперативной памяти, а затем загружает этот дамп в WinDbg для анализа. Используйте команду! Gcroot в WinDbg, чтобы найти неожиданные корни и перейти оттуда. Она не советует хранить сложные типы, которые содержат ссылки на другие объекты, в кеше или сеансе.

Answer 3

Вы правильно подключаете обработчики событий везде? Мне сказали, что они могут сидеть без дела, если вы никогда не отсоедините их от события. Они могут хранить ссылки на более крупные объекты дольше, чем необходимо.

Answer 4

Хотя это специальный блог о технологии, которую вы, вероятно, не используете, в ней рассказывается, как диагностировать проблемы с памятью - http://blogs.msdn.com/tess/archive/2008/09/12/asp-net-memory-issues-high-memory-usage-with-ajaxpro.aspx

Просмотрите работу Тесс, у нее много постов по отладке / диагностике, и я уверен, что вы сможете найти больше полезных для вас.

Answer 5

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

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

Также получается, что на сайте моего сайта с количеством одновременно работающих пользователей, грубая оценка концерта была именно тем, что ему нужно.

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

Наконец, но не в последнюю очередь проверьте, какой тип поставщика сеансов вы используете, если inproc слишком сильно напрягает ваш сервер, возможно, пришло время перейти на службу сеансов состояний asp.net или использовать сервер sql в качестве поставщика сеансов. .

Дайте мне знать, что вы думаете, и если вы нашли и особенности.

Answer 6

Правильно ли вы избавляетесь от объектов классов, которые реализуют IDisposable? Это может быть SqlConnections, SqlCommand, SqlDataAdapter, DirectoryEntry и т. Д. Есть ли у вас объекты, которые используют неуправляемую память, которые не реализуют IDisposable (и / или не удаляются)?