一:背景
在洞察 GC 方面,我觉得市面上没有任何一款工具可以和 PerfView 相提并论,这也是为什么我会在 WinDbg 之外还要学习这么一款工具的原因,这篇我们先简单聊聊 PerfView 到底能洞察 GC 什么东西?
二:洞察 GC
1. 到底都能看到 GC 什么?
能获取到的 GC 信息非常多,比如:
程序运行期间 GC 触发了多少次?
GC 最大一次暂停耗费了多久?
每一次 GC 触发的原因是什么?
GC 暂停 >200ms 的都有哪些?
GC 触发 3 阶段中各个函数的耗时是怎样的?
等等。。。可获取的信息非常多,后面的文章会逐一聊。
2. 获取 GC 的一般性信息
为了方面讲述,先上一段故意无限次拼接 string 的代码,让 GC 高频触发。
internal class Program
{
static void Main(string[] args)
{
Task.Run(Alloc1);
Console.ReadLine();
}
static void Alloc1()
{
var s = string.Empty;
for (int i = 0; i < 100000; i++)
{
s = s + i.ToString();
}
}
}
接下来我们用 Collect -> Run
对程序采样 20s,观察这 20s 中 GC 的触发情况。
![b137f8c26c4281c79d10d560af46a459.png](https://i-blog.csdnimg.cn/blog_migrate/0f2a3988e272edcf4451d3c4087ca52e.png)
稍等20s
后,在打包好的 zip 视图列表中点击 Memory -> GCStats
。
![411e2b97336fef46e54ebbb3aed7bea0.png](https://i-blog.csdnimg.cn/blog_migrate/d1845ed161afe51b84a90b9a0e5d7afa.png)
然后点击我们的应用程序,就会看到 GC 汇总信息。
GC Stats for Process 3848: ConsoleApp10
•CommandLine: "D:\net6\ConsoleApp1\ConsoleApp10\bin\Debug\net6.0\ConsoleApp10.exe"
•Runtime Version: V 6.0.522.21309 (built on 2022/4/14 1:31:32)
•CLR Startup Flags: 8388611
•Total CPU Time: 10,471 msec
•Total GC CPU Time: 1,305 msec
•Total Allocs : 38,099.086 MB
•GC CPU MSec/MB Alloc : 0.034 MSec/MB
•Total GC Pause: 2,710.6 msec
•% Time paused for Garbage Collection: 19.9%
•% CPU Time spent Garbage Collecting: 12.5%
•Max GC Heap Size: 14.285 MB
•Peak Process Working Set: 40.776 MB
•Peak Virtual Memory Usage: 5,003.682 MB
...
接下来看下 GC Rollup By Generation
列表,如下图所示:
![d66c04e4708b0bdfaa7cfdf774032357.png](https://i-blog.csdnimg.cn/blog_migrate/d03c735f06f16a1f453a2162db04897e.png)
从图中可得知这 20s 期间的如下信息:
GC触发了
1w
次,平均500次/s
,🐂哈GC总的暂停时间是 2.7s,占比 13.5% ,也就是说20s时间,程序其实就跑了 86.5% 的时间,有点像 公摊面积 哈, 其实这是有问题的。
1w 次GC 中,最大的单次暂停时发生在 gen0 上,耗费了 2.6ms。
还有一个比较有用的是 Pause > 200 Msec GC Events
列表,它记录着那些暂停时间大于 >200ms
的单次GC,截图如下:
![17dce56fe51b676d8c61a2ec21c31bf8.png](https://i-blog.csdnimg.cn/blog_migrate/d2a2ffaae025cae41155b01e074d5156.png)
还好本次实验没有遇到,不过可以肯定的是,大于 200ms 的程序暂停肯定会导致明显的卡顿,所以仔细研读下这些 列信息
非常有用,是不是因为 存活对象过多
导致的 mark_phase 和 compact_phase 时间过长?还是因为 pinned 或者 碎片化过多导致 plan_phase
时间过长等等,具体问题具体分析。
接下来就是这 10956
次 GC 的 detail 信息啦,可以观察到 GC 的触发原因,触发了哪一代 GC,SuppendEE 暂停时间,GC 暂停时间,GC 与上次 GC 之后的一个时间占比 等等各种信息,大家可以把鼠标放在标头上,都有相应的提示。
![e880039370d31751cf52e9739a3654be.png](https://i-blog.csdnimg.cn/blog_migrate/ca863c9966892ea1aa441593dc203fff.png)
稍微提醒下就是 Pause Start
是没有解释的,其实它是一个毫秒时间戳,如果你仔细观察,也就是 500次/s
的排序记录。
3. 获取 GC 内部函数的 一般性耗时
熟悉 GC 的朋友应该知道,最简单的非并发工作站模式 GC 是这样的一个触发模式,如下代码所示:
GarbageCollectGeneration()
{
SuspendEE();
garbage_collect();
RestartEE();
}
garbage_collect()
{
generation_to_condemn();
gc1();
}
gc1()
{
mark_phase();
plan_phase();
}
plan_phase()
{
// actual plan phase work to decide to
// compact or not
if (compact)
{
relocate_phase();
compact_phase();
}
else
make_free_lists();
}
那如何用 PerfView 去检测这些函数的耗时呢?可以是可以,但只是一个大体的模型,因为原理是对 CPU 进行采样 再根据权重算出来的,所以有一定的参考意义。
接下来我们在 Find
输入框中搜索 coreclr!GarbageCollectGeneration 关键词。
![c49b2762aa7560a5f440f1e1e1c12f47.png](https://i-blog.csdnimg.cn/blog_migrate/1c43387c4e2971e98e17730e71ae2dd4.png)
接下来右键选择 Goto -> Goto Item in Callees
选项,然后展开可能的耗时,如下图所示:
![a6bc6014ae06fcda13c8f3845b94892e.png](https://i-blog.csdnimg.cn/blog_migrate/e07265ea9561406ff472f98441e26303.png)
从输出信息看, GarbageCollectGeneration
大概会耗时 12.2ms
,耗时比较长的两块大概是:
GCScanRoots
在标记阶段,爬线程栈耗时相对较大,耗费了 3.8ms
,继续往下翻的话,会发现都耗费在寻找 GC 安全点上。
![daf39ed479f770ce0ce609852e094455.png](https://i-blog.csdnimg.cn/blog_migrate/cbd4895e28afe76bbcc7966029d675df.png)
relocate_phase
这个属于 计划阶段 的重定位阶段,主要用来修改需要移动对象的新地址,所谓 兵马未动,粮草先行
。
![29e8f4ecc11227fb169d8cac278fd171.png](https://i-blog.csdnimg.cn/blog_migrate/bbe56b9ea55ae5cda283f6ad70a83778.png)
关于 GC 的洞察,还有更多好玩的东西,放在后续文章聊吧!