ASP.Net: поиск причины OutOfMemoryExpcetions - PullRequest
Новая
       9

ASP.Net: поиск причины OutOfMemoryExpcetions

2 голосов
/ 12 мая 2010

Я пытаюсь отследить причину OutOfMemory для веб-сайта. На этом сайте ~ 12 000 .aspx страниц, и в последний раз, когда он падал, я записал дамп памяти с помощью adplus.

После некоторого исследования я обнаружил много фрагментов кучи, около 100 МБ свободных блоков, которые нельзя назначить. Копание вглубь кучи больших объектов фрагментировано, и причины, по-видимому, заключаются в интернировании строк, как описано [здесь] [1]

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

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

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

[1]: • Фрагментация кучи больших объектов

Ответы [ 2 ]

0 голосов
/ 13 мая 2010

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

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

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

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

0 голосов
/ 13 мая 2010

Да, фрагментация является одной из причин, потому что будет труднее «найти» память.

Некоторые очень известные подсказки:

  • В 32-битной ОС ваш рабочий процесс не может превышать 2 ГБ в памяти, даже если в вашей системе их больше. Альтернативой является ключ / 3GB (файл boot.ini).

  • Вероятность возникновения исключения OutOfMemoryException начинает резко возрастать, когда «Process \ Virtual Bytes» находится в пределах 600 МБ от виртуального адресного пространства (обычно 2 ГБ), а во-вторых, тесты показали, что «Process \ Virtual» Байт »часто больше, чем« Process \ Private Bytes », не более чем на 600 МБ

  • CLR выделяет и обрабатывает память блоками (64 МБ из памяти;)). Это не означает, что он использует всю эту память, это означает, что один блок не будет освобожден до тех пор, пока не будет использован один байт, и это не приведет к фрагментации памяти.

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

  • Что касается динамической компиляции, это правда, но наиболее важными являются ключи <compilation debug="false" /> / <deployment retail=”true”/>. Они включают пакетную компиляцию, которая подразумевает одну DLL по каталогу (это другая точка зрения), а не одну DLL на «страницу», которая вызывает фрагментацию виртуального пространства.

  • Об одной DLL по каталогу, даже с пакетной компиляцией, больше ваших каталогов / подкаталогов, больше у вас будет DLL и больше фрагментированного виртуального адресного пространства.

Лично я использую ANTS Memory Profiler для поиска проблем с памятью.

...