上篇博客中给大家分享了使用Windbg进行Live Debugging: Windbg程序调试系列4-Live Debugging 本篇中我们继续,跟大家分享常见的应用程序高CPU使用率问题分析. 先说Windows下CPU使用率这个概念: CPU使用率:在任务管理器的刷新周期内CPU忙的时间与整个刷新周期的比值.默认的刷新周期是1s. 即1s内,反映出系统的CPU繁忙程度 我们打开Windows的任务管理器,可以看到CPU的使用率: 当然,这个CPU使用率是整个所有核心CPU的使用率.比如我本

一:背景 1. 讲故事 上个月有个老朋友找到我,说他的站点晚高峰 CPU 会突然爆高,发了两份 dump 文件过来,如下图: 又是经典的 CPU 爆高问题,到目前为止,对这种我还是有一些经验可循的. 抓 2-3 个 dump 第一个:有利于算两份 dump 中的线程时间差,从而推算最耗时线程. 第二个:有时候你抓的dump刚好线程都处理完了,cpu 还未真实回落,所以分析这种dump意义不大,我是吃了不少亏. 优先推测是否为 GC 捣鬼 现在的码农都精怪精怪的,基本不会傻傻的写出个死循环,绝大部

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

一:背景 1. 讲故事 前几天有位朋友wx求助,它的程序内存经常飙升,cpu 偶尔飙升,没找到原因,希望帮忙看一下. 可惜发过来的 dump 只有区区2G,能在这里面找到内存泄漏那真有两把刷子...,所以我还是希望他的程序内存涨到 5G+ 的时候再给我看看,既然内存看不了,那就看看这个偶尔飙升的CPU是个啥情况?老办法,上windbg说话. 二: windbg 分析 1. CPU 到底是多少 要想查看这个快照生成时机器的cpu使用率,可以使用 !tp 命令. 0:033> !tp CPU uti

一:背景 1. 讲故事 前几天有位朋友wx求助,它的程序CPU经常飙满,没找到原因,希望帮忙看一下. 这些天连续接到几个cpu爆高的dump,都看烦了,希望后面再来几个其他方面的dump,从沟通上看,这位朋友表现的好惨,可能实际更惨,那既然找到我了,我就尽最大能力帮他找到幕后真凶,话不多说,上 windbg. 二: windbg 分析 1. 查看托管线程 因为线程都是靠cpu养着,所以从线程上入手也是一个很好的思路,要想查看程序的所有托管线程,可以使用 !t 命令. 0:000> !t Thre

一:背景 1. 讲故事 已经连续写了几篇关于内存暴涨的真实案例,有点麻木了,这篇换个口味,分享一个 CPU爆高 的案例,前段时间有位朋友在 wx 上找到我,说他的一个老项目经常收到 CPU > 90% 的告警信息,挺尴尬的. 既然找到我,那就用 windbg 分析呗,还能怎么办. 二: windbg 分析 1. 勘探现场 既然说 CPU > 90%,那我就来验证一下是否真的如此? 0:359> !tp CPU utilization: 100% Worker Thread: Total:

一:背景 1. 讲故事 这是6月中旬一位朋友加wx求助dump的故事,他的程序 cpu爆高UI卡死,问如何解决,截图如下: 在拿到这个dump后,我发现这是一个关于机械臂的MRS程序,哈哈,在机械臂这种智能机器人领域居然还有 .NET 的用武之地,有点超出我的认知哈,不知道把员工当兄弟的大强子仓库里可有 .NET 控制的几台机械臂 . 关于界面卡死的问题我这里就不讨论了,只讨论这个cpu爆高的问题如何解决,毕竟追这个系列的朋友都被前面那些各种 内存泄漏,内存爆涨 弄倦了,换个口味也挺好. 二:

一:背景 1. 讲故事 这个月初,一位朋友加微信求助他的程序出现了 CPU 偶发性爆高,希望能有偿解决一下. 从描述看,这个问题应该困扰了很久,还是医院的朋友给力,开门就是 100块 红包 ,那既然是偶发性爆高,人工不行,还得用 procdump 自动抓,用 procdump -ma -s 5 -n 2 -c 70 w3wp 埋伏好,几天后如愿生成了两个dump,太妙了,接下来就用 windbg 分析吧. 二:Windbg 分析 1. 真的是cpu爆高吗 一切只相信数据,这里用 !tp 看一下此

一:背景 1. 讲故事 前天有位朋友加微信求助他的程序出现了CPU爆高的问题,开局就是一个红包,把我吓懵了! 由于是南方小年,我在老家张罗处理起来不方便,没有第一时间帮他处理,朋友在第二天上午已经找出问题了,反馈说是一个 while(true) 导致的,这就有点意思了,在我分析的众多 CPU 爆高案例中,还真没遇到 while(true) 的情况,一直都抱有遗憾,真是运气好,年前赶上了,哈哈 . 接下来我们就用 windbg 一起来分析下吧. 二:Windbg 分析 1. 查看CPU占用率 一直

一:背景 1. 讲故事 年前有位朋友加微信求助,说他的程序出现了偶发性CPU爆高,寻求如何解决,截图如下: 我建议朋友用 procdump 在 cpu 高的时候连抓两个dump,这样分析起来比较稳健,朋友也如期的成功抓到,接下来就用 windbg 一起来分析下吧. 二:Windbg 分析 1. 查看CPU占用率 先用 !tp 查看两个 dump 的cpu 利用率 0:112> !tp CPU utilization: 100% Worker Thread: Total: 138 Running:

一:背景 1. 讲故事 前段时间有位朋友在微信上找到我,说他的 web 系统 cpu 运行一段时候后就爆高了,让我帮忙看一下是怎么回事,那就看吧,声明一下,我看 dump 是免费的,主要是锤炼自己技术,没有某软工程师高额的技术分析费. 闲话不多说,我们上 windbg 说话. 二:WinDbg 分析 1. CPU 真的爆高吗 是否真的爆高,我们得自己先验证下,使用 !tp 命令看一下即可. 0:065> !tp CPU utilization: 81% Worker Thread: Total:

一:背景 1. 讲故事 哈哈,再次见到物流类软件,上个月有位朋友找到我,说他的程序出现了 CPU 爆高,让我帮忙看下什么原因,由于那段时间在苦心研究 C++,分析和经验分享也就懈怠了,今天就给大家安排上. 话不多说,上 windbg 说话. 二:WinDbg 分析 1. CPU 真的爆高吗 既然说 CPU 爆高,那就用 !tp 验证下. 0:000> !tp Method table is shared (not implemented): System.Threading.ThreadPool

一:背景 1.讲故事 前段时间有位朋友微信找到我,说他的程序出现了 CPU 爆高,帮忙看下程序到底出了什么情况?图就不上了,我们直接进入主题. 二:WinDbg 分析 1. CPU 真的爆高吗? 要确认是否真的爆高,可以使用 !tp 观察. 0:000> !tp CPU utilization: 96% Worker Thread: Total: 36 Running: 36 Idle: 0 MaxLimit: 32767 MinLimit: 16 Work Request in Queue:

一:背景 1.讲故事 前段时间有位朋友加微信,说他的程序直接 CPU=100%,每次只能手工介入重启,让我帮忙看下到底怎么回事,哈哈,这种CPU打满的事故,程序员压力会非常大, 我让朋友在 CPU 高的时候抓 2 个 dump 下来,然后发给我分析. 二:WinDbg 分析 1. CPU 真的被打满了吗? 为了防止南辕北辙,一定要用 !tp 命令去验证下是不是真的 CPU 爆高. 0:000> !tp CPU utilization: 100% Worker Thread: Total: 21

昨天下午,测试反映trunk测试环境的数据库CPU一直100%,一开始以为是病毒,内网这段时间老是有个挖矿的病毒,查了一下被隔离了,但是数据库还是慢,停掉SQL server的服务CPU降下来,启动SSQL server的服务器就CPU就到100%,按照正常情况, SQL Server导致CPU爆高,一般是异常SQL引起,但查询了监控: 查询是RiskControlAnalysis,TaskTrunk库的sql比较多,先分离RiskControlAnalysis看看是否是这个库的原因,分离后CP

大概有11天没发文了,真的不是因为懒,本想前几天抽空写,不知道为啥最近求助的朋友比较多,一天都能拿到2-3个求助dump,晚上回来就是一顿分析,有点意思的是大多朋友自己都分析了几遍或者公司多年的牛皮藓问题,真的是心太累,不过也好,累那是走上坡路. 再回到正题,在一个月前,有位朋友wx找到我,他最近也在学习如何分析dump,可能经验不是很丰富,分析不下去了,截图如下: 虽然dump中的问题千奇百怪,但如果要汇成大类,还是有一些规律可循的,比如:gc频繁触发,大量锁 等等,详细汇总可以观摩我的星球,

一:背景 1. 前言 大概有2个月没写博客了,不是不想写哈

[1]问题描述 首先,查看top,下图来自网络 为什么会有%CPU 375??? 还可以超过100%的? 这是因为,有多核CPU.如图,top后,按数字1,即可出现下图. [2]排查办法(当前CPU爆高) [2.1]查看锁情况及对应语句 SELECT * FROM information_schema.INNODB_TRX; 查看一下有没有执行时间特别长的语句,或者资源耗费特别大的.找出来优化 [2.2]查看当前运行语句 select * from information_schema.proc

一:背景 1. 讲故事 上周四有位朋友加wx咨询他的程序出现 CPU + 线程 双高的情况,希望我能帮忙排查下,如下图: 从截图看只是线程爆高,没看到 cpu 爆高哈,有意思的是这位朋友说他: 一直在手动回收 ,不知道为啥看着特别想笑,但笑着笑着就哭了. 可能朋友知道老规矩,发了两份dump过来,接下来我就可以开工了,既然说高峰期分分钟上千个线程,和我前几天分享的那篇 串口 的问题很像,肯定是个别线程退不出 锁,导致 CLR 需要创建更多的线程池线程来应付不断累积的 Work Queue,所以还

一:背景 1. 讲故事 上个月有位朋友加wx告知他的程序有挂死现象,询问如何进一步分析,截图如下: 看这位朋友还是有一定的分析基础,可能玩的少,缺乏一定的分析经验,当我简单分析之后,我发现这个dump挺有意思的, CPU,内存,挂死 三样全占,程序悲惨莫过于此... 既然找到我,我得想办法化解他的痛苦,由易到难我们逐一分析这三样都是因为什么原因所致? 二:三高分析 1. 挂死原因 根据 40+ 的dump分析经验,挂死大多是由于某种情况导致线程卡死,导致后续请求堆积在 threadpool 中,

一:背景 相信很多人都知道通过 任务管理器 抓取dump,虽然简单粗暴,但无法满足程序的无数种死法,比如: 内存膨胀,程序爆炸 CPU爆高,程序累死 应用无响应,用户气死 意外退出,和人生一样 既然手工太弱鸡,那有什么好的工具呢? 除了 adplus,本文推荐一款神器 procdump, 下载地址:https://docs.microsoft.com/zh-cn/sysinternals/downloads/procdump ,还能支持 linux ,具体怎么安装就不细说了. 二:内存膨胀,程序