关于.net:记一次-NET-某智能交通后台服务-CPU爆高分析

5次阅读

共计 4260 个字符，预计需要花费 11 分钟才能阅读完成。

前天有位敌人加微信求助他的程序呈现了 CPU 爆高的问题，开局就是一个红包，把我吓懵了！🤣🤣🤣

因为是北方小年，我在老家张罗解决起来不不便，没有第一工夫帮他解决，敌人在第二天上午曾经找出问题了，反馈说是一个 while(true) 导致的，这就有点意思了，在我剖析的泛滥 CPU 爆高案例中，还真没遇到 while(true) 的状况，始终都抱有遗憾，真是运气好，年前赶上了，哈哈 😄😄😄。

接下来咱们就用 windbg 一起来剖析下吧。

始终关注我的敌人都晓得，用 !tp 命令就能够了。


0:022> !tp
CPU utilization: 95 Unknown format characterUnknown format control characterWorker Thread: Total: 11 Running: 11 Idle: 0 MaxLimit: 32767 MinLimit: 4
Work Request in Queue: 0
--------------------------------------
Number of Timers: 3
--------------------------------------
Completion Port Thread:Total: 4 Free: 4 MaxFree: 8 CurrentLimit: 4 MaxLimit: 1000 MinLimit: 4

下面有一句 Unknown format characterUnknown format control characterWorker 显得不太谐和，其实就是 % 的意思，不晓得为啥在 .NETCore 会呈现这种编码问题 😂😂😂，接下来咱们用 !eeversion 看一下。


0:022> !eeversion
4.700.21.56803 (3.x runtime) free
4,700,21,56803 @Commit: 28bb6f994c28bc91f09bc0ddb5dcb51d0f066806
Workstation mode
In plan phase of garbage collection
SOS Version: 5.0.4.36902 retail build

从根本信息看，以后是 .netcore 3.x 版本，而且很显著看到以后 GC 处于打算阶段。那何为打算阶段呢？

简而言之，打算阶段的 GC 须要决定以后的的托管堆是做简略的标记 free 操作，还是要做重量级的压缩操作，如果要压缩解决，还须要波及到托管堆对象的重定位，这往往会消耗相当多的 CPU 工夫片，接下来要探索的是什么导致了 GC 触发？

因为 GC 的触发往往是 用户线程 调配数据导致的，在 GC 触发的整个执行流中，其中有一环就是解冻 CLR 执行引擎，也就是 SuspendEE，能够在 gc.app 中一探到底。

为什么肯定要提 SuspendEE 呢？是因为我能够通过 !t -special 找出那个 SuspendEE 的线程，这样准确度更高一点。


0:072> !t -special
ThreadCount:      54
UnstartedThread:  0
BackgroundThread: 40
PendingThread:    0
DeadThread:       1
Hosted Runtime:   no

          OSID Special thread type
        1 6328 DbgHelper 
        2 35c0 Finalizer 
        4 5aac Timer 
        5 38b0 ThreadpoolWorker 
       17 3530 ThreadpoolWorker 
       18 4484 ThreadpoolWorker 
       19 1e4c ThreadpoolWorker 
       21 6380 ThreadpoolWorker 
       44 5bc4 SuspendEE 
       52  8ac ThreadpoolWorker 
       54 4164 ThreadpoolWorker 
       56 61c8 ThreadpoolWorker 
       58 1fa4 ThreadpoolWorker 
       60 2788 ThreadpoolWorker 
       69 48f4 IOCompletion 
       70 5708 IOCompletion 
       71 3b58 ThreadpoolWorker 
       72 17a0 GC 
       73 2f00 Gate 
       74 35e8 IOCompletion 
       75 5730 IOCompletion

能够看到以后的 44 号线程就是触发 GC 的线程，接下来就清朗了，看看 44 号线程在做啥？切到 44 号线程，而后 !clrstack 即可。


0:044> !clrstack 
OS Thread Id: 0x5bc4 (44)
        Child SP               IP Call Site
000000A2B0C3E4C8 00007ffd471ead3a [HelperMethodFrame: 000000a2b0c3e4c8] 
000000A2B0C3E5E0 00007ffce8b4e506 System.Collections.Generic.List`1[[System.__Canon, System.Private.CoreLib]].System.Collections.Generic.IEnumerable.GetEnumerator() [/_/src/System.Private.CoreLib/shared/System/Collections/Generic/List.cs @ 585]
000000A2B0C3E630 00007ffce85e7a10 xxx.Program.DeletexxxExipredDate()
000000A2B0C3E780 00007ffd46bc1f0b System.Threading.ThreadHelper.ThreadStart_Context(System.Object) [/_/src/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.cs @ 44]
000000A2B0C3E7B0 00007ffd46bb90b6 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) [/_/src/System.Private.CoreLib/shared/System/Threading/ExecutionContext.cs @ 172]
000000A2B0C3E830 00007ffd46ba535b System.Threading.ThreadHelper.ThreadStart() [/_/src/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.cs @ 93]
000000A2B0C3EA48 00007ffd47236c93 [GCFrame: 000000a2b0c3ea48] 
000000A2B0C3ECB0 00007ffd47236c93 [DebuggerU2MCatchHandlerFrame: 000000a2b0c3ecb0]

从输入信息看，问题出在了 DeletexxxExipredDate() 办法，接下来探索下这个办法的源码。


        private static void DeletexxxExipredDate()
        {while (true)
            {foreach (string key in xxx.xxxSpeedLimit.Keys)
                {
                    try
                    {string[] array = xxx.xxxSpeedLimit[key].Split('$');
                        if (array.Length > 1)
                        {DateTime dateTime = Convert.ToDateTime(array[1]);
                            if ((DateTime.Now - dateTime).TotalSeconds > 21600.0 && xxx.xxxSpeedLimit.ContainsKey(key))
                            {xxx.xxxSpeedLimit.TryRemove(key, out var _);
                            }
                        }
                    }
                    catch (Exception ex)
                    {LogHelper.WriteAppExceptionLog("删除数据出现异常:" + ex.Message, ex);
                    }
                    Thread.Sleep(20000);
                }
            }
        }

如果有丰盛踩坑教训的敌人，我置信一眼就能看出这代码中存在的问题，对，就是当 xxxSpeedLimit 字典为空的时候，就相当于一个 while(true) 死循环啦，对不对？

为了验证我的说法，能够用 !dso 找到 dict 的内存地址，而后用 !wconcurrentdict 即可。


0:044> !dso 
OS Thread Id: 0x5bc4 (44)
RSP/REG          Object           Name
...
000000A2B0C3E708 000001ba8007f618 System.Collections.Concurrent.ConcurrentDictionary`2[[System.String, System.Private.CoreLib],[System.String, System.Private.CoreLib]]
000000A2B0C3E760 000001ba88501cd0 System.Collections.Generic.List`1+Enumerator[[System.String, System.Private.CoreLib]]
000000A2B0C3E768 000001ba80050ec0 System.Threading.ContextCallback
000000A2B0C3E7F8 000001ba80a1a818 System.Threading.Thread
000000A2B0C3EA28 000001ba80a1a898 System.Threading.ThreadStart
0:044> !wconcurrentdict 000001ba8007f618
Empty ConcurrentDictionary

能够看到，以后就是一个 空字典 😂😂😂

这次事变的次要起因：编码人员短少了肯定的编程教训，在写业务逻辑的时候短少了对 空字典 的流程解决，导致了 while(true) 的难堪，也有可能是将那个 Thread.Sleep(20000) 放错了地位🤣🤣🤣

总的来说很感激这位敌人提供的 dump，让我真的眼见为实啦！

正文完