文章目录
可能的原因
程序设计的BUG
- 有死循环
- 低效算法与数据结构
- 滥用自旋锁
- 频繁的系统调用，导致用户态与内核态频繁切换
系统资源问题
- 内存不足，系统频繁使用硬盘交换分页
恶意软件
- 后台运行的病毒或流氓软件或自动更新的软件
硬件问题
- 散热不良
- 硬件老化
通常步骤
- 找到问题的进程
- 找到问题的线程
- 找到问题的代码位置
- 分析原因
一个简单的问题代码
#include <iostream>
#include <thread>
#include <vector>
void busy_task()
{
while(true) {}
}
void slow_algorithm()
{
for (auto i = 0L ; i < 1000000000L; ++i)
{
volatile auto x = i * i;
}
}
int main()
{
std::vector<std::thread> threads;
threads.emplace_back(busy_task);
threads.emplace_back(slow_algorithm);
for(auto& t: threads)
{
t.join();
}
return EXIT_SUCCESS;
}
程序以DEBUG模式编译成fst0.exe 与 fst0.pdb
在windows平台上如何排查
Windows Process Explorer
需要借助工具WindowsProcessExplorer
fst0.exe 在运行中
以管理员权限运行ProcExp，切记32 位的fst0.exe 要用32位的ProcExp,64位的fst0.exe要用64位的ProcExp
过滤出目标同时打开线程窗口
可以看到占用CPU过高的线程
我们需要设置符号文件路径
32位的程序用32位的pdb符号文件路径，64位的程序用64位的pdb符号文件路径
然后右键点击线程中的调用堆栈
可以清晰的看到程序是卡在busy_task那个函数上了！
WinDBG
怎么安装WinDbg这里就跨过，使用WinDbg时要切记，32位的程序使用32位的WinDbg调试，同时要使用32位pdb文件，64位的程序使用64位的WinDbg调试，同时要使用64位的pdb文件， WinDbg最好用管理员权限打开。
先行设置好符号路径与源码路径
现在Fst0.exe 已经在运行当中了，使用WinDbg来附加到进程，
看到这里WinDbg执行 int 3 软中断暂停了进程。
在Command里面执行!runaway看看各个线程的执行时间，可以看到4号线程执行时间最长
可以看看4号线程的调用堆栈
可以明显看到卡在了busy_task 函数，点击后面的蓝色链接可以看到源码
在Command里面使用qd命令退出调试
更多关于WinDBG的知识请上网自行搜索学习
在Linux平台如何排查
使用TOP + GDB
先以Debug模式编译出fst0
g++ -g fst0.cc -o fst0 -lpthread
然后运行 fst0
然后使用top
可以看到fst0的cpu占用很高
现在知道fst0的进程号是2473，还需要知道fst0的耗时线程是哪个
执行
top -H -p 2473
可以得到线程信息
可以看到有两个线程，2473主线程号与进程号相同，2474是耗时的那个子线程号
现在需要把2474那个线程的堆栈信息打印出来
sudo gdb -p 2474 -ex "thread apply all bt" -ex "detach" -ex "quit" > stack.log
cat stack.log
可以清楚看到程序是卡在busy_task函数，fst0.cc 文件的第8行那里。
更多gdb 相关知识自行上网学习。
Perf
perf 是Linux内核提供的性能分析工具。若你需要此工具，安装步骤如下：
# 更新软件包列表
sudo apt update
# 安装与当前内核匹配的linux-tools
sudo apt install linux-tools-$(uname -r)
# 验证安装
perf --version
编译程序，运行程序，打到程序PID与上面方法相同
使用perf实时查看进程热点，动态显示系统中消耗 CPU 最多的函数或进程
# 全局监控所有进程的热点
sudo perf top
# 仅监控指定 PID 的进程
sudo perf top -p <PID>
例子
清晰的看到耗时函数是哪个