一:背景
1. 讲故事
最近也挺奇怪,看到了两起 CPU 爆高的案例,且诱因也是一致的,觉得有一些代表性,合并分享出来帮助大家来避坑吧,闲话不多说,直接上 windbg 分析。
二:WinDbg 分析
1. CPU 真的爆高吗
这里要提醒一下,别人说爆高不一定真的就是爆高,我们一定要拿数据说话,可以用 !tp
观察下。
0:000> !tp
logStart: 132
logSize: 200
CPU utilization: 59 %
Worker Thread: Total: 6 Running: 6 Idle: 0 MaxLimit: 10 MinLimit: 4
Work Request in Queue: 0
--------------------------------------
Number of Timers: 3
--------------------------------------
Completion Port Thread:Total: 2 Free: 2 MaxFree: 8 CurrentLimit: 2 MaxLimit: 10 MinLimit: 4
虽然卦中的 CPU 不低但也不是我理想的阈值,不过分析也是可以分析的,知道了 CPU 的利用率,接下来我们看下这个 CPU 猛不猛,使用 !cpuid
看下核心数。
0:000> !cpuid
CP F/M/S Manufacturer MHz
0 6,167,1 <unavailable> 199
1 6,167,1 <unavailable> 199
2 6,167,1 <unavailable> 199
3 6,167,1 <unavailable> 199
只有四个核心,看样子这 CPU 不咋地哈,接下来的问题是谁导致了 CPU 爆高呢?
2. 是谁导致的 CPU 爆高
如果你刚才仔细看 !tp
的输出,应该会发现这么一句话 Total: 6 Running: 6
,这表示当前线程池中的所有工作线程火力全开,有了这个现象,思路就比较明朗了,为什么会火力全开,这些线程此时都在干什么? 我们使用 ~*e !clrstack
观察一下。
0:000> ~*e !clrstack
...
OS Thread Id: 0x1dd8 (58)
Child SP IP Call Site
...
00000065F623F360 00007ffc38383a06 xxx+c__DisplayClass18_0.b__0(System.Object)
00000065F623FA00 00007ffc385680e2 System.Threading.ThreadPoolWorkQueue.Dispatch() [/_/src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs @ 729]
00000065F623FA90 00007ffc9638e3ee System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart() [/_/src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.WorkerThread.cs @ 63]
00000065F623FBA0 00007ffc96372eaf System.Threading.Thread.StartCallback() [/_/src/coreclr/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.cs @ 105]
00000065F623FE30 00007ffc9730af03 [DebuggerU2MCatchHandlerFrame: 00000065f623fe30]
OS Thread Id: 0x15a8 (59)
Child SP IP Call Site
00000065F63BE6F8 00007ffca6905d14 [InlinedCallFrame: 00000065f63be6f8] Interop+Winsock.recv(System.Net.Sockets.SafeSocketHandle, Byte*, Int32, System.Net.Sockets.SocketFlags)
00000065F63BE6F8 00007ffc38521441 [InlinedCallFrame: 00000065f63be6f8] Interop+Winsock.recv(System.Net.Sockets.SafeSocketHandle, Byte*, Int32, System.Net.Sockets.SocketFlags)
00000065F63BE6C0 00007ffc38521441 ILStubClass.IL_STUB_PInvoke(System.Net.Sockets.SafeSocketHandle, Byte*, Int32, System.Net.Sockets.SocketFlags)
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]
...
00000065F63BF140 00007ffc3838ae0b xxx+c__DisplayClass18_0.b__0(System.Object)
00000065F63BF7E0 00007ffc385680e2 System.Threading.ThreadPoolWorkQueue.Dispatch() [/_/src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs @ 729]
00000065F63BF870 00007ffc9638e3ee System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart() [/_/src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.WorkerThread.cs @ 63]
00000065F63BF980 00007ffc96372eaf System.Threading.Thread.StartCallback() [/_/src/coreclr/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.cs @ 105]
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 用在了一个它最不擅长的地方,复杂度一下子就上来了。
public static xxx Getxxx(xxx conxx)
{
xxx xxxInfo2 = conxxx;
lock (xxx)
{
return hashxxxnfo.Where((xxxInfo x) => x.xxx == xxx.xxx && x.xxx == xxx.intPtr)?.FirstOrDefault();
}
}
4. 其他dump呢
刚才我也说了,最近是连续看到了两个,另外一个也是很奇葩的,而且还更严重,使用 !tp
观察一下。
0:000> !tp
CPU utilization: 92%
Worker Thread: Total: 16 Running: 16 Idle: 0 MaxLimit: 32767 MinLimit: 16
Work Request in Queue: 17
AsyncTimerCallbackCompletion TimerInfo@000000e644d32df0
Unknown Function: 00007fff29dc17d0 Context: 000000e136337f58
Unknown Function: 00007fff29dc17d0 Context: 000000e136344798
Unknown Function: 00007fff29dc17d0 Context: 000000e1363479a8
...
Unknown Function: 00007fff29dc17d0 Context: 000000e135730720
Unknown Function: 00007fff29dc17d0 Context: 000000e13573ccd8
--------------------------------------
Number of Timers: 0
--------------------------------------
Completion Port Thread:Total: 1 Free: 1 MaxFree: 32 CurrentLimit: 1 MaxLimit: 1000 MinLimit: 16
从卦中看,cpu利用率更高,线程池队列还有任务堆积,用同样的方式也洞察出了它的问题代码,也是一个无脑丢。
5. 如何优化
要想把 CPU 弄下去,无非就是在 生产端 和 消费端 进行双向打磨。
- 生产端
严格控制线程
的个数,以排队的方式定时定量的处理,严禁无脑丢,因为运行的线程少了,cpu自然就下去了。
- 消费端
很多朋友写代码不注意时间复杂度,或者根本不关心,导致数据量稍微大一点,代码就接近死循环,真的是无语死了,所以尽量把代码性能优化再优化,提高单次处理速度,让 消费端 接待能力 大大超出 生产端。文章来源:https://www.toymoban.com/news/detail-712128.html
三:总结
这两个 CPU 爆高事故还是非常经典的,根子上还是有不少初中级程序员具有 偷懒 + 无视算法
的思维,谨以这篇让后来的朋友少踩坑吧!文章来源地址https://www.toymoban.com/news/detail-712128.html
![记一次 .NET 某仪器测量系统 CPU爆高分析](https://imgs.yssmx.com/Uploads/2023/10/712128-4.jpg)
到了这里,关于记一次 .NET 某仪器测量系统 CPU爆高分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!