Ladění vysokého využití procesoru v .NET Core

Tento článek se vztahuje na: ✔️ .NET Core 3.1 SDK a novější verze

V tomto kurzu se dozvíte, jak ladit scénář nadměrného využití procesoru. Pomocí poskytnutého příkladu ASP.NET úložiště zdrojového kódu webové aplikace Core můžete záměrně způsobit zablokování. Koncový bod přestane reagovat a dojde k nahromadění vláken. Dozvíte se, jak můžete pomocí různých nástrojů diagnostikovat tento scénář několika klíčovými částmi diagnostických dat.

V tomto kurzu:

  • Zkoumání vysokého využití procesoru
  • Určení využití procesoru pomocí čítačů dotnet
  • Použití trasování dotnet-trace pro generování trasování
  • Výkon profilu v nástroji PerfView
  • Diagnostika a řešení nadměrného využití procesoru

Požadavky

Kurz používá:

Čítače procesoru

Než se pokusíte shromáždit diagnostická data, musíte sledovat vysokou podmínku procesoru. Spusťte ukázkovou aplikaci pomocí následujícího příkazu z kořenového adresáře projektu.

dotnet run

K vyhledání ID procesu použijte následující příkaz:

dotnet-trace ps

Poznamenejte si ID procesu z výstupu příkazu. ID našeho procesu bylo 22884, ale vaše bude jiné. Pokud chcete zkontrolovat aktuální využití procesoru , použijte příkaz nástroje dotnet-counters :

dotnet-counters monitor --refresh-interval 1 -p 22884

Jedná se refresh-interval o počet sekund mezi hodnotami čítače dotazování procesoru. Výstup by měl vypadat přibližně takto:

Press p to pause, r to resume, q to quit.
    Status: Running

[System.Runtime]
    % Time in GC since last GC (%)                         0
    Allocation Rate / 1 sec (B)                            0
    CPU Usage (%)                                          0
    Exception Count / 1 sec                                0
    GC Heap Size (MB)                                      4
    Gen 0 GC Count / 60 sec                                0
    Gen 0 Size (B)                                         0
    Gen 1 GC Count / 60 sec                                0
    Gen 1 Size (B)                                         0
    Gen 2 GC Count / 60 sec                                0
    Gen 2 Size (B)                                         0
    LOH Size (B)                                           0
    Monitor Lock Contention Count / 1 sec                  0
    Number of Active Timers                                1
    Number of Assemblies Loaded                          140
    ThreadPool Completed Work Item Count / 1 sec           3
    ThreadPool Queue Length                                0
    ThreadPool Thread Count                                7
    Working Set (MB)                                      63

Když je webová aplikace spuštěná hned po spuštění, procesor se vůbec nespotřebovává a hlásí se na 0%adrese . Přejděte na trasu api/diagscenario/highcpu jako 60000 parametr trasy:

https://localhost:5001/api/diagscenario/highcpu/60000

Teď spusťte příkaz dotnet-counters znovu. Pokud vás zajímá monitorování pouze cpu-usage čítače, přidejte do předchozího příkazu příkaz --counters System.Runtime[cpu-usage]. Nejste si jistí, jestli procesor spotřebovává, takže budeme monitorovat stejný seznam čítačů jako výše, abychom ověřili, že hodnoty čítačů jsou v očekávaném rozsahu pro naši aplikaci.

dotnet-counters monitor -p 22884 --refresh-interval 1

Měli byste vidět zvýšení využití procesoru, jak je znázorněno níže (v závislosti na hostitelském počítači očekáváte různé využití procesoru):

Press p to pause, r to resume, q to quit.
    Status: Running

[System.Runtime]
    % Time in GC since last GC (%)                         0
    Allocation Rate / 1 sec (B)                            0
    CPU Usage (%)                                         25
    Exception Count / 1 sec                                0
    GC Heap Size (MB)                                      4
    Gen 0 GC Count / 60 sec                                0
    Gen 0 Size (B)                                         0
    Gen 1 GC Count / 60 sec                                0
    Gen 1 Size (B)                                         0
    Gen 2 GC Count / 60 sec                                0
    Gen 2 Size (B)                                         0
    LOH Size (B)                                           0
    Monitor Lock Contention Count / 1 sec                  0
    Number of Active Timers                                1
    Number of Assemblies Loaded                          140
    ThreadPool Completed Work Item Count / 1 sec           3
    ThreadPool Queue Length                                0
    ThreadPool Thread Count                                7
    Working Set (MB)                                      63

Po celou dobu trvání požadavku se využití procesoru přesune kolem zvýšeného procenta.

Tip

Pokud chcete vizualizovat ještě vyšší využití procesoru, můžete tento koncový bod uplatnit na několika kartách prohlížeče současně.

V tomto okamžiku můžete bezpečně říci, že procesor běží vyšší, než očekáváte. Identifikace účinků problému je klíčem k nalezení příčiny. K nalezení příčiny problému použijeme kromě diagnostických nástrojů také účinek vysoké spotřeby procesoru.

Analýza vysokého využití procesoru pomocí Profileru

Při analýze aplikace s vysokým využitím procesoru potřebujete diagnostický nástroj, který vám poskytne přehled o tom, co kód dělá. Obvyklou volbou je profiler a existují různé možnosti profileru, ze které si můžete vybrat. dotnet-trace lze použít ve všech operačních systémech, ale jeho omezení předsudků bezpečných bodů a volání pouze spravovaných volání vedou k obecnějším informacím v porovnání s profilerem podporujícím jádro, jako je "perf" pro Linux nebo ETW pro Windows. Pokud vaše šetření výkonu zahrnuje jenom spravovaný kód, bude obecně dotnet-trace dostačující.

Nástroj perf lze použít ke generování profilů aplikací .NET Core. Tento nástroj si ukážeme, i když se dá použít i dotnet-trace. Ukončete předchozí instanci ukázkového cíle ladění.

Nastavte proměnnou DOTNET_PerfMapEnabled prostředí tak, aby aplikace .NET vytvořila map soubor v /tmp adresáři. Tento map soubor se používá perf k mapování adres procesoru na funkce generované JIT podle názvu. Další informace najdete v tématu Export map výkonu a výpisů paměti jit.

Poznámka:

.NET 6 standardizuje předponu DOTNET_ místo COMPlus_ proměnných prostředí, které konfigurují chování za běhu .NET. Předpona COMPlus_ ale bude i nadále fungovat. Pokud používáte předchozí verzi modulu runtime .NET, měli byste stále používat předponu COMPlus_ pro proměnné prostředí.

Spusťte ukázkový cíl ladění ve stejné relaci terminálu.

export DOTNET_PerfMapEnabled=1
dotnet run

Znovu si procvičte koncový bod rozhraní API s vysokým využitím procesoru (https://localhost:5001/api/diagscenario/highcpu/60000). Během 1minutového požadavku spusťte perf příkaz s ID procesu:

sudo perf record -p 2266 -g

Příkaz perf spustí proces shromažďování výkonu. Nechte ho běžet asi 20 až 30 sekund a pak stisknutím ctrl+C ukončete proces shromažďování. K zobrazení výstupu trasování můžete použít stejný perf příkaz.

sudo perf report -f

Graf plamene můžete také vygenerovat pomocí následujících příkazů:

git clone --depth=1 https://github.com/BrendanGregg/FlameGraph
sudo perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > flamegraph.svg

Tento příkaz vygeneruje flamegraph.svg , že můžete zobrazit v prohlížeči a prošetřit problém s výkonem:

Flame graph SVG image

Analýza dat s vysokým využitím procesoru pomocí sady Visual Studio

Všechny soubory *.nettrace je možné analyzovat v sadě Visual Studio. Pokud chcete analyzovat soubor Linux *.nettrace v sadě Visual Studio, přeneste soubor *.nettrace kromě dalších potřebných dokumentů na počítač s Windows a pak otevřete soubor *.nettrace v sadě Visual Studio. Další informace najdete v tématu Analýza dat využití procesoru.

Viz také

Další kroky