ToB企服应用市场:ToB评测及商务社交产业平台

标题: 记一次 .NET某智慧出行系统 CPU爆高分析 [打印本页]
作者: 圆咕噜咕噜    时间: 2024-8-8 11:32
标题: 记一次 .NET某智慧出行系统 CPU爆高分析
一：背景

1. 讲故事

前些天有位朋友找到我，说他们的系统出现了CPU 100%的环境，让我帮忙看一下怎么回事？dump也拿到了，本想着这种环境让他多抓几个，既然有了就拿现有的分析吧。
二：WinDbg 分析

1. 为什么会爆高

既然说是 100%，作为调试者得拿数据说话，可以利用 !tp 来观测一下。
  1. 0:000:x86> !tp
  2. CPU utilization: 100%
  3. Worker Thread: Total: 382 Running: 382 Idle: 0 MaxLimit: 8191 MinLimit: 8
  4. Work Request in Queue: 8694
  5.     Unknown Function: 6f62b650  Context: 4a36bbbc
  6.     Unknown Function: 6f62b650  Context: 4a36e1d4
  7.     Unknown Function: 6f62b650  Context: 4a372384
  8.     Unknown Function: 6f62b650  Context: 239adfec
  9.     Unknown Function: 6f62b650  Context: 4a374994
  10.     Unknown Function: 6f62b650  Context: 239b9e14
  11.     Unknown Function: 6f62b650  Context: 2399fd9c
  12.     ...
复制代码
从卦中看,不得了，CPU 100% 之外,全部的线程池线程全部被打满，人生自古最忌满，半贫半富半自安。同时线程池队列还累计了8694个任务待处理，说明这时候的线程池已经全面沦陷，要想找到这个答案，必要用 ~*e !clrstack 命令观察每一个线程此时正在做什么，输出如下：
  1. 0:000:x86> ~*e !clrstack
  2. OS Thread Id: 0x22f4 (429)
  3. Child SP       IP Call Site
  4. 4bc1e060 0000002b [GCFrame: 4bc1e060]
  5. 4bc1e110 0000002b [HelperMethodFrame_1OBJ: 4bc1e110] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)
  6. 4bc1e19c 24aad7da System.Threading.Monitor.Wait(System.Object, Int32, Boolean)
  7. 4bc1e1ac 2376f0d6 ServiceStack.Redis.PooledRedisClientManager.GetClient()
  8. 4bc1e1dc 2420bbc6 xxx.Service.CacheService.GetClient()
  9. ...
  10. 4bc1e234 24206fbe xxxBLL.GetxxxCount(System.Collections.Generic.Dictionary`2<System.String,System.Object>)
  11. 4bc1e3e0 216e25f9 DynamicClass.lambda_method(System.Runtime.CompilerServices.Closure, System.Web.Mvc.ControllerBase, System.Object[])
  12. 4bc1e3f0 238b86b7 System.Web.Mvc.ActionMethodDispatcher.Execute(System.Web.Mvc.ControllerBase, System.Object[])
  13. ...
  14. 4bc1eee0 2353d448 System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32)
  15. 4bc1efb8 00a9e3c2 [ContextTransitionFrame: 4bc1efb8]
复制代码

从卦中可以看到当前有 371个线程在 PooledRedisClientManager.GetClient 中的 Wait 上出不来，那为什么出不来呢？
2. 探究源码

要想找到这个答案，只能从源代码中观察，简化后的代码如下：
  1.     public IRedisClient GetClient()
  2.     {
  3.         lock (writeClients)
  4.         {
  5.             AssertValidReadWritePool();
  6.             RedisClient inActiveWriteClient;
  7.             while ((inActiveWriteClient = GetInActiveWriteClient()) == null)
  8.             {
  9.                 if (!Monitor.Wait(writeClients, PoolTimeout.Value))
  10.                 {
  11.                     throw new TimeoutException("Redis Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use.");
  12.                 }
  13.             }
  14.         }
  15.     }
  17.     private RedisClient GetInActiveWriteClient()
  18.     {
  19.         int num = WritePoolIndex % writeClients.Length;
  20.         for (int i = 0; i < ReadWriteHosts.Count; i++)
  21.         {
  22.             int num2 = (num + i) % ReadWriteHosts.Count;
  23.             RedisEndPoint redisEndPoint = ReadWriteHosts[num2];
  24.             for (int j = num2; j < writeClients.Length; j += ReadWriteHosts.Count)
  25.             {
  26.                 if (writeClients[j] != null && !writeClients[j].Active && !writeClients[j].HadExceptions)
  27.                 {
  28.                     return writeClients[j];
  29.                 }
  30.             }
  31.         }
  32.         return null;
  33.     }
复制代码
细致阅读卦中代码，之所以进入Wait主要是因为 GetInActiveWriteClient() 方法返回 null 所致，从非常信息看也知道此时是因为 writeClients 池已满，那这个池是不是满了呢？可以把 writeClients 数组挖出来，利用 !dso 命令。
  1. 0:429:x86> !dso
  2. OS Thread Id: 0x22f4 (429)
  3. ESP/REG  Object   Name
  4. ...
  5. 4BC1E0D0 0ea38d18 ServiceStack.Redis.RedisClient[]
  6. 4BC1E100 0ea38bb0 ServiceStack.Redis.PooledRedisClientManager
  7. ...
  9. 0:429:x86> !da 0ea38d18
  10. Name:        ServiceStack.Redis.RedisClient[]
  11. MethodTable: 237af1c0
  12. EEClass:     0129a224
  13. Size:        52(0x34) bytes
  14. Array:       Rank 1, Number of elements 10, Type CLASS
  15. Element Methodtable: 237ae954
  16. [0] 0ea38dd4
  17. [1] 0a9f9f58
  18. [2] 0296e468
  19. [3] 0c9786a0
  20. [4] 0a9fe768
  21. [5] 04a21f24
  22. [6] 0aa0d758
  23. [7] 10946d90
  24. [8] 04a8c8b0
  25. [9] 02a2a2a0
  27. 0:429:x86> !DumpObj /d 0ea38dd4
  28. Name:        ServiceStack.Redis.RedisClient
  29. MethodTable: 237ae954
  30. EEClass:     2375d154
  31. Size:        152(0x98) bytes
  32. File:        C:\Windows\xxx\ServiceStack.Redis.dll
  33. Fields:
  34. ...
  35. 0129aa48  4000169       7d       System.Boolean  1 instance        1 <Active>k__BackingField
  36. ...
复制代码
从卦中看 writeClients 池只有10个大小，并且都是 Active=1，所以返回 null 就不足为奇了。
3. 为什么client都在利用中呢

要想找到这个答案，必要看下上层的 xxxBLL.GetxxxCount 方法是如何调用的，为了掩护隐私，就多模糊一点。

从图中可以看到，题目出在用 foreach 去不断的迭代 ServiceStack.Redis 导致 writeClient 池耗尽，导致大量的请求在不断的壅闭，不要忘了这里有371个线程在争抢哦，真是大忌。
接下来顺带洞察下这个 foreach 要 foreach 多少次？ 继续用 !dso 去挖。
  1. 0:429:x86> !DumpObj /d 077cec20
  2. Name:        System.Collections.Generic.List`1[[xxxInfo, xxx]]
  3. MethodTable: 241ad794
  4. EEClass:     0193166c
  5. Size:        24(0x18) bytes
  6. File:        C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
  7. Fields:
  8.       MT    Field   Offset                 Type VT     Attr    Value Name
  9. 01860eec  4001891        4     System.__Canon[]  0 instance 077e0048 _items
  10. 0129c9b0  4001892        c         System.Int32  1 instance      307 _size
  11. 0129c9b0  4001893       10         System.Int32  1 instance      307 _version
  12. 01296780  4001894        8        System.Object  0 instance 00000000 _syncRoot
  13. 01860eec  4001895        4     System.__Canon[]  0   static  <no information>
复制代码
从卦中看当前必要循环307次，也就再次验证了池耗尽的说法，我知道心细的朋友肯定会说，卡死这个我认，但能导致 CPU爆高 我就不能理解了，其实你细致阅读源码就能理解了，这是经典的 锁护送(lock convoy) 征象，因为满意如下两个条件。
4. 如何解决这个题目

知道了前因结果，解决起来就比力简朴了，三种做法：
三：总结

这次生产事故分析还黑白常故意思的，一个看似壅闭的题目也会引发CPU爆高，超出了一些人的认知吧，对，其实它就是经典的 lock convoy 征象，大家有任何dump题目可以找我，一如既往的免费分析。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4