{"id":23168,"date":"2006-12-12T19:14:00","date_gmt":"2006-12-12T19:14:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/maoni\/2006\/12\/12\/difference-between-perf-data-reported-by-different-tools-2\/"},"modified":"2021-10-04T16:33:50","modified_gmt":"2021-10-04T23:33:50","slug":"difference-between-perf-data-reported-by-different-tools-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/difference-between-perf-data-reported-by-different-tools-2\/","title":{"rendered":"Difference Between Perf Data Reported by Different Tools \u2013 2"},"content":{"rendered":"<p><b>Managed Heap Size<\/b><\/p>\n<p>We have both .NET CLR Memory perf counters and SoS extensions that report manged heap size related data.<\/p>\n<p>Difference 2<\/p>\n<p>There are a few .NET CLR Memory counters that are related to the managed heap size:<\/p>\n<p># Total Committed Bytes<\/p>\n<p># Total Reserved Bytes<\/p>\n<p>I explained what these counters mean <a href=\"https:\/\/devblogs.microsoft.com\/dotnet\/gc-performance-counters\/\"><span style=\"color: #800080;\">here<\/span><\/a>.<\/p>\n<p>Now, how are they related to the values you see when you do a !SOS.eeheap \u2013gc?<\/p>\n<p>0:003&gt; !eeheap -gc\nNumber of GC Heaps: 1\ngeneration 0 starts at 0x01245078\ngeneration 1 starts at 0x0124100c\ngeneration 2 starts at 0x01241000\nephemeral segment allocation context: (0x0125a900, 0x0125b39c)\nsegment\u00a0\u00a0\u00a0 begin allocated\u00a0\u00a0\u00a0\u00a0 size\n001908c0 793fe120\u00a0 7941d8a8 0x0001f788(128904)\n01240000 01241000\u00a0 0125b39c 0x0001a39c(107420)\nLarge object heap starts at 0x02241000\nsegment\u00a0\u00a0\u00a0 begin allocated\u00a0\u00a0\u00a0\u00a0 size\n02240000 02241000\u00a0 02243250 0x00002250(8784)\nTotal Size\u00a0\u00a0 0x3bd74(245108)\n&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;\nGC Heap Size\u00a0\u00a0 0x3bd74(245108)<\/p>\n<p>The allocated column indicates the end of the last live object on the segment. So for gen0 and LOH it changes as the managed threads allocate, unlike the .NET CLR Memory counters which only reflect the end of the last live object on the segment when the last GC\u2019s happened (at the end of last GC).<\/p>\n<p>The # Bytes in All Heaps counter\u00a0 under .NET CLR Memory counter is kind of misleading. The explanation says it\u2019s the bytes in \u201call heaps\u201d but really it\u2019s gen1+gen2+LOH in CLR 2.0, so it doesn\u2019t include gen0 \u2018cause most of the time gen0 size is 0 right after a GC. So if you break into your process under the debugger and use the !sos.eeheap \u2013gc command you will most likely get a value that\u2019s the same as this counter. But if you break between 2 GCs the value you get from !eeheap \u2013gc will always be larger than the value of this counter.<\/p>\n<p>If you are concerned with the true amount of memory that the managed heap commits (which is usually what you need to worry about) you should use the # Total Committed Bytes counter.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Managed Heap Size We have both .NET CLR Memory perf counters and SoS extensions that report manged heap size related data. Difference 2 There are a few .NET CLR Memory counters that are related to the managed heap size: # Total Committed Bytes # Total Reserved Bytes I explained what these counters mean here. Now, [&hellip;]<\/p>\n","protected":false},"author":3542,"featured_media":58792,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[685],"tags":[3011],"class_list":["post-23168","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet","tag-maoniposts"],"acf":[],"blog_post_summary":"<p>Managed Heap Size We have both .NET CLR Memory perf counters and SoS extensions that report manged heap size related data. Difference 2 There are a few .NET CLR Memory counters that are related to the managed heap size: # Total Committed Bytes # Total Reserved Bytes I explained what these counters mean here. Now, [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/23168","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/3542"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=23168"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/23168\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=23168"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=23168"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=23168"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}