一:背景 1. 讲故事 前几天有位朋友加wx说他的程序遭遇了内存暴涨,求助如何分析? 和这位朋友聊下来,这个dump也是取自一个HIS系统,如朋友所说我这真的是和医院杠上了,这样也好,给自己攒点资源,好了,不扯了,上windbg说话. 二: windbg 分析 1. 托管还是非托管? 既然是内存暴涨,那就看看当前进程的 commit 内存有多大? 0:000> !address -summary --- State Summary ---------------- RgnCount ------…

一:背景 1. 讲故事 七月中旬有一位朋友加wx求助,他的程序在生产上跑着跑着内存就飙起来了,貌似没有回头的趋势,询问如何解决,截图如下: 和这位朋友聊下来,感觉像是自己在小县城当了个小老板,规律的生活,有当地资源,各种小关系,有一股财务自由的味道,这也是我一直向往的生活方式 . 既然朋友找到我了,我得想办法给他解决问题,既然是内存暴涨,我就赌一把在托管层面吧,嘿嘿,上windbg说话. 二: windbg 分析 1. 托管还是非托管 一直在追这个系列的朋友应该知道,我无数次的用 !addres…

一:背景 1. 讲故事 前段时间有位朋友找到我,说他的程序内存占用比较大,寻求如何解决,截图就不发了,分析下来我感觉除了程序本身的问题之外,.NET5 在内存管理方面做的也不够好,所以有必要给大家分享一下. 二:WinDbg 分析 1. 托管还是非托管泄漏 这个还是老规矩 !address -summary 和 !eeheap -gc 组合命令排查一下. 0:000> !address -summary Mapping file section regions... Mapping module…

一:背景 1. 讲故事 前段时间微信上有一位老朋友找到我,说他的程序跑着跑着内存会突然爆高,有时候会下去,有什么会下不去,怀疑是不是某些情况下存在内存泄露,让我帮忙分析一下,其实内存泄露方面的问题还是比较好解决的,看过这个dump之后觉得还是有一定的分享价值,拿出来和大家分享一下吧. 二:WinDbg 分析 1. 托管还是非托管泄露 这个首先是一定要确定的,否则就是南辕北辙,强调再多也不为过,可以用 !address -summary 观察一下. 0:000> !address -summary…

一:背景 1. 讲故事 前几天有位朋友加 wx 抱怨他的程序在高峰期总是莫名其妙的cpu爆高,求助如何分析? 和这位朋友沟通下来,据说这问题困扰了他们几年,还请了微软的工程师过来解决,无疾而终,应该还是没找对微软的大佬... 关于程序CPU爆高的问题,老读者应该知道我都写了好几篇了,基本上归为两类: GC 触发 大量 lock 锁 少部分就是各种莫名其妙的问题了,无法一一列举 ,既然朋友找到我了,我得想办法给他解决,话不多聊,上 windbg. 二: windbg 分析 1. 查看同步块表 遇到…

一:背景 1. 讲故事 上个月有位朋友加微信求助,说他的程序跑着跑着就内存爆掉了,寻求如何解决,截图如下: 从聊天内容看,这位朋友压力还是蛮大的,话说这貌似是我分析的第三个 MES 系统了,看样子 .NET 在传统工厂是巨无霸的存在哈... 话不多说,一起用 Windbg 一探究竟吧. 二:Windbg 分析 1. 托管还是非托管 先看下进程的commit内存,用 !address -summary 即可. 0:000> !address -summary Mapping file sectio…

一:背景 1. 讲故事 前几天有位朋友加wx求助说他的程序最近总是出现内存溢出,很崩溃,如下图: 和这位朋友聊下来,发现他也是搞医疗的,哈哈,.NET 在医疗方面还是很有市场的,不过对于内存方面出的问题,我得先祈祷一下千万不要是非托管... 废话不多说,上 windbg,看能不能先救个急. 二: windbg 分析 1. 找出异常对象 如果内存溢出了,大家应该知道 C# 会抛一个 OutOfMemoryException 异常,而且还会附加到那个执行线程上,所以先用 !t 命令调出当前的所有托管…

一:背景 1. 讲故事 上个月有位朋友找到我,说他的程序出现了内存泄漏,不知道如何进一步分析,截图如下: 朋友这段话已经说的非常言简意赅了,那就上 windbg 说话吧. 二:Windbg 分析 1. 到底是哪一方面的泄漏 根据朋友描述,程序运行一段时间后,内存就炸了,应该没造成人员伤亡,不然也不会跟我wx聊天了,这里可以用 .time 看看当前的 process 跑了多久. 0:000> .time Debug session time: Thu Oct 21 14:54:39.000 202…

一:背景 1. 讲故事 我在年前写过一篇关于CPU爆高的分析文章 再记一次 应用服务器 CPU 暴高事故分析 ,当时是给同济做项目升级,看过那篇文章的朋友应该知道,最后的结论是运维人员错误的将 IIS 应用程序池设成 32bit 导致了事故的发生,这篇算是后续,拖了好久才续上哈. 犹记得那些天老板天天找我们几个人开会,大概老板是在传导甲方给过来的压力,人倒霉就是这样,你说 CPU 爆高可怕吧,我硬是给摁下去了,好了,Memory 又爆高了,尼玛我又给摁下去了,接着数据库死锁又来了,你能体会到这种…

一:背景 1. 讲故事 昨天有位朋友找到我,说他的程序内存存在泄露导致系统特别卡,大地址也开了,让我帮忙看一下怎么回事?今天上午看了下dump,感觉挺有意思,在我的分析之旅中此类问题也蛮少见,算是完善一下体系吧. 二:WinDbg 分析 1. 到底是哪里的泄露 在.NET高级调试训练营中,我多次告诉学员们,在分析此类问题时一定要搞清楚是托管还是非托管的问题,否则就南辕北辙啦,接下来使用 !address -summary 观察下内存段. 0:000:x86> !address -summary…