记一次 .NET 某仪器测量系统 CPU爆高分析

盈通四海

一：背景

1. 讲故事

最近也挺奇怪，看到了两起 CPU 爆高的案例，且诱因也是一致的，觉得有一些代表性，合并分享出来帮助大家来避坑吧，闲话不多说，直接上 windbg 分析。
二：WinDbg 分析

1. CPU 真的爆高吗

这里要提醒一下，别人说爆高不一定真的就是爆高，我们一定要拿数据说话，可以用 !tp 观察下。

1. 0:000> !tp
2. logStart: 132
3. logSize: 200
4. CPU utilization: 59 %
5. Worker Thread: Total: 6 Running: 6 Idle: 0 MaxLimit: 10 MinLimit: 4
6. Work Request in Queue: 0
7. --------------------------------------
8. Number of Timers: 3
9. --------------------------------------
10. Completion Port Thread:Total: 2 Free: 2 MaxFree: 8 CurrentLimit: 2 MaxLimit: 10 MinLimit: 4

复制代码

虽然卦中的 CPU 不低但也不是我理想的阈值，不过分析也是可以分析的，知道了 CPU 的利用率，接下来我们看下这个 CPU 猛不猛，使用 !cpuid 看下核心数。

1. 0:000> !cpuid
2. CP  F/M/S  Manufacturer     MHz
3. 0  6,167,1  <unavailable>    199
4. 1  6,167,1  <unavailable>    199
5. 2  6,167,1  <unavailable>    199
6. 3  6,167,1  <unavailable>    199

复制代码

只有四个核心，看样子这 CPU 不咋地哈，接下来的问题是谁导致了 CPU 爆高呢？
2. 是谁导致的 CPU 爆高

如果你刚才仔细看 !tp 的输出，应该会发现这么一句话 Total: 6 Running: 6  ，这表示当前线程池中的所有工作线程火力全开，有了这个现象，思路就比较明朗了，为什么会火力全开，这些线程此时都在干什么？ 我们使用  ~*e !clrstack 观察一下。

1. 0:000> ~*e !clrstack
2. ...
3. OS Thread Id: 0x1dd8 (58)
4.         Child SP               IP Call Site
5. ...
6. 00000065F623F360 00007ffc38383a06 xxx+c__DisplayClass18_0.b__0(System.Object)
7. 00000065F623FA00 00007ffc385680e2 System.Threading.ThreadPoolWorkQueue.Dispatch() [/_/src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs @ 729]
8. 00000065F623FA90 00007ffc9638e3ee System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart() [/_/src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.WorkerThread.cs @ 63]
9. 00000065F623FBA0 00007ffc96372eaf System.Threading.Thread.StartCallback() [/_/src/coreclr/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.cs @ 105]
10. 00000065F623FE30 00007ffc9730af03 [DebuggerU2MCatchHandlerFrame: 00000065f623fe30]
11. OS Thread Id: 0x15a8 (59)
12.         Child SP               IP Call Site
13. 00000065F63BE6F8 00007ffca6905d14 [InlinedCallFrame: 00000065f63be6f8] Interop+Winsock.recv(System.Net.Sockets.SafeSocketHandle, Byte*, Int32, System.Net.Sockets.SocketFlags)
14. 00000065F63BE6F8 00007ffc38521441 [InlinedCallFrame: 00000065f63be6f8] Interop+Winsock.recv(System.Net.Sockets.SafeSocketHandle, Byte*, Int32, System.Net.Sockets.SocketFlags)
15. 00000065F63BE6C0 00007ffc38521441 ILStubClass.IL_STUB_PInvoke(System.Net.Sockets.SafeSocketHandle, Byte*, Int32, System.Net.Sockets.SocketFlags)
16. 00000065F63BE790 00007ffc385679d1 System.Net.Sockets.Socket.Receive(Byte[], Int32, Int32, System.Net.Sockets.SocketFlags, System.Net.Sockets.SocketError ByRef) [/_/src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs @ 1473]
17. ...
18. 00000065F63BF140 00007ffc3838ae0b xxx+c__DisplayClass18_0.b__0(System.Object)
19. 00000065F63BF7E0 00007ffc385680e2 System.Threading.ThreadPoolWorkQueue.Dispatch() [/_/src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs @ 729]
20. 00000065F63BF870 00007ffc9638e3ee System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart() [/_/src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.WorkerThread.cs @ 63]
21. 00000065F63BF980 00007ffc96372eaf System.Threading.Thread.StartCallback() [/_/src/coreclr/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.cs @ 105]
22. 00000065F63BFC10 00007ffc9730af03 [DebuggerU2MCatchHandlerFrame: 00000065f63bfc10]

复制代码

通过仔细观察各个线程的线程栈，发现最多的是 xxx+c__DisplayClass18_0.b__0 方法，从底层的 PortableThreadPool 来看，这是 C# 自己封装的线程池，说明这是由 线程池工作线程创建的，再辅助一张截图：

接下来的方向是 xxx+c__DisplayClass18_0.b__0  为何方神圣，可能有些朋友对这种方法命名很奇怪，这里解释一下，一般都是 await, async 的底层弄出来的，由大量的状态机方法所致。
3. c__DisplayClass18_0 到底写了什么

知道了这个方法，接下来可以用 ILSPY 去观察下这段代码，截图如下：

上面这段代码不知道大家有没有看出什么问题？ 至少我看到这样的代码我就知道 CPU 为什么会爆高了，两点原因。

• 偷懒，无脑往线程池丢，导致线程增多
  
• 线程中方法时间复杂度高。
  

关于时间复杂度高，在子函数很容易就能找到诸如此类代码，将一个 hash 用在了一个它最不擅长的地方，复杂度一下子就上来了。

1. public static xxx Getxxx(xxx conxx)
2. {
3.         xxx xxxInfo2 = conxxx;
4.         lock (xxx)
5.         {
6.                 return hashxxxnfo.Where((xxxInfo x) => x.xxx == xxx.xxx && x.xxx == xxx.intPtr)?.FirstOrDefault();
7.         }
8. }

复制代码

4. 其他dump呢

刚才我也说了，最近是连续看到了两个，另外一个也是很奇葩的，而且还更严重，使用 !tp 观察一下。

1. 0:000> !tp
2. CPU utilization: 92%
3. Worker Thread: Total: 16 Running: 16 Idle: 0 MaxLimit: 32767 MinLimit: 16
4. Work Request in Queue: 17
5.     AsyncTimerCallbackCompletion TimerInfo@000000e644d32df0
6.     Unknown Function: 00007fff29dc17d0  Context: 000000e136337f58
7.     Unknown Function: 00007fff29dc17d0  Context: 000000e136344798
8.     Unknown Function: 00007fff29dc17d0  Context: 000000e1363479a8
9.     ...
10.     Unknown Function: 00007fff29dc17d0  Context: 000000e135730720
11.     Unknown Function: 00007fff29dc17d0  Context: 000000e13573ccd8
12. --------------------------------------
13. Number of Timers: 0
14. --------------------------------------
15. Completion Port Thread:Total: 1 Free: 1 MaxFree: 32 CurrentLimit: 1 MaxLimit: 1000 MinLimit: 16

复制代码

从卦中看，cpu利用率更高，线程池队列还有任务堆积，用同样的方式也洞察出了它的问题代码，也是一个无脑丢。

5. 如何优化

要想把 CPU 弄下去，无非就是在 生产端 和 消费端 进行双向打磨。

• 生产端
  

严格控制线程的个数，以排队的方式定时定量的处理，严禁无脑丢，因为运行的线程少了，cpu自然就下去了。

• 消费端
  

很多朋友写代码不注意时间复杂度，或者根本不关心，导致数据量稍微大一点，代码就接近死循环，真的是无语死了，所以尽量把代码性能优化再优化，提高单次处理速度，让 消费端 接待能力 大大超出 生产端。
三：总结

这两个 CPU 爆高事故还是非常经典的，根子上还是有不少初中级程序员具有 偷懒 + 无视算法 的思维，谨以这篇让后来的朋友少踩坑吧！

来源:https://www.cnblogs.com/huangxincheng/archive/2023/09/22/17722077.html
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！