none
Проблема с w3wp.exe на windows 2008 server RRS feed

  • Вопрос

  • Я приветствую всех!

    У меня возникла проблема. Мы сделали сайт на asp.net, использовали MVC2, LINQ to SQL Classes, Ninject.

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

    Есть фикс как бы - http://support.microsoft.com/kb/912891. Статья та за 2007 год. По логике, он уже включен же в фреймворк.

    Собственно вопрос такой. Кто с таким сталкивался и есть ли методы борьбы?

    Пул часто перезапускать не пойдет, сессии хранятся на SQL-сервере и перезапуск пула влечет за собой обрыв сессии. Все контроллеры и модели имеют деструкторы (наследовал от IDisposable), то есть я уверен что все мои объекты уничтожаются после того как они отработали.

    Буду очень благодарен за отзывы :)

Ответы

  • Пройдитесь по лабам от Tess. Там все не слишком сложно. Поиск утечки обычно сводится к просмотру статистики dumpheap -stat и поиска "текущего" типа - того, который встречается чаще всего(за исключением массивов и строк).

    Если пугает windbg - пользуйтесь студией, предварительно включив debug native code в свойствах проекта. Окно Immediate понимает команды windbg.

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

    Пользователей у вас вылогинивает не из-за потери сессии. Скорее всего используется forms authentication, а в ней токены подписываются ключем из секции machineKey. По умолчанию они генерируемые, уникальные для приложений, но в IIS7 почему-то перегенерируются при рестарте апппула. Сгенерируйте явные ключи и впишите в web.config. Генератор для облегчения жизни: http://aspnetresources.com/tools/keycreator.aspx

    • Помечено в качестве ответа Alexandr Kuznetsov 21 мая 2010 г. 3:10
  • Строки и массивы - всегда в конце списка dumpheap -stat. С ними надо бороться только если они явно висят в LOH.

    Почитай кусок System.String and array objects: http://blogs.msdn.com/tess/archive/2009/02/27/net-memory-leak-reader-email-are-you-really-leaking-net-memory.aspx

    Удачи :)
    • Помечено в качестве ответа Alexandr Kuznetsov 21 мая 2010 г. 3:12
  • Похоже я решил проблему. Вся загвоздка стояла в том что  стояло <compilation debug="true"> . Из-за этого память сжиралась в три горла, а дампы нечего такого не показывали :(

    Большое спасибо, PashaPash =) Ну и надо бы сказать спасибо Тесс, по ее наводкам я и решил проблему. Да и с windbg теперь имеем представление как работать. Урок получился знатный.

    • Помечено в качестве ответа Alexandr Kuznetsov 21 мая 2010 г. 3:13

Все ответы

  • Фикс по ссылке не на "постепенное наращивание памяти" :)

    Если используемая память действительно постоянно растет, и рост не прекращается со временем - нужно брать профайлер, например ANTS Memory Profiler , или родные утилиты MS, вроде windbg/sos, и смотреть где именно утечка. По работе с windb/sos есть неплохой блог http://blogs.msdn.com/tess/ , с примерами и обучалками.

    Если сессии хранятся на SQL Server - то перезапуск пула их не оборвет, кстати. Но все равно лучше пул не трогать.

    Деструкторы - реализация IDisposable - не заставляют объекты "уничтожаться". Объект перестает существовать - собирается GC - только если на него больше нет ссылок. Если положить ссылку на контроллер в статическую переменную - то контроллер будет существовать бесконечно, хоть он и IDisposable.

    Даже наоборот, объект с деструктором будет жить чуть дольше. IDisposable следует реализовать только в случае, когда нужно явно освободить не только память, а еще и другие ресурсы, которые были вручную выделены во время работы.

     


  • Если сессии хранятся на SQL Server - то перезапуск пула их не оборвет, кстати.

    Обрывает, мы так пробовали. Пул перестартанул и сессия была оборвана.

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

    По фиксу кстати, да, я последнее время слишком маниакально реагирую на "application uses more memory", извиняюсь =)))

    Ссылки на контроллеры в статические переменные не пихались.. У меня там на Ninject  закручено, но не думаю что из-за нее. А ANTS Memory Profiler, скотина, при запускке выругался 2мя exception-ами и дальше ничего не захотел делать.

    Собственно говоря у меня там в Dispose только модель "разрушается" и все. Мне что, получается можно и не делать было это?

  • По сессиям - по каким признакам "сессия оборвана". Пользователя вылогинило?

    Ищи другой профайлер или разбирайся с дампами. Там не все так сложно как кажется - пару команд всего.

    Да, если модель чисто managed, и не держит у себя внутри никаких ресурсов (открытых файлов, например) - то можно было ничего не "разрушать".

  • Модель содержит в себе функции работы с базой и все. Сейчас .Net memory profiler гоняли - если честно, нифига не поняли. asp.net  cache тоже не добавил понимания - в нем лежит куча объектов((

    По сессиям - да. Был Васей Пупкиным, а стал после перезапуска пула Гостем. А вот другие данные, что были в сессии, кстати не пострадали. Я только сейчас об этом подумал :-[ Но, как я говорил выше этот путь не наш, перезапуск пула чреват длинным (сравнительно) ожиданием.

    UPD:

    Кстати, я тут подумал. На IIS последний раз выкладывался проект, собранный в конфигурации Debug. Это может влиять подобным образом на память? В этой конфигурации GS ведет себя, на сколько я понимаю, весьма лениво. же.

  • Пройдитесь по лабам от Tess. Там все не слишком сложно. Поиск утечки обычно сводится к просмотру статистики dumpheap -stat и поиска "текущего" типа - того, который встречается чаще всего(за исключением массивов и строк).

    Если пугает windbg - пользуйтесь студией, предварительно включив debug native code в свойствах проекта. Окно Immediate понимает команды windbg.

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

    Пользователей у вас вылогинивает не из-за потери сессии. Скорее всего используется forms authentication, а в ней токены подписываются ключем из секции machineKey. По умолчанию они генерируемые, уникальные для приложений, но в IIS7 почему-то перегенерируются при рестарте апппула. Сгенерируйте явные ключи и впишите в web.config. Генератор для облегчения жизни: http://aspnetresources.com/tools/keycreator.aspx

    • Помечено в качестве ответа Alexandr Kuznetsov 21 мая 2010 г. 3:10
  • Ммм.. Мы так и делали, собственно - !load sos.dll и вперед. Кстати, профайлер показывал что у нас больше всего строк в памяти. Только как с ними там бороться я не представляю. 

    У меня просто там сделана поддержка языков, локализации же лежат в xml-файлах, я не делал через стандартные ресурсы.

    По поводу вылогинивания пользователей - все верно, у нас так и сделано. Спасибо, хоть это подправлю =)

    Будем думать дальше, спасибо =)
  • Строки и массивы - всегда в конце списка dumpheap -stat. С ними надо бороться только если они явно висят в LOH.

    Почитай кусок System.String and array objects: http://blogs.msdn.com/tess/archive/2009/02/27/net-memory-leak-reader-email-are-you-really-leaking-net-memory.aspx

    Удачи :)
    • Помечено в качестве ответа Alexandr Kuznetsov 21 мая 2010 г. 3:12
  • Прочитал.. Вроде бы понятно.

    Значит будем искать утечку в других местах.

    Спасибо, она мне точно понадобится =)

    UPD В web.config стоит debug=true. Тесс советует это убрать, может как бы помочь. Пошел проверять..=)

  • Похоже я решил проблему. Вся загвоздка стояла в том что  стояло <compilation debug="true"> . Из-за этого память сжиралась в три горла, а дампы нечего такого не показывали :(

    Большое спасибо, PashaPash =) Ну и надо бы сказать спасибо Тесс, по ее наводкам я и решил проблему. Да и с windbg теперь имеем представление как работать. Урок получился знатный.

    • Помечено в качестве ответа Alexandr Kuznetsov 21 мая 2010 г. 3:13