全国免费自学网站,郑州seo外包顾问,鲜花网络营销推广方案,建设银行网站在哪设置查询密码一#xff1a;背景 1. 讲故事我在年前写过一篇关于CPU爆高的分析文章 再记一次 应用服务器 CPU 暴高事故分析 #xff0c;当时是给同济做项目升级#xff0c;看过那篇文章的朋友应该知道#xff0c;最后的结论是运维人员错误的将 IIS 应用程序池设成 32bit 导致了事故的发生… 一背景 1. 讲故事我在年前写过一篇关于CPU爆高的分析文章 再记一次 应用服务器 CPU 暴高事故分析 当时是给同济做项目升级看过那篇文章的朋友应该知道最后的结论是运维人员错误的将 IIS 应用程序池设成 32bit 导致了事故的发生这篇算是后续????????????拖了好久才续上哈。犹记得那些天老板天天找我们几个人开会大概老板是在传导甲方给过来的压力人倒霉就是这样你说 CPU 爆高可怕吧我硬是给摁下去了好了Memory 又爆高了尼玛我又给摁下去了接着数据库死锁又来了你能体会到这种压力吗???? 就像我在朋友圈发的那样程序再不跑我就要跑了。所以有时候敬敬风水还是很有必要的有点扯远了哈这篇我们来看看程序的内存暴涨如何去排查为了让你更有兴趣来一张运维发的内存监控图。从图中可以看出9点开始内存直线暴涨绝对惊心动魄要是我的小诺安这样暴涨就好了????????????接下来 windbg 说话。二windbg 分析 1. 说一下思路内存暴涨了最怕的就是 非托管层 出了问题它的排查难度相比 托管层 要难10倍以上所以遇到这类问题先祈祷一下吧gc堆也罢loader堆也不怕所以先看看是否 进程内存 ≈ gc堆内存 ?2. 排查托管还是非托管排查方式也很简单通过 !address -summary 看看进程的已提交内存如下输出
0:000 !address -summary--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 261 7fb4b151000 ( 7.982 TB) 99.77%
MEM_RESERVE 278 26aafc000 ( 9.667 GB) 51.35% 0.12%
MEM_COMMIT 2199 24a3a3000 ( 9.160 GB) 48.65% 0.11%可以看到已提交内存是 9.1G接下来看下 gc 堆的大小使用 !eeheap -gc 即可。
0:000 !eeheap -gc
Number of GC Heaps: 8
------------------------------
Heap 0 (0000000002607740)
generation 0 starts at 0x00000001aaaa5500
generation 1 starts at 0x00000001aa3fd070
generation 2 starts at 0x0000000180021000
Heap 7 (0000000002713b40)
generation 0 starts at 0x000000053b3a2c28
generation 1 starts at 0x000000053a3fa770
generation 2 starts at 0x0000000500021000------------------------------
GC Heap Size: Size: 0x1fdfe58c8 (8556271816) bytes.从最后一行输出中可以看到当前的占用是 8556271816 / 1024 /1024 /1024 7.9G 太幸运了果然是托管层出了问题gc 上有大块脏东西这下有救了 ????????????。3. 查看托管堆知道托管堆出了问题后接下来就可以用 !dumpheap -stat 去gc堆上翻一翻。
0:000 !dumpheap -stat
Statistics:MT Count TotalSize Class Name
000007fef7b5c308 32867 788808 System.DateTime
000007fef7b5e598 33049 793176 System.Boolean
000007feec7301f8 30430 1217200 System.Web.HttpResponseUnmanagedBufferElement
000007fef7b56020 2931 3130928 System.Object[]
000007fef7b580f8 219398 5265552 System.Int32
000007fe9a0c5428 46423 7799064 xxx.Laundry.Entities.V_InvoiceInfo
000007fef7b59638 164418 7892064 System.Text.StringBuilder
000007fef7b56980 164713 10059852 System.Char[]
000007fef7b5a278 7351 26037217 System.Byte[]
000007fe9a0d8758 35 28326856 xxx.Laundry.Entities.V_ClothesTagInfo[]
0000000002536f50 76837 77016088 Free
000007fe9a327ab0 46534 312964608 xxx.Laundry.Entities.V_InvoiceClothesInfo[]
000007fe9a0c4868 2068912 397231104 xxx.Laundry.Entities.V_ClothesTagInfo
000007fef7b55b70 98986851 3483764540 System.String
000007fe9a10ef80 23998759 3839801440 xxx.Laundry.Entities.V_InvoiceClothesInfo
Total 126039641 objects我去托管堆上的 xxx.Laundry.Entities.V_InvoiceClothesInfo 对象居然高达 2399w 占了大概 3.6G这还不算其附属对象对了如果直接用 !dumpheap -mt xxx 输出 address 的话很难进行UI中止所以这里有一个小技巧用 range 来限定一下如下代码所示
0:000 !dumpheap -mt 000007fe9a10ef80 0 0000000180027b30Address MT Size
0000000180027800 000007fe9a10ef80 160
0000000180027910 000007fe9a10ef80 160
0000000180027a20 000007fe9a10ef80 160
0000000180027b30 000007fe9a10ef80 160 Statistics:MT Count TotalSize Class Name
000007fe9a10ef80 4 640 xxx.Laundry.Entities.V_InvoiceClothesInfo
Total 4 objects4. 查找引用根接下来用 !gcroot 随便找一个 address 查看它的引用链看看它到底被谁引用着
0:000 !gcroot 0000000180027800
HandleTable:00000000013715e8 (pinned handle)- 000000058003c038 System.Object[]- 00000004800238a0 System.Collections.Generic.List1[[xxx.Laundry.APIService.Models.Common.BaseModel, xxx.Laundry.APIService]]- 0000000317e01ae0 xxx.Laundry.APIService.Models.Common.BaseModel[]- 000000028010caf0 xxx.Laundry.APIService.Models.Common.BaseModel- 00000003014cbbd0 System.Collections.Generic.List1[[xxx.Laundry.Entities.V_InvoiceInfo, xxx.Laundry.Entities]]- 00000003014f3580 xxx.Laundry.Entities.V_InvoiceInfo[]- 00000003014cd7f0 xxx.Laundry.Entities.V_InvoiceInfo- 000000038cc49bf0 System.Collections.Generic.List1[[xxx.Laundry.Entities.V_InvoiceClothesInfo, xxx.Laundry.Entities]]- 000000038cc49c18 xxx.Laundry.Entities.V_InvoiceClothesInfo[]- 0000000180027800 xxx.Laundry.Entities.V_InvoiceClothesInfoFound 1 unique roots (run !GCRoot -all to see all roots).从输出中可以看到它貌似被一个 ListBaseModel 所持有哈哈总算找到了接下来就简单了直接用 !objsize 看一看它的 size 有多大
0:000 !objsize 00000004800238a0
sizeof(00000004800238a0) -1972395312 (0x8a6fa2d0) bytes (System.Collections.Generic.List1[[xxx.Laundry.APIService.Models.Common.BaseModel, xxx.Laundry.APIService]])看到上面的 -1972395312 了吗我去int 类型的 size 直接给爆掉了果然是个大对象就是你了。。。如果非要看大小也可以写一个脚本遍历一下。三总结 知道是 ListBaseModel 做的孽后仔细阅读了源码才知道原来是给用户第一次数据全量同步的时候服务端为了加速将数据缓存在 ListBaseModel 这个静态变量中很遗憾的是并没有在合适的时机进行释放造成了高峰期内存直线暴增优化方案很简单就是修改业务逻辑咯增加释放内存的时机。题外话如果你遇到的是这种 Strong Handles 的静态变量也可以直接用可视化的 dotMemory 查看。当然你要保证你有足够的内存毕竟也算是小10G的dump ???? 我的 16G 内存一下子就被吃掉了。。。善于用 String 驻留池机制来优化看看它的源码定义吧。public sealed class String{[SecuritySafeCritical]public static string Intern(string str){if (str null){throw new ArgumentNullException(str);}return Thread.GetDomain().GetOrInternString(str);}}对于那些重复度很高的string用驻留池机制可以节省千百倍的内存空间至于为什么可以优化可参考我之前的文章字符串太占内存了我想了各种奇思淫巧对它进行压缩 。END工作中的你是否已遇到 ... 1. CPU爆高2. 内存暴涨3. 资源泄漏4. 崩溃死锁5. 程序呆滞等紧急事件全公司都指望着你能解决... 危难时刻才能展现你的技术价值作为专注于.NET高级调试的技术博主欢迎微信搜索: 一线码农聊技术免费协助你分析Dump文件希望我能将你的踩坑经验分享给更多的人。
