Поиск утечки памяти на веб-сайте ASP.NET с помощью ANTI Memory Profiler?

Question

У меня есть веб-сайт ASP.NET FRAMEWORK 4.0 с утечкой памяти. Чтобы найти его, я установил ANTS Memory Profiler.

Это то, что я делаю:

1. сайт хоста в IIS7
2. Start Муравьи Memory Profiler 8.1
3. Установите мы профилирование веб-сайт IIS и указать URL этой страницы (построен в выпуске)
4. тест Start и пусть запуска веб-страницы (много кэширование так около 1 мин)
5. снимок памяти при первой загрузке страницы и стабильной
6. Обновить первая страница МНОГО и увидеть памяти поднимают от 110 МБ (Байт/Working Set -Частное) до 270 MB
7. Посещение много страниц на веб-страницу и увидеть его поднять до 360 MB
8. Push It некоторые все больше и больше не поднимают делается
9. Возьмите памяти снимок и нажмите Class список (проверить классы с источником)

Это покажет классы, которые до сих пор хранятся, например

sites_mypage_default_asx - 10 320 bytes and 10 live instances 
usercontrols_common_pagehead_ascx - 928 bytes and 4 live instances 

и так далее

Я верю/надеюсь, что эти классы, которые будут очищены с помощью GC

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

string - 1 890 292 bytes 
RuntimeMethodInfo - 990 976 bytes 
RuntimePropertyInfo - 604 136 bytes 
Hastable+bucket[] - 413 712 bytes 

и так далее.

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

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

Но я не знаю, как сделать следующий шаг? Почему мой сайт по-прежнему занимает 350 МБ? 350 МБ с данными - это много данных, и я не вижу, чтобы я кэшировал эти данные !?

Какой должен быть следующий шаг?

Answer 1

Это не должно быть утечка памяти, просто недостаточно памяти, чтобы сборщик мусора мог выполнять более комплексную работу. Чтобы полностью исследовать эту проблему и проверить, действительно ли это настоящая утечка памяти, вы должны сделать долгосрочную нагрузку на своей веб-странице со средним трафиком. Вы можете использовать Visual Studio Ultimate Load Testing, если вам повезет с ним или с открытым кодом LoadUI.Во время этого теста наблюдения счетчиков производительности:

• .NET Memory группы счетчиков, особенно # Bytes in all Heaps и все Gen # heap size,
• Process : Working Set и Process : Private bytes

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

Поскольку я большой поклонник WinDbg (это быстрее, более подробно и дешевле, чем любой коммерческий инструмент на основе графического интерфейса), я предлагаю вам использовать его. Используйте его с расширением Psscor2 или Psscor4 (в зависимости от используемой вами программы). После настройки среды отладки (установки WinDbg и копирования в папку Psscor) создайте свалку процесса. Вы можете сделать это легко, например, с помощью инструмента Procdump:

procdump -ma <PID> 

Затем свалка нагрузки с помощью меню Файл -> Открыть Давка вариант самосвала. Нагрузка соответствующая версия Psscor:

.load psscor4 

Затем выполнить команду загрузки символов с серверов Microsoft (если это необходимо), убедитесь, что у вас есть подключение к интернету:

!symfix 

И теперь вы должны иметь доступ на много очень интересную команду (ищите !help, чтобы перечислить их). Чтобы посмотреть использование памяти каждого типа:

!dumpheap -stat 

Который приведет длинный список типов и их использование памяти отсортированные по возрастанию:

... 
0x79b56d84 297,724 12,308,164 SomeNamespace.SomeObject 
0x6983ad6c  1,177 19,751,856 SomeNamespace.SomeClass[] 
0x79ba4aa0  6,544 46,300,516 System.Byte[] 
0x001027a0  527 69,152,092  Free 
0x79b9fb08 1,127,896 82,456,640 System.String 

Чтобы увидеть общее использование памяти (iu означает, что и некорневых объекты быть включены):

!heapstat -iu 

Heap    Gen0   Gen1   Gen2   LOH 
Heap0   6594540  1488744  24322236  19164192 
Heap1   8360908  951312  30822196  14358048 
Heap2   8207144  386488  23198448  16078256 
Heap3   4299844  453440  36015332  16125560 
Total  39615576  5301708 179028460  93254272 

Free space:             Percentage 
Heap0   4868516   12   3512  8692736SOH: 15% LOH: 45% 
Heap1   7221256   12  66200  5232904SOH: 18% LOH: 36% 
Heap2   7518052   12   520  7677824SOH: 23% LOH: 47% 
Heap3   3578232   12  6606504  4098640SOH: 24% LOH: 25% 
Total  28807516   72  8353592  31990912 

Unrooted objects:           Percentage 
Heap0   1688812  258828  8905748  4019992SOH: 33% LOH: 20% 
Heap1   1052548  270796  9983932  5625984SOH: 28% LOH: 39% 
Heap2   503560  267112  7697632  4596792SOH: 26% LOH: 28% 
Heap3   571776  235440  8453980  5205176SOH: 22% LOH: 32% 
Total   9691432  2179788  53539772  32143328 

Эта информация наверняка приведет вас к некоторым выводам, но дальнейшее расследование, очевидно, возможно, поэтому не стесняйтесь спрашивать ,