记一次 .NET 某电子病历 CPU 爆高分析
一：背景
1.讲故事
前段时间有位朋友微信找到我，说他的程序出现了 CPU 爆高，帮忙看下程序到底出了什么情况？图就不上了，我们直接进入主题。
二：WinDbg 分析
1. CPU 真的爆高吗？
要确认是否真的爆高，可以使用 !tp 观察。
0:000> !tp
CPU utilization: 96%
Worker Thread: Total: 36 Running: 36 Idle: 0 MaxLimit: 32767 MinLimit: 16
Work Request in Queue: 61
Unknown Function: 00007ffc5c461750 Context: 00000187da7a9788
Unknown Function: 00007ffc5c461750 Context: 0000017fcdd36e88
...
Unknown Function: 00007ffc5c461750 Context: 00000187da5e87d8
Unknown Function: 00007ffc5c461750 Context: 00000187da872788
--------------------------------------
Number of Timers: 2
--------------------------------------
Completion Port Thread:Total: 1 Free: 1 MaxFree: 32 CurrentLimit: 1 MaxLimit: 1000 MinLimit: 16
从卦中可以看到 CPU=96%，果然是 CPU 爆高，而且 Work Request 也累积了 61 个任务未处理，看样子下游不给力哈？ 不给力有可能是因为 GC 触发导致线程频繁停顿，也可能真的是处理太慢。
2. 是 GC 触发了吗？
要查看是否真的 GC 触发，可以用 !t -special 观察下是否有 SuspendEE 字样。
0:000> !t -special
ThreadCount: 83
UnstartedThread: 0
BackgroundThread: 74
PendingThread: 0
DeadThread: 9
Hosted Runtime: no
Lock
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
19 1 1c84 0000017abe10cf60 28220 Preemptive 0000000000000000:0000000000000000 0000017abe103f70 0 Ukn
...
OSID Special thread type
26 1c78 DbgHelper
27 1328 GC SuspendEE
28 1e78 GC
29 1ffc GC
30 1de0 GC
果不其然 27 号线程带了 SuspendEE ,说明当前 GC 是触发状态，接下来看下 27 号线程的非托管栈, 到底发生了什么。
0:027> k
# Child-SP RetAddr Call Site
00 00000074`11aff348 00007ffc`66624abf ntdll!NtWaitForSingleObject+0x14
01 00000074`11aff350 00007ffc`591aa747 KERNELBASE!WaitForSingleObjectEx+0x8f
02 00000074`11aff3f0 00007ffc`591aa6ff clr!CLREventWaitHelper2+0x3c
03 00000074`11aff430 00007ffc`591aa67c clr!CLREventWaitHelper+0x1f
04 00000074`11aff490 00007ffc`59048ef5 clr!CLREventBase::WaitEx+0x7c
05 00000074`11aff520 00007ffc`5905370e clr!SVR::t_join::join+0x10f
06 00000074`11aff580 00007ffc`59049278 clr!SVR::gc_heap::plan_phase+0x11f4
07 00000074`11aff900 00007ffc`590494d6 clr!SVR::gc_heap::gc1+0xb8
08 00000074`11aff950 00007ffc`59048c64 clr!SVR::gc_heap::garbage_collect+0x870
09 00000074`11aff9f0 00007ffc`59192487 clr!SVR::gc_heap::gc_thread_function+0x74
0a 00000074`11affa20 00007ffc`59194194 clr!SVR::gc_heap::gc_thread_stub+0x7e
0b 00000074`11affa60 00007ffc`694184d4 clr!GCThreadStub+0x24
0c 00000074`11affa90 00007ffc`69dee8b1 kernel32!BaseThreadInitThunk+0x14
0d 00000074`11affac0 00000000`00000000 ntdll!RtlUserThreadStart+0x21
从栈方法 gc_thread_function() 来看，这是一个专有的 GC 线程，熟悉 server GC 的朋友应该知道，用户线程分配 引发GC后，会通过 event 唤醒GC线程，言外之意就是还没有找到这个用户线程触发的导火索，要想找到答案有很多方法，查看当前的 GCSettings 观察 GC 触发的诱因及代数，截图如下：
我去，居然是一个诱导式FullGC，言外之意就是有代码会调用 GC.Collect() ，接下来我们用 ~*e !clrstack 导出所有的线程栈，观察 GC.Collect() 字样，还真给找到了。。。
0:117> !clrstack
OS Thread Id: 0x170c (117)
Child SP IP Call Site
0000007419f1d580 00007ffc69e25ac4 [InlinedCallFrame: 0000007419f1d580] System.GC._Collect(Int32, Int32)
0000007419f1d580 00007ffbfba0fbf2 [InlinedCallFrame: 0000007419f1d580] System.GC._Collect(Int32, Int32)
0000007419f1d550 00007ffbfba0fbf2 Spire.Pdf.PdfDocument.Dispose()
...
0000007419f1e2f0 00007ffc504b1092 System.Web.Mvc.MvcHandler.EndProcessRequest(System.IAsyncResult)
从代码看居然是一个商业组件 Spire.Pdf 在 Dispose 时手工释放触发的，一般这么做的目的是想通过此方法间接释放非托管资源。
其实一个 FullGC 不代表什么，如果频繁的 FullGC 肯定是有问题的，那如何观察是否频繁呢？在 CLR 源码中有一个 full_gc_counts 的全局变量，记录着FullGC 的次数，代码如下：
size_t gc_heap::full_gc_counts[gc_type_max];
enum gc_type
{
gc_type_compacting = 0,
gc_type_blocking = 1,
#ifdef BACKGROUND_GC
gc_type_background = 2,
#endif //BACKGROUND_GC
gc_type_max = 3
};
接下来可以用 x 命令去检索这个变量，观察各自的布局。
因为 gc_type_compacting 和 gc_type_blocking 有重叠，而且观察进程运行了 17min，所以 17min 触发了至少 113 =90+23 次 FullGC。
0:117> .time
Debug session time: Tue Sep 6 15:56:08.000 2022 (UTC + 8:00)
System Uptime: 0 days 21:59:52.396
Process Uptime: 0 days 0:17:10.000
Kernel time: 0 days 0:34:34.000
User time: 0 days 0:39:05.000
这个算频繁吗？触发点是否集中？ 在DUMP这种照片下是不得而知的，为了稳一点再看看可有其他的线索。
3. 还有其他线索吗？
既然线程池堆积了很多任务，除了受到一些诸如 GC 的外因影响，内因肯定是最主要的，既然都是 http 请求，可以用 !whttp 观察各自的 HttpContext。
0:117> !whttp
HttpContext Thread Time Out Running Status Verb Url
0000017b406b6f80 102 00:05:00 00:08:56 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017b46797110 107 00:05:00 00:07:35 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017b814572f8 97 00:05:00 00:08:49 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017b84634490 104 00:05:00 00:07:46 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017bc04767b0 90 00:05:00 00:08:43 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017e3e79cbb8 96 00:05:00 00:09:45 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017e7ee10b80 88 00:05:00 00:09:40 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017e89b2cfb0 109 00:05:00 00:04:37 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017e8adb6b80 106 00:05:00 00:02:53 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017d41e90f28 103 00:05:00 00:08:04 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017d4385d528 101 00:05:00 00:07:39 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017d471b7d58 98 00:05:00 00:06:50 200 GET /xxxx/xxx/xxxLogOutputExcel
0000017bc8283c48 117 00:05:00 00:00:32 200 GET /xxx/xxx/xxxMedTags
...
从卦中看，有两点信息：
- 高达 17 个 Excel 导出请求，一般来说导出操作都是 CPU 密集型的, 17 个请求可能刚好把 CPU 全部打满，可以通过
!cpuid验证下。
0:117> !cpuid
CP F/M/S Manufacturer MHz
0 6,79,1 <unavailable> 1995
1 6,79,1 <unavailable> 1995
2 6,79,1 <unavailable> 1995
3 6,79,1 <unavailable> 1995
4 6,79,1 <unavailable> 1995
5 6,79,1 <unavailable> 1995
6 6,79,1 <unavailable> 1995
7 6,79,1 <unavailable> 1995
8 6,79,1 <unavailable> 1995
9 6,79,1 <unavailable> 1995
10 6,79,1 <unavailable> 1995
11 6,79,1 <unavailable> 1995
12 6,79,1 <unavailable> 1995
13 6,79,1 <unavailable> 1995
14 6,79,1 <unavailable> 1995
15 6,79,1 <unavailable> 1995
- 触发 GC 的请求是
/xxx/xxx/xxxMedTags也高达32s，说明程序此时整体变慢。
接下来就是把挖到的这两点信息告诉朋友，重点是 xxxLogOutputExcel 导出，一定要限定频次。
三：总结
总体来说这次生产事故诱发的因素有两个：
-
主因是客户高频次的点击 Excel 导出，越着急越点，越点越着急，导致系统的雪崩。
-
高频的Excel点击操作，间接导致 Spire.Pdf 在某一时段为了释放非托管资源频发的诱导 GC.Collect，进而雪上加霜。
解决方案就简单了，抑制高频点击。
多一点耐心，少一点急躁，也许我们相处的会更好。
