В .NET Core 3.0 мы представляем набор инструментов, которые используют новые возможности среды выполнения .NET, которые упрощают диагностику и решение проблем с производительностью.
Эти возможности помогут вам ответить на некоторые распространенные вопросы диагностики, которые могут у вас возникнуть:
Со временем может возникать утечка памяти в приложении, что в конечном итоге приводит к OutOfMemoryException. В других случаях, некоторый проблемный код может привести к скачку загрузки процессора. Это лишь некоторые из проблем, которые вы можете активно идентифицировать с помощью метрик.
Метрики представляют собой данные измерений за промежуток времени. Данные метрик позволяют вам наблюдать за состоянием вашей системы на высоком уровне. В отличие от .NET Framework на Windows, .NET Core не генерирует счетчики производительности. Вместо этого мы ввели новый способ генерирования метрик в .NET Core через EventCounter API.
EventCounters предлагают улучшение, по сравнению с счетчиками производительности Windows, поскольку теперь они используются во всех ОС, где поддерживается .NET Core. Кроме того, в отличие от счетчиков производительности, они также могут использоваться в средах с низким уровнем привилегий (например, при развертывании xcopy). К сожалению, отсутствие такого инструмента, как Performance Monitor (perfmon), затрудняет отображение этих показателей в режиме реального времени.
dotnet-counters
В 3.0-preview5 мы представляем новый инструмент командной строки для наблюдения за метриками, генерируемыми приложениями .NET Core в режиме реального времени.
Вы можете установить этот инструмент, выполнив следующую команду
В приведенном ниже примере, мы видим, что загрузка ЦП и память нашего приложения увеличиваются, когда мы начинаем нагружать на наше веб-приложение.
Для получения подробных инструкций о том, как использовать этот инструмент, посмотрите readme-файл в проекте с dotnet-counters. Для известных ограничений dotnet-counters, посмотрите на открытые проблемы на GitHub.
В то время как метрики помогают идентифицировать возникновение аномального поведения, они предлагают мало понимания того, что пошло не так. Чтобы ответить на вопрос, почему ваше приложение имеет аномальное поведение, вам нужно собрать дополнительную информацию через трассировки. Например, CPU Profiles, собранные с помощью трассировки, могут помочь вам определить hot path в вашем коде.
Трассировки — это неизменные записи дискретных событий с отметкой времени. Трассировки содержат локальный контекст, который позволяет лучше определить судьбу системы. Традиционно .NET Framework (и фреймворки, такие как ASP.NET) генерировали диагностические трассировки о своих внутренних компонентах с помощью Event Tracing for Windows (ETW). В .NET Core эти трассировки были записаны в ETW для Windows и LTTng для Linux.
dotnet-trace
В версии 3.0-preview5 каждое приложение .NET Core открывает дуплексный канал с именем EventPipe (сокет домена Unix в * nix или именованный канал в Windows), через который он может отправлять события. Пока мы все еще работаем над протоколом контроллера, dotnet-trace реализует предварительную версию этого протокола.
Вы можете установить этот инструмент, выполнив следующую команду
В приведенном выше примере я запускаю трассировку dotnet с профилем по умолчанию, который включает события профилировщика ЦП и runtime события .NET.
В дополнение к событиям по умолчанию вы можете включить дополнительных провайдеров на основе исследование, которое вы пытаетесь выполнить.
В результате запуска dotnet trace вы получаете файл .netperf. Этот файл содержит события времени выполнения и выборки стеков ЦП, которые можно визуализировать в perfview. Следующее обновление Visual Studio (16.1) также добавит поддержку для визуализации этих трассировок.
Если вы работаете в OS X или Linux, то при записи трассировки, вы можете преобразовать файлы .netperf в файлы .speedscope.json, которые можно визуализировать с помощью Speedscope.app.
Вы можете преобразовать существующую трассировку, выполнив следующую команду:
Изображение ниже показывает диаграмму, визуализирующую трассировку, которою мы только что получили.
Для получения подробных инструкций о том, как использовать этот инструмент, посмотрите readme-файл. Для известных ограничений с dotnet-trace, посмотрите на открытые проблемы на GitHub.
В некоторых случаях невозможно установить причину аномального поведения, просто отслеживая процесс. В случае сбоя процесса или ситуаций, когда нам может потребоваться дополнительная информация, например доступ ко всей куче процесса, дамп процесса может быть более подходящим для анализа.
Дамп — это запись состояния рабочей виртуальной памяти процесса, обычно захваченного при неожиданном его завершении. Диагностика дампов ядра обычно используется для выявления причин сбоев приложения или непредвиденного поведения.
Традиционно вы полагались на свою операционную систему для получения дампа при сбое приложения (например, отчетов об ошибках Windows) или использовали инструмент, такой как procdump, для захвата дампа при выполнении определенных критериев запуска.
До сих пор проблема с захватом дампов с помощью .NET в Linux заключалась в том, что захват дампов с помощью gcore или отладчика приводил к очень большим дампам, поскольку существующие инструменты не знали, какие страницы виртуальной памяти обрезать в процессе .NET Core.
Кроме того, было сложно проанализировать эти дампы даже после того, как вы их собрали, поскольку требовалось приобрести отладчик и настроить его для загрузки sos, расширения отладчика для .NET.
dotnet-dump
В 3.0.0-preview5, мы представляем новый инструмент, который позволяет собирать и анализировать дампы процессов как в Windows, так и в Linux.
dotnet-dump все еще находится в активной разработке, и в таблице ниже показано, какие функции в настоящее время поддерживаются в каких операционных системах.
Вы можете установить этот инструмент, выполнив следующую команду
После того, как вы установили dotnet-dump, вы можете захватить дамп процесса, выполнив следующую команду
В Linux полученный дамп можно проанализировать, загрузив полученный дамп с помощью следующей команды
В следующем примере я пытаюсь определить ASP.NET Core Hosting Environment дампа
Для получения подробных инструкций о том, как использовать этот инструмент, посмотрите readme-файл. Для известных ограничений с dotnet-dump, посмотрите на открытые проблемы на GitHub.
Спасибо за испытания новых инструментов диагностики в .NET Core 3.0. Пожалуйста, продолжайте давать нам отзывы, либо в комментариях, либо на GitHub. Мы внимательно выслушиваем и будем вносить изменения, основываясь на ваших отзывах.
Эти возможности помогут вам ответить на некоторые распространенные вопросы диагностики, которые могут у вас возникнуть:
- Является ли мое приложение работоспособным?
- Почему мое приложение имеет аномальное поведение?
- Почему мое приложение крашится?
Является ли мое приложение работоспособным?
Со временем может возникать утечка памяти в приложении, что в конечном итоге приводит к OutOfMemoryException. В других случаях, некоторый проблемный код может привести к скачку загрузки процессора. Это лишь некоторые из проблем, которые вы можете активно идентифицировать с помощью метрик.
Метрики
Метрики представляют собой данные измерений за промежуток времени. Данные метрик позволяют вам наблюдать за состоянием вашей системы на высоком уровне. В отличие от .NET Framework на Windows, .NET Core не генерирует счетчики производительности. Вместо этого мы ввели новый способ генерирования метрик в .NET Core через EventCounter API.
EventCounters предлагают улучшение, по сравнению с счетчиками производительности Windows, поскольку теперь они используются во всех ОС, где поддерживается .NET Core. Кроме того, в отличие от счетчиков производительности, они также могут использоваться в средах с низким уровнем привилегий (например, при развертывании xcopy). К сожалению, отсутствие такого инструмента, как Performance Monitor (perfmon), затрудняет отображение этих показателей в режиме реального времени.
dotnet-counters
В 3.0-preview5 мы представляем новый инструмент командной строки для наблюдения за метриками, генерируемыми приложениями .NET Core в режиме реального времени.
Вы можете установить этот инструмент, выполнив следующую команду
dotnet tool install --global dotnet-counters --version 1.0.3-preview5.19251.2В приведенном ниже примере, мы видим, что загрузка ЦП и память нашего приложения увеличиваются, когда мы начинаем нагружать на наше веб-приложение.
Для получения подробных инструкций о том, как использовать этот инструмент, посмотрите readme-файл в проекте с dotnet-counters. Для известных ограничений dotnet-counters, посмотрите на открытые проблемы на GitHub.
Почему мое приложение имеет аномальное поведение?
В то время как метрики помогают идентифицировать возникновение аномального поведения, они предлагают мало понимания того, что пошло не так. Чтобы ответить на вопрос, почему ваше приложение имеет аномальное поведение, вам нужно собрать дополнительную информацию через трассировки. Например, CPU Profiles, собранные с помощью трассировки, могут помочь вам определить hot path в вашем коде.
Трассировка
Трассировки — это неизменные записи дискретных событий с отметкой времени. Трассировки содержат локальный контекст, который позволяет лучше определить судьбу системы. Традиционно .NET Framework (и фреймворки, такие как ASP.NET) генерировали диагностические трассировки о своих внутренних компонентах с помощью Event Tracing for Windows (ETW). В .NET Core эти трассировки были записаны в ETW для Windows и LTTng для Linux.
dotnet-trace
В версии 3.0-preview5 каждое приложение .NET Core открывает дуплексный канал с именем EventPipe (сокет домена Unix в * nix или именованный канал в Windows), через который он может отправлять события. Пока мы все еще работаем над протоколом контроллера, dotnet-trace реализует предварительную версию этого протокола.
Вы можете установить этот инструмент, выполнив следующую команду
dotnet tool install --global dotnet-trace--version 1.0.3-preview5.19251.2В приведенном выше примере я запускаю трассировку dotnet с профилем по умолчанию, который включает события профилировщика ЦП и runtime события .NET.
В дополнение к событиям по умолчанию вы можете включить дополнительных провайдеров на основе исследование, которое вы пытаетесь выполнить.
В результате запуска dotnet trace вы получаете файл .netperf. Этот файл содержит события времени выполнения и выборки стеков ЦП, которые можно визуализировать в perfview. Следующее обновление Visual Studio (16.1) также добавит поддержку для визуализации этих трассировок.
Если вы работаете в OS X или Linux, то при записи трассировки, вы можете преобразовать файлы .netperf в файлы .speedscope.json, которые можно визуализировать с помощью Speedscope.app.
Вы можете преобразовать существующую трассировку, выполнив следующую команду:
dotnet trace convert <input-netperf-file>Изображение ниже показывает диаграмму, визуализирующую трассировку, которою мы только что получили.
Для получения подробных инструкций о том, как использовать этот инструмент, посмотрите readme-файл. Для известных ограничений с dotnet-trace, посмотрите на открытые проблемы на GitHub.
Почему мое приложение крашится?
В некоторых случаях невозможно установить причину аномального поведения, просто отслеживая процесс. В случае сбоя процесса или ситуаций, когда нам может потребоваться дополнительная информация, например доступ ко всей куче процесса, дамп процесса может быть более подходящим для анализа.
Анализ дампа
Дамп — это запись состояния рабочей виртуальной памяти процесса, обычно захваченного при неожиданном его завершении. Диагностика дампов ядра обычно используется для выявления причин сбоев приложения или непредвиденного поведения.
Традиционно вы полагались на свою операционную систему для получения дампа при сбое приложения (например, отчетов об ошибках Windows) или использовали инструмент, такой как procdump, для захвата дампа при выполнении определенных критериев запуска.
До сих пор проблема с захватом дампов с помощью .NET в Linux заключалась в том, что захват дампов с помощью gcore или отладчика приводил к очень большим дампам, поскольку существующие инструменты не знали, какие страницы виртуальной памяти обрезать в процессе .NET Core.
Кроме того, было сложно проанализировать эти дампы даже после того, как вы их собрали, поскольку требовалось приобрести отладчик и настроить его для загрузки sos, расширения отладчика для .NET.
dotnet-dump
В 3.0.0-preview5, мы представляем новый инструмент, который позволяет собирать и анализировать дампы процессов как в Windows, так и в Linux.
dotnet-dump все еще находится в активной разработке, и в таблице ниже показано, какие функции в настоящее время поддерживаются в каких операционных системах.
Вы можете установить этот инструмент, выполнив следующую команду
dotnet tool install --global dotnet-dump --version 1.0.3-preview5.19251.2После того, как вы установили dotnet-dump, вы можете захватить дамп процесса, выполнив следующую команду
sudo $HOME/.dotnet/tools/dotnet-dump collect -p <pid>В Linux полученный дамп можно проанализировать, загрузив полученный дамп с помощью следующей команды
dotnet dump analyze <dump-name>В следующем примере я пытаюсь определить ASP.NET Core Hosting Environment дампа
Для получения подробных инструкций о том, как использовать этот инструмент, посмотрите readme-файл. Для известных ограничений с dotnet-dump, посмотрите на открытые проблемы на GitHub.
Заключение
Спасибо за испытания новых инструментов диагностики в .NET Core 3.0. Пожалуйста, продолжайте давать нам отзывы, либо в комментариях, либо на GitHub. Мы внимательно выслушиваем и будем вносить изменения, основываясь на ваших отзывах.
