一:背景 1. 讲故事 前天那位 his 老哥又来找我了,上次因为CPU爆高的问题我给解决了,看样子对我挺信任的,这次另一个程序又遇到内存泄漏,希望我帮忙诊断下. 其实这位老哥技术还是很不错的,他既然能给我dump,那真的是遇到很棘手的疑难杂症了,我得做好心理准备,沟通下来大概就是程序的内存会缓慢膨胀,直到自毁,问题就是这么一个问题,接下来祭出我的看家工具 windbg. 二: windbg 分析 1. 到底哪里泄漏了? 我在之前很多篇文章中都说过,遇到这种内存泄漏,首先就要排查到底是 托管堆…

一:背景 1. 讲故事 前段时间有位朋友wx找到我,说他的程序存在内存阶段性暴涨,寻求如何解决,和朋友沟通下来,他的内存平时大概是5G 左右,在某些时点附近会暴涨到 10G+, 画个图大概就是这样. 所以接下来就是想办法给他找到那莫名奇妙的 5-6G 是个啥,上 windbg 说话. 二:Windbg 分析 1. 判断托管还是非托管 从描述上看大概率是托管层面的问题,但为了文章的完整性,我们还是用 !address -summary 和 !eeheap -gc 来看一下. 0:000> !add…

一:背景 1. 讲故事 去年十月份有位朋友从微信找到我,说他的程序内存要炸掉了...截图如下: 时间有点久,图片都被清理了,不过有点讽刺的是,自己的程序本身就是做监控的,结果自己出了问题,太尴尬了 二:Windbg 分析 1. 托管还是非托管 这个是甄别内存问题的第一步,通过 !address -summary 和 !eeheap -gc 两个命令基本就可以断定. 0:000> !address -summary Mapping file section regions... Mapping m…

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

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

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

一:背景 1.讲故事 前些天有位朋友微信找到我,说他的程序出现了CPU阶段性爆高,过了一会就下去了,咨询下这个爆高阶段程序内部到底发生了什么? 画个图大概是下面这样,你懂的. 按经验来说,这种情况一般是程序在做 CPU 密集型运算,所以让朋友在 CPU 高的时候间隔 5~10s 抓两个 dump 下来,然后就是用 WinDbg 分析. 二:WinDbg 分析 1. CPU 真的爆高吗 耳听为虚,眼见为实,我们用 !tp 观察下当前的CPU情况. 0:000> !tp CPU utilizatio…

一:背景 1.讲故事 前段时间有位朋友微信找到我,说他生产机器上的 Console 服务看起来像是卡死了,也不生成日志,对方也收不到我的httpclient请求,不知道程序出现什么情况了,特来寻求帮助. 哈哈,一般来说卡死的情况在窗体程序(WinForm,WPF) 上特别多,在 Console,WebApi 中相对较少,既然找到我,那就上 WinDbg 分析吧. 二:WinDbg 分析 1. 程序真的卡死了吗 程序之所以能跑的梭梭响,全靠线程帮忙,如果玩不转可能就是线程上出了点什么问题,接下来使…

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

一:背景 1. 讲故事 上周四有位朋友加wx咨询他的程序内存存在一定程度的泄漏,并且无法被GC回收,最终机器内存耗尽,很尴尬. 沟通下来,这位朋友能力还是很不错的,也已经做了初步的dump分析,发现了托管堆上有 10w+ 的 byte[] 数组,并占用了大概 1.1G 的内存,在抽取几个 byte[] 的 gcroot 后发现没有引用,接下来就排查不下去了,虽然知道问题可能在 byte[],但苦于找不到证据. 那既然这么信任的找到我,我得要做一个相对全面的输出报告,不能辜负大家的信任哈,还是老规…