Кто мне скажет, зачем выделили Views? Я вот что-то понять не могу, хватило бы адаптеров, имхо.

Минимальный проект с использованием System.AddIn

В предыдущей статье мы сделали дамп с помощью WinDbg. Далее, что с ним можно сделать? Наверно много, но меня интересовало только одно, а именно — память. Поэтому, я загнал дамп в .Net Memory Profiler.

Данный профайлер сказал мне, что из 7 гигов рама, у меня управляемой памяти всего 1.5 гига. Так как я был тупо уверен (без всяких на то указаний — это ошибка), что утечка именно в управляемой дотнетом памяти, то эту информацию я сразу отбросил и выкинул профайлер.

Пришлось гуглить и пытать по аське знакомых. Результаты:

“!eeheap -stat” — выдаст статистику по управляемым кучам. Предварительно надо загрузить расширение sos.dll. Посмотрев результаты, я понял, что управляемой памяти на самом деле всего полтора гига.

Дальнейшее было делом техники — зацепился из кода к GC Lua, стал выводить статистику по памяти в лог и убедился, что жрёт наш замечательный интерпретатор.

А вот пособие для нубов, как юзать WinDbg для отсечки утечек памяти.

Итак, условия задачи: есть 64битный (это важно) .NET процесс, штатный режим которого — 1-2 Gb Ram, иногда оно съедает 7-8 (больше на сервере нет просто). Задача: выяснить что же там такое, что сжирает эти лишние 6 гиг рама, найти и уничтожить, как обычно всё в общем.

На испытания поступили:

1. WinDbg + SOS (брать в составе нужного фреймворка) — брутальнейший отладчик от майкрософт с интерфейсом в духе «назад в 90е» и «я-vi», ибо практически всё управление через командную строку.
2. JetBrains dotTrace — новенький гламурный профайлер, писанный на шарпе, с блекджеком и шлюхами.
3. .Net Memory Profiler — понтов поменьше, чем у JetBrains, но интерфейс вполне приятный.

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

Запустил я WinDbg, увидел аццкое окошко, кучу непонятных букв и мегамануал и понял, что этот звездолёт я освою только в крайнем случае. Ну уж если совсем жопа будет. И отложил его подальше, благо он бесплатный, лежит — жрать не просит. Далее шёл фаворит — dotTrace.

Фаворит заупрямился сразу — к работающим процессам он не аттачится, видите ли там API херовое, поэтому у них API своё и надо запускать процесс из-под него. Ну раз так — значит так, нам то, что. Запускаем, эмулируем ситуацию, делаем дамп. Доттрейс думал долго. Минут 15, но дамп сделал (честь ему и хвала). Но дальше — финиш. Открывать его он отказался, сославшись на «Not enough memory». Я тупо посмотрел на свободных 6 гиг рама и ещё 20 гиг свопа, почесал в затылке и написал в саппорт.

добрый день.
у меня есть пара вопросов по dottrace
есть дампы по 900 метров файлы, снятые с процесса, который жрал примерно 2 гига рама. записывались только сами объекты, без колстеков, гарбадж коллектора и финалайзер инфы.
пытаемся открыть версией 3.1 этот дамп на сервере (16 гб рама, вин 2003 р2 сп2 х64, 2 xeon каких-то). доттрейс падает с not enough memory.
что у нас не так?

Ответ меня сразил наповал:

слишком большой снепшот. dT 3.1 — 32-битное приложение, ей 16 физических гигов не сильно помогут

Как замечательно. Скромно умолчим, что качал я конечно версию, которая помечена на сайте как 64битное приложение. Для софта по 500 баксов за одно место, это несколько непонятно.

Ну, да ладно. Выкинув поделку от Jetbrains, я взялся за .Net Memory Profiler. Создателям возможная кривость Debugging API не помешала и профайлер умеет как цепляться к существующим процессам, так и запускать из под себя их. Поигравшись по мелочи с настройками, пытаемся сделать дамп процесса. Профайлер думал 2 часа, меня проклинали тестеры, но дамп сделать не смог. Стоит, правда, в два раза дешевле — 250 баксов.

Добрый коллега посоветовал для снятия дампа ClrDump, бесплатную тулзу от спецов по отладке. Тулза порадовала быстрой работой, произведя дамп в 0 (ноль) байт с процесса в 7 гигов. Немедленно была составлена жалоба в суппорт:

Hello.

I wonder why ClrDump produces dump of zero size? My process have 7 Gb of ram and I want to look why.

Command string: ClrDump 3684 sil.dmp Max.

What am I doing wrong?

There is enough space on HDD (about 100 Gb of free space)

Regards, Anatoly Popov.

Автор сначала вежливо ответил, что он в отпуске, но на следующей неделе рассмотрит проблему внимательно. Не обманул, но ответ уже не удивлял:

Hello Anatoly,

Is your process 64-bit? If so, ClrDump cannot create a dump for it (limitations of 32-bit DbgHelp.dll). Unfortunately, there is no 64-bit version of ClrDump (it was created when 64-bit systems were not widespread, and now I don’t have time to upgrade it).

As a workaround, it should be possible to write your own tool that would be built as 64-bit executable, load 64-bit DbgHelp.dll and create the dump. Three function calls are needed: OpenProcess (open the target process), CreateFile(create the dump file), MiniDumpWriteDump with the proper parameters to create the dump. I can send you a sample code if you want.

Regards,

Oleg

Но тут хоть претензий предъявить нельзя — тулза бесплатная, делалась для себя. Так что ладно.

А что же наш звездолёт, который WinDbg? Звездолёт отлично делает дампы со скоростью, примерно равной скорости записи на винт, работает как часы, даром, что бесплатный, древний, да от майкрософта.

Да, кстати, в Vista и 2008 сервере так трахаться не надо. Открываем Task Manager, тыркаем правой кнопкой в процесс, выбираем Create Dump, вуаля, всё готово.

Приятной вам работы.