{"id":23184,"date":"2014-12-22T03:02:00","date_gmt":"2014-12-22T03:02:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/maoni\/2014\/12\/22\/gc-etw-events-1\/"},"modified":"2021-09-30T16:11:01","modified_gmt":"2021-09-30T23:11:01","slug":"gc-etw-events-1","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/gc-etw-events-1\/","title":{"rendered":"GC ETW events – 1"},"content":{"rendered":"

GC ETW series –<\/span><\/strong><\/p>\n

GC ETW Events – Part 1<\/span><\/a> (this post)<\/span><\/p>\n

GC ETW Events – Part 2<\/span><\/a><\/p>\n

GC ETW Events – Part 3<\/span><\/a><\/p>\n

GC ETW Events – Part 4<\/span><\/a><\/p>\n

Processing GC ETW Events Programmatically with the GLAD Library<\/span><\/a><\/p>\n

A lot of people have mentioned to me that I have not posted anything for a long time. I do realize it and do appreciate being asked to write more. Well, it's end of year and I am starting vacation so I thought I'd write something light that perhaps makes good reading around Christmas time \ud83d\ude42<\/span><\/p>\n

Perf counters vs ETW events<\/span><\/strong> <\/span><\/p>\n

Perf counters and ETW events, like anything else, each have their pros and cons. In my <\/span>Defrag Tools series of videos<\/span><\/a> I mentioned that I really would like folks to start using ETW (via the <\/span>PerfView<\/span><\/a> tool) if they haven't. I would state that again here because ETW just gives you richer info that you simply cannot get with perf counters. And if you only get the basic GC events, the overhead is very, very low that you could afford to have it on in your production environment. So what's the con? Well, ETW is a newer thing (internally at MS many groups have started using ETW events, perhaps for a long time now; but clearly there are still groups that are using perf counters and not ETW events) which means there's a learning curve. And the learning curve of using ETW is steeper than what you had with perf counters. I'd like to think that the PerfView made that fairly easy to get you started though. Aside from the less rich info, perf counters, as I explained <\/span>here<\/span><\/a>, also suffer from the precision problem. Just last week I had someone asking me why he's seeing % time in GC being 99% for a few minutes straight. It was because the % time in GC counter is only updated at the end of a GC and in his process since it was idling for a long time after the last gen2 GC (ie, no GCs were happening), the 99% value lasted till next time a GC happened so to him this was misleading. <\/span><\/p>\n

Collecting GC events with PerfView<\/span><\/strong> <\/span><\/p>\n

After you download perfview from Microsoft.com, you just unzip it and run perfview.exe \u2013 yes it's that simple \u2013 there's no install involved. There are many different options in perfview to collect ETW events with but for our purpose we want to collect just some GC events to start with. There are 2 ways you can do that: <\/span><\/p>\n

1) run perfview.exe, click on Collect, then Collect again (or just do Alt+C). You will see a dialog box popping up, click on Advanced options, uncheck \u201cKernel Base\u201d and .NET and check \u201cGC Collect Only\u201d. This tells it to only collect events fired <\/span>during<\/span><\/em> GCs. If you don't do this and simply click on \u201cStart Collection\u201d it will collect these GC events as well, but a lot of other events which makes it less sustainable if you aim to run this for many hours on your production server as the problem will likely take that long to repro. <\/span><\/p>\n

2) use the commandline \u2013 I am a commandline person so this is what I use. It also makes it much easier to include in your automation scripts. Run this commandline (if you run this from a non admin cmd window it will pop up some UI asking for permission to run as admin as collecting ETW requires admin privilege; or you just run it from an admin cmd window): <\/span><\/p>\n

perfview \/GCCollectOnly \/AcceptEULA \/nogui collect <\/span><\/p>\n

\/GCCollectOnly, as name suggests, is the one that's telling it to collect only GC events. <\/span><\/p>\n

Then you run your scenario for long enough for it to show the symptoms. And you can stop it by either clicking on \u201cStop collection\u201d or press \u2018s' in the cmd window to stop the collection. If you know approximately how long it takes for the symptoms to show up, say 10 mins, you can also do <\/span><\/p>\n

perfview \/GCCollectOnly \/AcceptEULA \/nogui \/MaxCollectSec:600 collect <\/span><\/p>\n

which will stop after it's collected for 600 seconds, ie, 10 mins. <\/span><\/p>\n

BTW, you can see all the available commandline args in Help\\Command Line Help. This gives you 2 resulting files: PerfViewGCCollectOnly.etl.zip and PerfViewGCCollectOnly.log.txt. The latter is logging what perfview did. The former is what we will be diving into. <\/span><\/p>\n

The GCStats view in PerfView<\/span><\/strong> <\/span><\/p>\n

Open the PerfViewGCCollectOnly.etl.zip file in perfview, meaning either by running Perfview and browsing to that directory and double clicking on that file; or running the \u201cperfview PerfViewGCCollectOnly.etl.zip\u201d commandline. You will see that there are multiple nodes under that filename. What we are interested in is the GCStats view under the \u201cMemory Group\u201d node. Double click on it to open it. At the top we have something like this:<\/span><\/p>\n

GCStats<\/span><\/strong><\/p>\n