Windbg程序调试系列5-高CPU问题分析
上篇博客中给大家分享了使用Windbg进行Live Debugging:
本篇中我们继续,跟大家分享常见的应用程序高CPU使用率问题分析。
先说Windows下CPU使用率这个概念:
CPU使用率:在任务管理器的刷新周期内CPU忙的时间与整个刷新周期的比值。默认的刷新周期是1s。
即1s内,反映出系统的CPU繁忙程度
我们打开Windows的任务管理器,可以看到CPU的使用率:
当然,这个CPU使用率是整个所有核心CPU的使用率。比如我本机是8核心的CPU。整体的CPU使用率 在某一瞬间是14%。
这个CPU使用率是如何计算出来的,有两个重要的时间sysTime和idleTime:
sysTime:表示该时间段内总的CPU时间=CPU处于用户态和内核态CPU时间的总和,即sysTime =kerneTimel + userTime
(注:这里并不包括idleTime,因为当CPU处于空闲状态时,是在内核模式下运行System Idle Process这个进程,所以kernelTime实际上已经包含了idleTime);
idleTime:表示在该时间段内CPU处于空闲状态的时间;
CPU% = 1 – idleTime / sysTime * 100
说到这里,我们分析一个应用的高cpu问题,更多的是:分析用户态的CPU耗时。即,我们应用程序本身运行时消耗的CPU时间片总和。
然后,进入今天的正题,使用Windbg分析高CPU问题:
一、首先我们用C#写一个Any CPU架构的Console模拟程序
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks; namespace HighCpuDemo
{
class Program
{
static void Main(string[] args)
{
var normalThread = new Thread(NormalMethod);
normalThread.Start(); var longRunningThread = new Thread(LongRunningMethod);
longRunningThread.Start(); Console.ReadKey();
} private static void NormalMethod()
{
int a = 0;
int b = 100000;
var list = new List<int>();
for (int i = 0; i < b; i++)
{
a += i;
list.Add(a);
var max = list.Max();
var min = list.Min();
var avg = list.Average();
Console.WriteLine(string.Format("Thread:{0}, writeline:{1}", Thread.CurrentThread.ManagedThreadId, a)); //休息一下
Thread.Sleep(100);
}
} private static void LongRunningMethod()
{
for (int c = 0; c < 100000; c++)
{
int a = 0;
int b = 100000;
var list = new List<int>();
for (int i = 0; i < b; i++)
{
a += i;
list.Add(a);
var max = list.Max();
var min = list.Min();
var avg = list.Average();
Console.WriteLine(string.Format("Thread:{0}, writeline:{1}", Thread.CurrentThread.ManagedThreadId, a));
}
}
}
}
}
代码中有两个线程,一个是“正常”的计算输出线程NormalThread(每次输出,会休息一下 100s),一个是长时间运行的线程LongRunningThread,一直在计算,输出。
代码写好之后,设置为Any CPU架构,支持64位模式:
看程序输出:
很明显,3号线程是NormalThread, 4号线程是LongRunningThread。
二、 查看应用进程的CPU使用率
从任务管理器上,能够发现,HighCpuDemo这个进程的CPU使用率是12%
三、间隔30s,抓两个Dump
这里有个问题:为什么要间隔一段时间抓2个dump?我们先把问题放在这。
四、使用Windbg分析两个Dump文件,使用!runaway找到最消耗CPU时间片的线程,然后优化
Windbg打开这两个Dump后,分别执行以下命令:
:> .loadby sos clr
:> !runaway
对比看着两个Dump的输出:
第一个Dump:
Debug session time: Sun Nov 20:16:39.000 2018 (GMT+8)
System Uptime: days ::00.195
Process Uptime: days ::31.000
.............................
Loading unloaded module list
.
ntdll!ZwDeviceIoControlFile+0x14:
00007ffc`c01b03a4 c3 ret
:> .loadby sos clr
:> !runaway
User Mode Time
Thread Time
: 0 days 0:07:38.531
:325c days ::00.390
: days ::00.015
:4c3c days ::00.000
:17d0 days ::00.000
: days ::00.000
: days ::00.000
第二个Dump:
Debug session time: Sun Nov 20:17:06.000 2018 (GMT+8)
System Uptime: days ::27.136
Process Uptime: days ::58.000
.............................
Loading unloaded module list
.
ntdll!ZwDeviceIoControlFile+0x14:
00007ffc`c01b03a4 c3 ret
:> .loadby sos clr
:> !runaway
User Mode Time
Thread Time
: days 0:08:01.984
:325c days ::00.406
: days ::00.015
:4c3c days ::00.000
:17d0 days ::00.000
: days ::00.000
: days ::00.000
这里有个关键的Windbg指令 !runaway, 它有什么作用,输出的是什么:
This extension is a quick way to find out which threads are spinning out of control or consuming too much CPU time. The display identifies each thread by the debugger's internal thread numbering and by the thread ID in hexadecimal. The debugger IDs are also shown. Here is an example: :> !runaway User Mode Time
Thread Time
:55c ::00.0093
:1a4 ::00.0000 Kernel Mode Time
Thread Time
:55c ::00.0140
:1a4 ::00.0000 Elapsed Time
Thread Time
:55c ::43.0533
:1a4 ::25.0876
使用这个指令,可以查看每个线程的"用户态"CPU使用时间:
从上面两个Dump中,我们能看出,4号线程 User Mode Time 一直在增加,我们看看4号线程的堆栈:
:> ~4s
*** WARNING: Unable to verify checksum for System.Core.ni.dll
System_Core_ni+0x588b44:
00007ffc`a4268b44 488b4de8 mov rcx,qword ptr [rbp-18h] ss:000000c1`df0ff2a8=000001d4633eb280
:> !clrstack
OS Thread Id: 0x3758 ()
Child SP IP Call Site
000000c1df0ff280 00007ffca4268b44 System.Linq.Enumerable.Min(System.Collections.Generic.IEnumerable`<Int32>)
000000c1df0ff2d0 00007ffc4b930660 *** WARNING: Unable to verify checksum for HighCpuDemo.exe
HighCpuDemo.Program.LongRunningMethod() [c:\users\zhougq\documents\visual studio \Projects\HighCpuDemo\Program.cs @ ]
000000c1df0ff3a0 00007ffca7e24770 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ ]
000000c1df0ff470 00007ffca7e24604 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ ]
000000c1df0ff4a0 00007ffca7e245d2 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ ]
000000c1df0ff4f0 00007ffca7eacff2 System.Threading.ThreadHelper.ThreadStart() [f:\dd\ndp\clr\src\BCL\system\threading\thread.cs @ ]
000000c1df0ff748 00007ffcaaf35863 [GCFrame: 000000c1df0ff748]
000000c1df0ffa98 00007ffcaaf35863 [DebuggerU2MCatchHandlerFrame: 000000c1df0ffa98]
正如我们代码中所写的,LongRunningMethod方法一直在执行、消耗CPU资源。
定位到代码问题,就可以进一步修改代码,解决问题了。
以上就是使用Windbg 调试高CPU问题的方法思路,总结一下:
1. 查看应用进程的CPU使用率
2. 间隔一段时间,抓两个Dump
3. 使用Windbg分析两个Dump文件,使用!runaway找到最消耗CPU时间片的线程,然后优化
分享给大家。
周国庆
2018/11/25
Windbg程序调试系列5-高CPU问题分析的更多相关文章
- Windbg程序调试系列3-线程阻塞问题
上一篇博文给大家分享了使用Windbg分析内存泄露问题: Windbg程序调试系列2-内存泄露问题 本篇我们继续跟大家分享,如何分析解决线程阻塞问题. 从根本上讲,线程阻塞属于程序Hang的一种,其表 ...
- Windbg程序调试系列4-Live Debugging
上篇博文中给大家分享了使用Windbg分析线程阻塞问题: Windbg程序调试系列3-线程阻塞问题 本篇中我们继续,跟大家分享附加进程实时调试-Live Debugging. 先说一下使用Windbg ...
- Windbg程序调试系列-索引篇
最近整理了一下Windbg程序调试系列的文章,做个了索引贴,方便大家查询.搜索: Windbg程序调试系列1-常用命令说明&示例 Windbg程序调试系列1-Mex扩展使用总结 Windbg程 ...
- Windbg程序调试系列1-常用命令说明&示例
Windbg程序调试是.Net高级开发需要掌握的必备技能,分析内存泄露.分析高CPU.分析线程阻塞.分析内存对象.分析线程堆栈.Live Dedugging.这个领域可以说一个技能+场景化应用的结合, ...
- Windbg程序调试系列2-内存泄露问题
上篇文章给大家解释了Windbg的基本命令和说明,这一篇给大家介绍内存泄露场景的问题分析. 文章大纲: 描述问题背景和现象 确定问题是否是内存泄露 梳理问题分析思路 动手分析解决 总结 1. 先说问题 ...
- Windbg程序调试系列1-Mex扩展使用总结
最近一直在频繁使用Windbg做线上Dump调试,与微软做Case交流的时候,发现微软CSS团队,用了一个非常效率的Windbg 插件,Mex: 使用介绍: https://blogs.msdn.mi ...
- Windows程序调试系列: 使用VC++生成调试信息 转
Windows程序调试系列: 使用VC++生成调试信息 ZhangTao,zhangtao.it@gmail.com, 译自 “Generating debug information with Vi ...
- Windbg程序调试--转载
WinDbg是微软发布的一款相当优秀的源码级(source-level)调试工具,可以用于Kernel模式调试和用户模式调试,还可以调试Dump文件. WinDbg是微软很重要的诊断调试工具: 可以查 ...
- Expert 诊断优化系列------------------你的CPU高么?
现在很多用户被数据库的慢的问题所困扰,又苦于花钱请一个专业的DBA成本太高.软件维护人员对数据库的了解又不是那么深入,所以导致问题迟迟不能解决,或只能暂时解决不能得到根治.开发人员解决数据问题基本又是 ...
随机推荐
- 艺术模板 art-template-web
艺术模板 art-template____jQuery 项目可用 最快的模板渲染引擎 兼容 ejs 语法 推荐语法 {{each arr}} {{$value}} ---- {{$index}} {{ ...
- vue全选与取消全选
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8&quo ...
- C# 复选框显示多项选择
private void Form1_Load(object sender, EventArgs e) { checkedListBox1.Items.Add("语文"); che ...
- [daily] 如何用emacs+xcscope阅读内核源码
假设 首先我假设: 你已经学会了使用emacs. 同时也学会了使用cscope. 读过cscope官网上,关于emacs的使用指引. 它的指引就是请你去阅读xcscope.el的源码,当然这无可厚非, ...
- 2018-2019-2 网络对抗技术 20165225 Exp4 恶意代码分析
2018-2019-2 网络对抗技术 20165225 Exp4 恶意代码分析 实践目标 1.1是监控你自己系统的运行状态,看有没有可疑的程序在运行. 1.2是分析一个恶意软件,就分析Exp2或Exp ...
- 神贴真开眼界:为什么很多人倡导重视能力和素质,但同时对学历有严格要求?——代表了上一场比赛的输赢,招聘成本很重要。如果上一场游戏失败了,尽量让自己成为当前群体的尖子。学历只是其中的一个作品而已,但学历代表了学生时代为之做出的牺牲。人群自有偏向集中性 good
对于软件工程师职位,没学历没关系,如果真觉得自己才高八斗,请在简历里附上 github项目链接或者 appstore/google play上你的作品.如果学历比别人低,那么想必是把时间和精力用在了其 ...
- python摸爬滚打之----tcp协议的三次握手四次挥手
TCP协议的三次握手, 四次挥手 三次握手过程 1, 服务器时刻准备接受客户端进程的连接请求, 此时服务器就进入了LISTEN(监听)状态; 2, 客户端进程然后向服务器发出连接请求报文, 之后客户端 ...
- luogu4643 [国家集训队]阿狸和桃子的游戏
题目链接:洛谷 这道题乍一看非常的难,而且题目标题上的标签让人很害怕. 但其实这道题并不难写(只要想到了...emm) 因为我们只需要知道两个人得分之差,所以我们可以对条件进行变换. 我们将边权平分到 ...
- CF1142C U2
题目链接:洛谷 codeforces $y>x^2+bx+c$也就是$y-x^2>bx+c$ 左边是点,右边是直线. 维护上凸包. 虽然这么简单但就是做不出来. #include<c ...
- php 数据库乱码。。。php 移动临时文件
数据库乱码,三个位置 处理好不会乱码 第一前台,传到后台: 第二后台,传到数据库: 第三数据库,存入数据库: 详解 https://www.cnblogs.com/zhoujinyi/p/46188 ...