Perfview、BLOCKED_TIME 和垃圾收集中的暂停

Question

我正在尝试通过在 perfview 中分析单线程计算密集型/低 IO .NET 4.7.1 程序来提高其性能，该程序在 AWS 中的 Windows Server 2016 上的 r5.8xlarge 实例（32 核，256GB RAM）上运行。

我在 perfview 中采集了 700 秒的进程样本（包括 -threadtime 标志），我看到了以下 GC 结果

以及这些 > 200 毫秒的暂停事件

查看第一个缓慢的 GC 索引 149056，暂停时间为 12,270.571 毫秒，这是否意味着我的托管代码实际上在 2,522.622 毫秒到 14,793.193 毫秒之间停止了？ (=2522.622+12270.571) 当我等待 Gen 2 GC 完成时？

如果这是真的，当我查看该时间窗口上的线程时间堆栈，并且仅查看我的主线程的 BLOCKED_TIME（使用 IncPats）时，我会看到许多不同的函数最终会出现在 BLOCKED_TIME 中。

我已经编辑了最终调用 clr!JIT_New 的函数行，但大约有 20 个不同的函数。

如果托管线程在此时间窗口内暂停进行 GC，那么我的代码中不会只有一个调用在 BLOCKED_TIME 内结束吗？

Answer 1

查看第一个缓慢的 GC 索引 149056，暂停时间为 12,270.571 毫秒，这是否意味着我的托管代码实际上在 2,522.622 毫秒到 14,793.193 毫秒之间停止了？ (=2522.622+12270.571) 当我等待 Gen 2 GC 完成时？

不，它是后台 GC，与托管线程同时运行，但 12 秒对于第 2 代收集来说是非常长的时间。

我正在尝试通过在 perfview 中分析单线程计算密集型/低 IO .NET 4.7.1 程序来提高其性能，该程序在 AWS 中的 Windows Server 2016 上的 r5.8xlarge 实例（32 核，256GB RAM）上运行。

1. 它运行在服务器GC模式还是工作站模式？

如果可以通过减少 GC 对应用程序的影响来减少暂停并提高项目性能，并在多个线程而不是单线程上执行 GC，请考虑将其更改为服务器 GC

2. 减少可终结对象，因为它会影响对象分配和垃圾收集性能，并对一次性对象使用 Dispose 方法，而不是依赖 fianlizer。

3. 减少从第 2 代到第 0 代的交叉引用，因为它会减慢每个第 0 代 GC 的速度，并使 GC 扫描第 2 代中的一些对象，以确保可以安全地收集第 0 代对象

4. 确保清除对短寿命对象的引用，以便 GC 可以更快地完成标记阶段（这是 GC 大部分时间最耗时的部分）

5. 尽可能避免分配大对象（大多数时候是数组），这样可以减少第 2 代 GC 的频率