上一篇我们聊到了如何调试.NET Native AOT 程序，这是研究一个未知领域知识的入口，这篇我们再来看下如何对 Native AOT 程序进行轻量级的APM监控，当然这里的轻量级更多的是对 AOT 中的coreclr内容的挖掘。
二：如何轻量级APM监控 1. 一个简单的例子用一个不断的往内存中囤积数据的例子来演示吧，然后观察内存的趋势变化，参考代码如下：
internal Program {public static List<string> list = new List<string>();static void Main(string[] args) { Debugger.Break(); Task.Run(() => { Run(); }).Wait(); }static void Run() {for (int i = 0; i < 10000; i++) { list.Add(string.Join(", ", Enumerable.Range(0, 20000))); Thread.Sleep(1); Console.WriteLine($"i={i}"); } } }这里要注意的是，AOT在 ilc 编译的过程中会采用摇树优化,言外之意就是 eventpipe跟踪组件 默认是不加入的，这个组件的源码在 src\native\eventpipe 目录下，主要是采用 ipc 的方式与接收者进行通讯。
如果有点懵的话可以简单的理解成这东西是托管版的ETW，msdn 上也给了一张对比图，参考如下：
说了这么多，言外之意就是要把 eventpipe 保留，方式就是在 csproj 中配置 EventSourceSupport =true 即可，参考如下：
<Project Sdk="Microsoft.NET.Sdk"><PropertyGroup><OutputType>Exe</OutputType><TargetFramework>net8.0</TargetFramework><ImplicitUsings>enable</ImplicitUsings><able>enable</able><PublishAot>true</PublishAot><InvariantGlobalization>true</InvariantGlobalization><EventSourceSupport>true</EventSourceSupport></PropertyGroup></Project>接下来用 dotnet cli 进行 public 发布，参考如下：
dotnet publish -r win-x64 -c Debug -o D:\testdump程序启动好之后，接下来用dotnet-counter来洞察一下程序的托管堆，CPU 等各种指标，安装方式可以参考链接：https://learn.microsoft.com/zh-cn/dotnet/core/diagnostics/dotnet-counters
PS C:\Users\Administrator\Desktop> dotnet-counters monitor -n Example_21_1
从上图中我们确实也真真切切的看到了进程的各个指标，有些朋友可能会好奇，如果我没开 EventPipe还能挖到这些信息吗？这当然是可以的，不过这就需要你对 coreclr 底层有一定的了解度了。
2. 如何用windbg去挖首先要知道的是sos 在 aot 中用不了的，但用不了不代表我们没办法，因为 sos 也是从 coreclr 中挖取的数据，那为什么我就不能自己去挖呢？
如何挖托管堆数据sos 是在coreclr 的 gc_heap::generation_table 全局数组中挖取的数据，言外之意我也可以手工的去挖，然后拼凑成托管堆 ，参考如下：
0:009> dx -r1 (*((Example_21_1!WKS::generation (*)[5])0x7ff6fa99ca90))(*((Example_21_1!WKS::generation (*)[5])0x7ff6fa99ca90)) [Type: WKS::generation [5]] [0] [Type: WKS::generation] [1] [Type: WKS::generation] [2] [Type: WKS::generation] [3] [Type: WKS::generation] [4] [Type: WKS::generation]这个数组就对应着 0代，1代，2代，LOH代，POH代 等数据。
如何知道当前机器的内存总量和CPU核心数这个数据在dump分析过程中非常重要，它可以表示当前机器的robust能力，这些数据在 coreclr 的 g_SystemInfo 和 total_physical_mem 全局变量中，参考如下：
0:009> x Example_21_1!WKS::gc_heap::total_physical_mem00007ff6`fa9ac1b0 Example_21_1!WKS::gc_heap::total_physical_mem = 0x00000007`f7bbd0000:009> ? 0x00000007`f7bbd000 /0n1024/0n1024/0n1024Evaluate expression: 31 = 00000000`0000001f0:009> dt Example_21_1!g_SystemInfo +0x000 dwNumberOfProcessors : 0xc +0x004 dwPageSize : 0x1000 +0x008 dwAllocationGranularity : 0x10000可以看到当前机器的内存总量是 31G（32G），同时机器的CPU=12。
如何挖掘GC触发信息捕获gc的触发可以有效的获取gc的触发代，触发原因，以及当前的托管堆静态和动态阈值情况，对我们洞察程序非常有帮助，那如何捕获呢？可以对gc触发的必经之路上下一个断点即可，比如：bp Example_21_1!WKS::gc_heap::gc1 。
0:010> bp Example_21_1!WKS::gc_heap::gc1 0:010> gBreakpoint 0 hitExample_21_1!WKS::gc_heap::gc1:00007ff7`e268cd20 488bc4 mov rax,rsp0:006> k 5# Child-SP RetAddr Call Site00 0000001d`6c6febb8 00007ff7`e268ccac Example_21_1!WKS::gc_heap::gc1 [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @ 22250] 01 0000001d`6c6febc0 00007ff7`e26742e0 Example_21_1!WKS::gc_heap::garbage_collect+0x77c [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @ 24332] 02 0000001d`6c6fec70 00007ff7`e26a5a8a Example_21_1!WKS::GCHeap::GarbageCollectGeneration+0x300 [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @ 50529] 03 0000001d`6c6fecd0 00007ff7`e2672d84 Example_21_1!WKS::gc_heap::trigger_gc_for_alloc+0x5a [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @ 18906] 04 (Inline Function) --------`-------- Example_21_1!WKS::gc_heap::try_allocate_more_space+0x14e [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @ 19048] ...接下来洞察内部的 gc_heap::settings 结构，信息如下：
0:006> dt Example_21_1!WKS::gc_heap::settings 00007ff7`e2c46fb0 +0x000 gc_index : Volatile<unsigned __int64> +0x008 condemned_generation : 0n0 +0x00c promotion : 0n0 +0x010 compaction : 0n1 +0x014 loh_compaction : 0n0 +0x018 heap_expansion : 0n0 +0x01c concurrent : 0 +0x020 demotion : 0n0 +0x024 card_bundles : 0n1 +0x028 gen0_reduction_count : 0n0 +0x02c should_lock_elevation : 0n0 +0x030 elevation_locked_count : 0n0 +0x034 elevation_reduced : 0n0 +0x038 minimal_gc : 0n0 +0x03c reason : 0 ( reason_alloc_soh ) +0x040 pause_mode : 1 ( pause_interactive ) +0x044 found_finalizers : 0n0 +0x048 background_p : 0n0 +0x04c b_state : 0 ( bgc_not_in_process ) +0x050 entry_memory_load : 0x30 +0x058 entry_available_physical_mem : 0x00000004`1a660000 +0x060 exit_memory_load : 00:006> dx -r1 (*((Example_21_1!Volatile<unsigned __int64> *)0x7ff7e2c46fb0))(*((Example_21_1!Volatile<unsigned __int64> *)0x7ff7e2c46fb0)) [Type: Volatile<unsigned __int64>] [+0x000] m_val : 0xd [Type: unsigned __int64]0:006> ? 0x41a660000/0n1024/0n1024/0n1024Evaluate expression: 16 = 00000000`00000010从上面的输出中可以看到当前GC的信息特别多：0xd次触发，并且是压缩式的回收，触发的是 0代，原因是代满了，当前机器还可使用的内存是 16G。
三：总结虽然 .NET AOT 越来越成熟，但目前还是不能对 gcheap 进行sos级的分析，暂时只能手工的挖掘整理，不过我相信在 .NET10 或者 11 上应该能够得到完整的支持，毕竟这势不可挡！
