windbg sos使用就不写了，网上已有大量教程。
运维发来截图，IIS CPU爆高。
使用!tp
1、查看同步块表如下：
2、查看GC，如下：有线程此时处于GC状态
根据结构gc_heap::settings与枚举gc_reason对照。
从上图上看，有GC处于2代回收，回收原因为4（大对象分配），从下图也统计也可看出，在有10个线程上存在大对象分配操作，导致GC触发。这也是导致CPU高的其中一个原因（后续分析）。
使用!gcroot随便抽一个查看lock对象引用根，如下图，基本上来自于System.Collections.Generic.Dictionary。
使用命令：!dumpheap -live -min 8196 -type System.Collections.Generic.Dictionary
使用命令!mdt展开查看table对象，如下，由图可知，这里存在1024个lock对象，以及3w+个元素。
1、使用命令!dumpheap -stat查看所有托管堆状态，如下图：
2、再使用!dumpheap -live -min 8196 -mt 来查看String方法表中>8196的对象信息，.net将>8196的对象定义为大对象，如下图，还不少：
从案发至今，现场共发回给笔者3份dump，其分析结论均指向序列化与反序列化问题，以及大对象导致的GC回收问题。
笔者将分析反馈研发后于2024.3.21优化后当日中午紧急升级；
下午接前方反馈经监控cpu已回落至30%左右；
3.22上午监控平均也在30%左右。
看雪ID：cmdxhz
https://bbs.kanxue.com/user-home-116953.htm
#
原文始发于微信公众号（看雪学苑）：一次.net cpu爆高分析-windbg sos基本命令使用及分析思路
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论