linux故障定位，运维必备
|
linux故障定位，运维必备
What-现象是什么样的
针对应用程序，我们通常关注的是内核CPU调度器功能和性能。 线程的状态分析主要是分析线程的时间用在什么地方，而线程状态的分类一般分为： a. on-CPU：执行中，执行中的时间通常又分为用户态时间user和系统态时间sys。 b. off-CPU：等待下一轮上CPU，或者等待I/O、锁、换页等等，其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。 如果大量时间花在CPU上，对CPU的剖析能够迅速解释原因；如果系统时间大量处于off-cpu状态，定位问题就会费时很多。但是仍然需要清楚一些概念： 处理器 核 硬件线程 CPU内存缓存 时钟频率 每指令周期数CPI和每周期指令数IPC CPU指令 使用率 用户时间／内核时间 调度器 运行队列 抢占 多进程 多线程 字长 4.2 分析工具 Linux 问题故障定位，看这一篇就够了，九招搞定所有问题 说明: uptime,vmstat,mpstat,top,pidstat只能查询到cpu及负载的的使用情况。 perf可以跟着到进程内部具体函数耗时情况，并且可以指定内核函数进行统计，指哪打哪。 4.3 使用方式 //查看系统cpu使用情况 top //查看所有cpu核信息 mpstat -P ALL 1 //查看cpu使用情况以及平均负载 vmstat 1 //进程cpu的统计信息 pidstat -u 1 -p pid //跟踪进程内部函数级cpu使用情况 perf top -p pid -e cpu-clock
内存是为提高效率而生，实际分析问题的时候，内存出现问题可能不只是影响性能，而是影响服务或者引起其他问题。同样对于内存有些概念需要清楚： 主存 5.2 分析工具 Linux 问题故障定位，看这一篇就够了，九招搞定所有问题 说明： free,pidstat,pmap只能统计内存信息以及进程的内存使用情况。 5.3 使用方式 //查看系统内存使用情况 6. 磁盘IO 6.1 说明 磁盘通常是计算机最慢的子系统，也是最容易出现性能瓶颈的地方，因为磁盘离 CPU 距离最远而且 CPU 访问磁盘要涉及到机械操作，比如转轴、寻轨等。访问硬盘和访问内存之间的速度差别是以数量级来计算的，就像1天和1分钟的差别一样。要监测 IO 性能，有必要了解一下基本原理和 Linux 是如何处理硬盘和内存之间的 IO 的。 在理解磁盘IO之前，同样我们需要理解一些概念，例如： 文件系统 6.2 分析工具 Linux 问题故障定位，看这一篇就够了，九招搞定所有问题 6.3 使用方式 //查看系统io信息 7. 网络 7.1 说明 网络的监测是所有 Linux 子系统里面最复杂的，有太多的因素在里面，比如：延迟、阻塞、冲突、丢包等，更糟的是与 Linux 主机相连的路由器、交换机、无线信号都会影响到整体网络并且很难判断是因为 Linux 网络子系统的问题还是别的设备的问题，增加了监测和判断的复杂度。现在我们使用的所有网卡都称为自适应网卡，意思是说能根据网络上的不同网络设备导致的不同网络速度和工作模式进行自动调整。 7.2 分析工具 Linux 问题故障定位，看这一篇就够了，九招搞定所有问题 //显示网络统计信息 8. 系统负载 8.1 说明 Load 就是对计算机干活多少的度量（WikiPedia：the system Load is a measure of the amount of work that a compute system is doing）简单的说是进程队列的长度。Load Average 就是一段时间（1分钟、5分钟、15分钟）内平均Load。 8.2 分析工具 Linux 问题故障定位，看这一篇就够了，九招搞定所有问题 8.3 使用方式 //查看负载情况
火焰图（Flame Graph是 Bredan Gregg 创建的一种性能分析图表，因为它的样子近似 ?而得名。 火焰图主要是用来展示 CPU的调用栈。 y 轴表示调用栈，每一层都是一个函数。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。 x 轴表示抽样数，如果一个函数在 x 轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间长。注意，x 轴不代表时间，而是所有的调用栈合并后，按字母顺序排列的。 火焰图就是看顶层的哪个函数占据的宽度最大。只要有”平顶”（plateaus），就表示该函数可能存在性能问题。颜色没有特殊含义，因为火焰图表示的是 CPU 的繁忙程度，所以一般选择暖色调。 常见的火焰图类型有On-CPU、Off-CPU、Memory、Hot/Cold、Differential等等。 9.2 安装依赖库 //安装systemtap，默认系统已安装 git clone https://github.com/lidaohang/quick_location.git cpu占用过高，或者使用率提不上来，你能快速定位到代码的哪块有问题吗？ 一般的做法可能就是通过日志等方式去确定问题。现在我们有了火焰图，能够非常清晰的发现哪个函数占用cpu过高，或者过低导致的问题。 9.4.1 on-CPU cpu占用过高，执行中的时间通常又分为用户态时间user和系统态时间sys。 使用方式： //on-CPU user #include <stdio.h> DEMO火焰图： Linux 问题故障定位，看这一篇就够了，九招搞定所有问题 9.4.2 off-CPU cpu过低，利用率不高。等待下一轮CPU，或者等待I/O、锁、换页等等，其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。 使用方式： // off-CPU user
Linux 问题故障定位，看这一篇就够了，九招搞定所有问题 9.5 内存级别火焰图 如果线上程序出现了内存泄漏，并且只在特定的场景才会出现。这个时候我们怎么办呢？有什么好的方式和工具能快速的发现代码的问题呢？同样内存级别火焰图帮你快速分析问题的根源。 使用方式： sh ngx_on_memory.sh pid //进入结果目录 cd ngx_on_memory //开一个临时端口8088 python -m SimpleHTTPServer 8088 //打开浏览器输入地址 127.0.0.1:8088/pid.svg 9.6 性能回退-红蓝差分火焰图 你能快速定位CPU性能回退的问题么？ 如果你的工作环境非常复杂且变化快速，那么使用现有的工具是来定位这类问题是很具有挑战性的。当你花掉数周时间把根因找到时，代码已经又变更了好几轮，新的性能问题又冒了出来。主要可以用到每次构建中，每次上线做对比看，如果损失严重可以立马解决修复。 通过抓取了两张普通的火焰图，然后进行对比，并对差异部分进行标色：红色表示上升，蓝色表示下降。 差分火焰图是以当前（“修改后”）的profile文件作为基准，形状和大小都保持不变。因此你通过色彩的差异就能够很直观的找到差异部分，且可以看出为什么会有这样的差异。 使用方式： cd quick_location //抓取代码修改前的profile 1文件 perf record -F 99 -p pid -g -- sleep 30 perf script > out.stacks1 //抓取代码修改后的profile 2文件 perf record -F 99 -p pid -g -- sleep 30 perf script > out.stacks2 //生成差分火焰图: ./FlameGraph/stackcollapse-perf.pl ../out.stacks1 > out.folded1 ./FlameGraph/stackcollapse-perf.pl ../out.stacks2 > out.folded2 ./FlameGraph/difffolded.pl out.folded1 out.folded2 | ./FlameGraph/flamegraph.pl > diff2.svg DEMO： //test.c
#include <stdio.h>
#include <stdlib.h>
void foo3()
{
}
void foo2()
{
int i;
for(i=0 ; i < 10; i++)
foo3();
}
void foo1()
{
int i;
for(i = 0; i< 1000; i++)
foo3();
}
int main(void)
{
int i;
for( i =0; i< 1000000000; i++) {
foo1();
foo2();
}
}
//test1.c
#include <stdio.h>
#include <stdlib.h>
void foo3()
{
}
void foo2()
{
int i;
for(i=0 ; i < 10; i++)
foo3();
}
void foo1()
{
int i;
for(i = 0; i< 1000; i++)
foo3();
}
void add()
{
int i;
for(i = 0; i< 10000; i++)
foo3();
}
int main(void)
{
int i;
for( i =0; i< 1000000000; i++) {
foo1();
foo2();
add();
}
}
（编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
