Microsoft открывает новый проект GC Perf! Теперь это часть репозитория производительность .Net.
Прежде всего, позвольте отметить, что целевой аудиторией этой инфраструктуры, помимо очевидной (то есть тех, кто вносит изменения в производительность GC), являются люди, которым необходимо провести углубленный анализ GC / производительности управляемой памяти и / или построить автоматизацию вокруг этого. Таким образом, предполагается, что у вас уже есть достаточное количество знаний о том, что искать при анализе.
Во-вторых, в инфраструктуре много движущихся частей, и, поскольку она все еще находится в стадии разработки, я не удивлюсь, если вы столкнетесь с проблемами при ее использовании. Пожалуйста, будьте терпеливы, когда мы решаем проблемы! У нас нет много ресурсов, поэтому мы не сможем получить к ним доступ сразу. И, конечно, если вы хотите внести свой вклад, для нас это будет очень ценно. Я знаю многих людей, которые читают это, увлечены анализом производительности и проделали огромную работу по созданию / улучшению ее для .NET. А внесение вклада в анализ производительности – это фантастический способ узнать о настройке GC, если вы хотите начать с чего-то. Поэтому я настоятельно рекомендую вам внести свой вклад!
Топология
Мы обсудили, хотим ли мы открыть исходный код для этого в своем собственном репо, и пришли к выводу, что мы не будем делать это в основном из-за логистических соображений, поэтому это стало частью репозитория perf в каталоге “src/benchmarks/gc” (к которому я буду обращаться в качестве корневого каталога). Это не зависит от чего-либо это означает, что вам не нужно ничего создавать вне этого каталога, если вы просто хотите использовать инфракрасную часть GC perf.
Файл readme.md в корневом каталоге описывает общий рабочий процесс и основное использование. Дополнительную документацию можно найти в каталоге документов.
Есть 2 основных компонента инфраструктуры:
Запуск тестов производительности
Это запускает наши собственные тесты перфорирования – это для людей, которым нужно действительно вносить изменения производительности в GC. Это обеспечивает следующие функциональные возможности –
■ Задание различных аргументов командной строки для генерации разных характеристик perf в тестах, например, разных коэффициентов построения для SOH / LOH и разных коэффициентов пиннинга;
■ Определение сборок для сравнения;
■ Задание различных сред, например, различных переменных env для указания конфигураций GC, работы в контейнерах или ситуаций с высокой загрузкой памяти;
■ Задание различных параметров для сбора трасс с помощью, GCCollectOnly или ThreadTime.
Вы указываете все это в том, что мы называем стендовым файлом (это файл .yaml, но на самом деле это может быть что угодно – мы просто выбрали .yaml). Мы также предоставляем конфигурации для базовых сценариев перфорации, поэтому при внесении изменений их следует запускать, чтобы убедиться, что все не регрессирует.
Вам не нужно запускать тесты – вы можете запускать все что угодно, если только вы можете указать это как программу командной строки, и при этом использовать все остальное, что мы предоставляем, например запуск в контейнере.
Это задокументировано в файле readme, и я буду говорить об этом более подробно в одной из будущих записей в блоге.
Источник для этого находится в exec dir.
Анализ производительности
Это может использоваться без бегущей части вообще. Если вы уже собрали следы перфектов, вы можете использовать их для анализа. Я предполагаю, что больше людей заинтересуются этим, чем бегущей частью, поэтому я посвятим больше контента анализу. В последней публикации GC я уже говорил о том, что вы можете сделать это с помощью Jupyter Notebook (я покажу больше примеров с реальным кодом в следующих записях блога). На этот раз я сосредоточусь на фактической настройке и использовании команд, которые мы предоставляем. Не стесняйтесь попробовать это сейчас
Источник находится в analysis.
Настройка анализа
После копирования репозитория с производительностью dotnet вы увидите файл readme в директории gc infra root. Настройка подробно описана в этом документе. Если вам просто нужен анализ, вам не нужно выполнять все шаги по настройке. Единственные шаги, которые вам нужны –
■ Установите Python. 3.7 является минимально необходимой версией и рекомендуемой версией. 3.8 есть проблемы с Jupyter Notebook. Я хотел указать на это, потому что 3.8 – последняя версия релиза на странице python.
■ Установите необходимые библиотеки python – вы можете сделать это через «py -m pip install -r src / needs.txt», как сказано в readme, и если ошибок не возникает, отлично; но вы можете получить ошибки с pythonnet, который является обязательным для анализа. На самом деле установка pythonnet может быть настолько хлопотной, что мы посвятили ей целый документ. Я надеюсь, что однажды в VSCode будет достаточно хороших библиотек для построения диаграмм на С#, и С# в Jupyter Notebook, будут работать, поэтому нам больше не понадобится pythonnet.
■ Создайте библиотеку анализа С#, запустив «dotnet publish» в каталоге src\analysis\managed-lib dir.
Укажите, что анализировать
Допустим, вы собрали трассировку ETW (это может быть из .NET или .NET Core) вам нужно его проанализировать, какой процесс будет для вас интересен (в Linux вы собираете события для интересующего процесса с помощью dotnet-trace, но поскольку инфраструктура работает как в Windows, так и в Linux, это те же шаги). Определение процесса для анализа означает простую запись файла .yaml, который мы называем «файлом статуса теста». Из файла readme для файла состояния теста, который вы пишете только для анализа, нужны только эти 3 строки:
success: true
trace_file_name: x.etl # A relative path. Should generally match the name of this file.
process_id: 1234 # If you don’t know this, use the print-processes command for a list
Вы можете задаться вопросом, зачем вообще указывать строку «success: true» – это просто потому, что нижеприведенная схема также может использоваться для анализа результатов выполнения тестов. Когда вы запускаете множество тестов и анализируете их результаты в области автоматизации, мы ищем эту строку и анализируем только те, которые были успешными.
Возможно, вы уже знаете PID процесса, который вы хотите проанализировать с помощью таких инструментов как PerfView, мы стремимся к тому, чтобы инфраструктура использовалась автономно, без запуска других инструментов, поэтому есть команда, которая выводит PID процессов, содержащихся в трассировке.
Мы действительно хотели, чтобы инфраструктура обеспечивала значимую встроенную помощь, поэтому, когда вы задаетесь вопросом, как сделать что-то, вы можете найти это в справке. Чтобы получить список всех команд, просто попросите помощи верхнего уровня в корневом каталоге –
C:\perf\src\benchmarks\gc>py . help
Сначала прочтите README.md. Для помощи с отдельной командой используйте py . command-name –help. (Вы можете пропустить —help –hidden чтобы увидеть скрытые аргументы.)
Запустите команду
[пропустить]
команды анализа
Команды для анализа результатов теста (файлы трассировки). Чтобы сравнить небольшое количество конфигурации, используйте diff. Для сравнения используйте chart-configs. Для подробного анализа одной трассы используйте analyze-single или chart-individual-gcs.
analysis-single: с учетом одной трассы, показателей печати и, при необходимости, показателей для отдельных GC.
analyse-single-gc: выводит подробную информацию об одном GC в пределах одной трассы.
[больше вывода опущено и выполнено некоторое форматирование вывода]
(Я прошу прощения за форматирование – меня поражает, что у нас, похоже, нет приличной программы редактирования html для ведения блогов, а написание блога в основном состоит из ручного написания html, что очень больно)
Как говорится в справке высокого приоритета, вы можете получить помощь по конкретным командам. Поэтому мы последуем этому предложению и сделаем
C: \ perf \ src \ benchmarks \ gc> py. помочь печатным процессам
Напечатайте все PID процесса и имена из файла трассировки.
[больше выходных данных пропущено; Я также сделал некоторое форматирование, чтобы избавиться от некоторых столбцов, чтобы строки не были слишком длинными]
В качестве примера я специально выбрал тест, который, по моему мнению, не подходит для работы с Server GC, потому что он имеет только один поток, поэтому я ожидаю увидеть некоторый дисбаланс потоков. Я знаю, что дисбаланс возникнет, когда мы отметим объекты старшего поколения, удерживающие объекты молодого поколения, поэтому я буду использовать команду chart-individual-gcs, чтобы показать мне, сколько времени потребовалась каждому потоку.
C:\perf\src\benchmarks\gc>py . chart-individual-gcs C:\traces\fragment\fragment.yaml –x-single-gc-metric Index –y-single-heap-metrics MarkOlderMSec
Это покажет 8 куч. Подумайте о прохождении —show-n-heaps.
Конечно, одна из куч всегда занимает значительно больше времени, чтобы пометить объекты молодого поколения, на которые ссылаются объекты более старого поколения, и чтобы убедиться, что это не из-за каких-то других факторов, я также посмотрел, сколько повышается за кучу –
C:\perf\src\benchmarks\gc>py . chart-individual-gcs C:\traces\fragment\fragment.yaml –x-single-gc-metric Index –y-single-heap-metrics MarkOlderPromotedMB
Это покажет 8 куч. Подумайте о прохождении —show-n-heaps.
Это подтверждает теорию – потому что мы пометили значительно больше одной кучи, что привело к тому, что эта куча потратила значительно больше времени на маркировку.
Эта трассировка была взята с последней версии настольного CLR. В текущей версии coreclr мы можем лучше справиться с этой ситуацией, но я оставлю это на следующий день, так как сегодня я хотел сосредоточиться на инструментах.
Вот пример .md, который показывает примеры использования некоторых команд. Обратите внимание, что анализ объединения еще не проверен – пиар вышел, и я хотел потратить больше времени на CR, прежде чем объединять его.
Источник