Web Dump Stack Dump Tool для ASP.NET, используя Mdbg?

Дэн Фарино (Dan Farino), главный системный архитектор на MySpace.com, представляет отличную презентацию, демонстрирующую веб-инструмент для создания дампов стека, который каталогизирует все потоки, выполняемые в данном процессе (что они делают, как долго они выполняются и т. Д..)

Их методы также представлены на сайте highscalability.com:

  • PerfCollector.
    Централизованный сбор данных о производительности через UDP. Более надежен, чем Windows, и позволяет любому клиенту подключаться и просматривать статистику.
  • Веб-инструмент для создания дампов стека.
    Можно щелкнуть правой кнопкой мыши на проблемном сервере и получить дамп стека управляемых потоков.Net. Используется для того, чтобы подключить RDC к системе и подключить отладчик, а через 1/2 получить ответ. Медленный, несчетный и утомительный. Не только дамп стека, дает много контекста о том, что делает поток. Устранение неполадок проще, поскольку вы можете видеть, что 90 потоков заблокированы в базе данных, поэтому база данных может быть недоступна.
  • Инструмент для создания дампа кучи.
    Сбрасывает все выделения памяти. Очень полезно для разработчиков. Сэкономьте часы, делая это вручную. • Профилировщик. Отслеживает запрос от начала до конца и создает отчет. Смотрите URL, методы, статус, все, что поможет вам определить медленный запрос. Рассматривает утверждения о блокировках, выдается много исключений, все, что может быть интересно. Очень легкий вес Он работает на одной коробке в каждом VIP (группа из 100 серверов) в производстве. Образцы 1 нить каждые 10 секунд. Всегда трассировка в фоновом режиме.

Вопрос в том, какие инструменты необходимы для создания веб-утилиты стека дампов для ASP.NET? Для удобства давайте предположим, что *.aspx, размещенный в целевом домене приложений, способный выводить все управляемые стеки вызовов в этом процессе, является достаточным.

Есть несколько постов, посвященных использованию Mdbg (отладчик для управляемого кода, полностью написанного на C#/IL, который начал поставляться с CLR 2 SDK) и сборке mdbgcore, обычно находящейся в C: \ Program Files \ Microsoft Visual Studio 8 \ SDK \ v2.0 \ Bin:

Будет ли решение просто ссылаться на эту сборку для получения желаемого результата? Какое влияние окажет операция "перечислить все управляемые стеки вызовов" на работающий процесс, обслуживающий производственный трафик?

Источник

2 ответа

Я считаю, что API профилирования.Net - это путь.

Посмотрите на проект SlimTune в Google Code, чтобы получить живой пример с источниками, которые вы можете проверить, как адаптироваться и улучшать работу в сценарии Asp.NET.

С уважением Массимо

Источник

С помощью API профилирования.Net вы должны остановить сервер, и он требует много ресурсов ЦП (но он дает вам полный контроль над всеми вызываемыми методами).

Я думаю, что наиболее "легким" решением будет сделать это с помощью MDbg, я собрал очень маленькое, но полезное маленькое приложение под названием StackDump, которое выполняет следующие действия: 1) Отладчик останавливает приложение и генерирует список всех стеков CLR, запущенных для процесс. 2) Приложение запускается снова. Эта операция является быстрой и может (возможно) быть выполнена на работающем производственном сервере с неизмененным рабочим кодом.

Это всего лишь 80 строк кода.Net для управления этим. Я опубликовал исходный код на Codeplex.

Источник
Другие вопросы по тегам