Итак, мы проводим стресс-тестирование приложения ASP.NET, разработанного внешней компанией. Мы выполняем примерно 50 запросов в секунду, и примерно через полчаса каждый из 48 рабочих процессов (w3wp.exe) занимает около 400 МБ и продолжает расти. Работает на IIS7.
Теперь, после вмешательства с dotTrace, я почти уверен, что здесь есть утечка памяти, но трудно быть уверенным на 100%, не зная приложения. Когда мы столкнули разработчиков с этой теорией, они отвергли ее через 30 секунд, сказав что-то вроде «память обрабатывается автоматически в .NET». Конечно, .NET собирала бы мусор 48x ~ 400MB, если бы это были финальные данные?
Во всяком случае, я привык работать с WinForms. Как именно создать утечку памяти в ASP.NET? ЕДИНСТВЕННЫЙ способ (неправильное) использование объектов Application и Session в .NET?
редактировать
С тех пор, как я разместил этот вопрос, я узнал, что хранение статических ссылок на объекты в обработчиках запросов (будь то класс веб-службы, веб-форма или что-то еще) вызовет «утечки». Вероятно, это неправильный термин, но в любом случае ... В этом я не был уверен, потому что я думал, что классы обработчиков уничтожаются и воссоздаются после каждого запроса IIS.
Итак, код вроде этого:
public class SomeService : IService
{
public static List<RequestData> _requestDataHistory = new List<RequestData>();
public void SomeRequest(RequestData data)
{
_requestDataHistory.Add(data);
}
}
Рано или поздно произойдет сбой вашего сервера. Может быть, для большинства это было очевидно, но не для меня :-)
Все еще не уверен, будет ли это проблемой, если вы удалите ключевое слово static. Являются экземпляры удаляется после каждого запроса?
Возможно, разработчики правы. В мире .Net сборка мусора и освобождение памяти происходит по мере необходимости. Т.е. если приложению доступно много памяти, оно может потреблять все больше и больше, пока операционная система не позволит выделить больше. Вы не должны беспокоиться об этом, если это действительно не вызовет проблем.
Конечно, могут быть утечки памяти, если приложение не удаляет должным образом неуправляемые ресурсы, такие как сокеты, обработчики файлов и т. Д. Посмотрите на объекты операционной системы (в диспетчере задач вы можете включить дескрипторы и столбцы объектов пользователей), чтобы увидеть, как Они растут.
Как вы сказали, причиной может быть неправильное использование объекта Application или Session.
Мне интересно, зачем вам 48 пулов приложений (рабочих процессов). Это перебор, и это вам совсем не нужно.
GC управляет памятью для каждого процесса, а 400 МБ на процесс - это совсем немного. Уменьшите количество пулов приложений до nr. ядер - 1, а затем стресс-тест приложения. Если затем он слишком сильно разрастется, вы можете беспокоиться об утечках памяти.
Основываясь на вашей дополнительной информации, да, в этом случае список истории будет расти бесконечно. Статические объекты создаются один раз для каждого домена приложения и живут до тех пор, пока не будет жить домен приложения.
Я не советую вам произвольно удалять ключевое слово static, если вы не знаете, что не нарушаете логику приложения. Узнайте, почему все равно собираются эти данные и для чего они используются. У кода есть еще одна проблема - он не является потокобезопасным, его поведение не определено, когда 2 запроса поступают одновременно и решают добавить данные в этот список.
Лучше переместите свой вопрос на stackoverflow.com, так как это вопрос программирования, а не административный.
Если вы не контролируете этот код и действительно хотите просто решить проблему с памятью, вы можете настроить пулы приложений на повторное использование после X запросов или после того, как они получат более Y объема памяти - но опять же, это не реальное решение.
Утечки памяти, в общем смысле, - это отрицательные / непредвиденные результаты логики кодирования, которая не высвобождает свои неиспользуемые (или больше не используемые) ресурсы правильно (или вообще), при этом все еще резервируя дополнительные ресурсы для новых / продолжающихся требований использования / обработки. Общий объем ресурсов затем продолжает расти, даже несмотря на то, что фактические требования могут не обязательно увеличиваться, если имеется надлежащая «очистка» правильного использования и высвобождения ресурсов.
Короче говоря, это не ограничивается «злоупотреблением» логическим программированием, которое может быть вызвано неверными предположениями об управлении ресурсами или просто его отсутствием.