蓝盟IT小贴士，来喽！
windbg分析
1. GC捣蛋鬼分析
GC恶作剧的本质是GC出现回收压力，特别是向大对象堆分配和释放，大家应该知道大对象堆采用连锁管理法，万不得已GC无法将其回收，所以上面的分配和释放都是CPU密集型操作，
2 .使用x命令进行搜索
windbg包含一个快捷命令x，用于在非托管堆中搜索指定关键字。 在搜索之前，请确定此dump使用哪个框架版本和哪个关键字。
如文件版本所示，当前基于net框架4.8。 是的，我用x clr。 SVR : GC _ heap 3360: trigger *会检查是否有触发GC的操作。
到了这里就差不多可以确定是gc印章的鬼了。 下一个爱好是GetUserLoginGameMapIds ()在做什么
分析GetUserLoginGameMapIds ()方法
然后导出方法的源代码，然后使用！ name2ee找到所属的模块后通过！ 保存模块导出模块的源代码。
由此可见，这是一种EF读取数据库的复杂写法，朋友说这段代码涉及多个表的相关操作，是一种资源密集型方法。
4 .你到底有着怎样的大对手呢？
方法逻辑读完了。 然后，您可以查看GetUserLoginGameMapIds ()方法分配了哪些大对象以触发GC，从而搜索并使用50个线程的调用栈。 clrstack -a调用所有参数局部变量。
从调用栈来看，EF的读取逻辑需要向List添加记录，因此会触发List的扩展机制。 这是因为此扩展导致了GC大对象的分配。
那你觉得怎么样？ 很简单，请先把this ()=0x08053f6c里面的地址do出来！ do0x08053f6c将调用列表。
看到上面的_size=32768了吗？ 正好是2的15次方。 由于需要扩展才能再次添加，因此List在底部分配System.__Canon[65536]数组以存储旧内容。 这个数组一定大于一个名为85000字节的大对象的定义值。如果有兴趣的话，可以看看List的扩展机制。
3 :总结
知道前因后果后，大致提出三点优化建议。
最佳方法是优化GetUserLoginGameMapIds ()方法中的逻辑。
从dump来看也是4核4G的小机器，提高了机器的配置，可能有点。
文/上海蓝盟 IT外包专家
中文
电话咨询
微信咨询
公众号
