Linux 问题故障定位，看这一篇就够了
一、 背景
有时候会遇到一些疑难杂症，而且监控插件并不能一眼立马发现问题的根源。这时候就须要登陆服务器进一步深刻分析问题的根源。那么分析问题须要有必定的技术经验积累，而且有些问题涉及到的领域很是广，才能定位到问题。因此，分析问题和踩坑是很是锻炼一我的的成长和提高自我能力。若是咱们有一套好的分析工具，那将是事半功倍，可以帮助你们快速定位问题，节省你们不少时间作更深刻的事情。html
说明
本篇文章主要介绍各类问题定位的工具以及会结合案例分析问题。node
做者：Lucien_168
连接： https://www.jianshu.com/p/0bb...
二、 分析问题的方法论
套用5W2H方法，能够提出性能分析的几个问题python
- What-现象是什么样的
- When-何时发生
- Why-为何会发生
- Where-哪一个地方发生的问题
- How much-耗费了多少资源
- How to do-怎么解决问题
三、cpu
3.1 说明ios
针对应用程序，咱们一般关注的是内核CPU调度器功能和性能。nginx
线程的状态分析主要是分析线程的时间用在什么地方，而线程状态的分类通常分为：git
a. on-CPU：执行中，执行中的时间一般又分为用户态时间user和系统态时间sys。
b. off-CPU：等待下一轮上CPU，或者等待I/O、锁、换页等等，其状态能够细分为可执行、匿名换页、睡眠、锁、空闲等状态。github
若是大量时间花在CPU上，对CPU的剖析可以迅速解释缘由；若是系统时间大量处于off-cpu状态，定位问题就会费时不少。可是仍然须要清楚一些概念：json
- 处理器
- 核
- 硬件线程
- CPU内存缓存
- 时钟频率
- 每指令周期数CPI和每周期指令数IPC
- CPU指令
- 使用率
- 用户时间／内核时间
- 调度器
- 运行队列
- 抢占
- 多进程
- 多线程
- 字长
3.2 分析工具后端
说明:浏览器
- uptime,vmstat,mpstat,top,pidstat只能查询到cpu及负载的的使用状况。
- perf能够跟着到进程内部具体函数耗时状况，而且能够指定内核函数进行统计，指哪打哪。
3.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
四、内存
4.1 说明
内存是为提升效率而生，实际分析问题的时候，内存出现问题可能不仅是影响性能，而是影响服务或者引发其余问题。一样对于内存有些概念须要清楚：
- 主存
- 虚拟内存
- 常驻内存
- 地址空间
- OOM
- 页缓存
- 缺页
- 换页
- 交换空间
- 交换
- 用户分配器libc、glibc、libmalloc和mtmalloc
- LINUX内核级SLUB分配器
4.2 分析工具
说明：
- free,vmstat,top,pidstat,pmap只能统计内存信息以及进程的内存使用状况。
- valgrind能够分析内存泄漏问题。
- dtrace动态跟踪。须要对内核函数有很深刻的了解，经过D语言编写脚本完成跟踪。
4.3 使用方式
//查看系统内存使用状况 free -m //虚拟内存统计信息 vmstat 1 //查看系统内存状况 top //1s采集周期，获取内存的统计信息 pidstat -p pid -r 1 //查看进程的内存映像信息 pmap -d pid //检测程序内存问题 valgrind --tool=memcheck --leak-check=full --log-file=./log.txt ./程序名
五、 磁盘IO
5.1 说明
磁盘一般是计算机最慢的子系统，也是最容易出现性能瓶颈的地方，由于磁盘离 CPU 距离最远并且 CPU 访问磁盘要涉及到机械操做，好比转轴、寻轨等。访问硬盘和访问内存之间的速度差异是以数量级来计算的，就像1天和1分钟的差异同样。要监测 IO 性能，有必要了解一下基本原理和 Linux 是如何处理硬盘和内存之间的 IO 的。
在理解磁盘IO以前，一样咱们须要理解一些概念，例如：
- 文件系统
- VFS
- 文件系统缓存
- 页缓存page cache
- 缓冲区高速缓存buffer cache
- 目录缓存
- inode
- inode缓存
- noop调用策略
5.2 分析工具
5.3 使用方式
//查看系统io信息 iotop //统计io详细信息 iostat -d -x -k 1 10 //查看进程级io的信息 pidstat -d 1 -p pid //查看系统IO的请求，好比能够在发现系统IO异常时，可使用该命令进行调查，就能指定究竟是什么缘由致使的IO异常 perf record -e block:block_rq_issue -ag^Cperf report
六、网络
6.1 说明
网络的监测是全部 Linux 子系统里面最复杂的，有太多的因素在里面，好比：延迟、阻塞、冲突、丢包等，更糟的是与 Linux 主机相连的路由器、交换机、无线信号都会影响到总体网络而且很难判断是由于 Linux 网络子系统的问题仍是别的设备的问题，增长了监测和判断的复杂度。如今咱们使用的全部网卡都称为自适应网卡，意思是说能根据网络上的不一样网络设备致使的不一样网络速度和工做模式进行自动调整。
6.2 分析工具
6.3 使用方式
//显示网络统计信息
netstat -s
//显示当前UDP链接情况
netstat -nu
//显示UDP端口号的使用状况
netstat -apu
//统计机器中网络链接各个状态个数
netstat -a | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
//显示TCP链接
ss -t -a
//显示sockets摘要信息
ss -s
//显示全部udp socketsss -u -a//tcp,etcp状态
sar -n TCP,ETCP 1
//查看网络
IOsar -n DEV 1
//抓包以包为单位进行输出
tcpdump -i eth1 host 192.168.1.1 and port 80
//抓包以流为单位显示数据内容
tcpflow -cp host 192.168.1.1
七、系统负载
7.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。
7.2 分析工具
7.3 使用方式
//查看负载状况 uptimetopvmstat //统计系统调用耗时状况 strace -c -p pid //跟踪指定的系统操做例如 epoll_waitstrace -T -e epoll_wait -p pid //查看内核日志信息 dmesg
八、 火焰图
8.1 说明
火焰图（Flame Graph是 Bredan Gregg 建立的一种性能分析图表，由于它的样子近似 ?而得名。
火焰图主要是用来展现 CPU的调用栈。
y 轴表示调用栈，每一层都是一个函数。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。
x 轴表示抽样数，若是一个函数在 x 轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间长。注意，x 轴不表明时间，而是全部的调用栈合并后，按字母顺序排列的。
火焰图就是看顶层的哪一个函数占据的宽度最大。只要有”平顶”（plateaus），就表示该函数可能存在性能问题。颜色没有特殊含义，由于火焰图表示的是 CPU 的繁忙程度，因此通常选择暖色调。
常见的火焰图类型有On-CPU、Off-CPU、Memory、Hot/Cold、Differential等等。
8.2 安装依赖库
//安装systemtap，默认系统已安装 yum install systemtap systemtap-runtime //内核调试库必须跟内核版本对应，例如： uname -r 2.6.18-308.el5kernel-debuginfo-2.6.18-308.el5.x86_64.rpmkernel-devel-2.6.18-308.el5.x86_64.rpmkernel-debuginfo-common-2.6.18-308.el5.x86_64.rpm //安装内核调试库 debuginfo-install --enablerepo=debuginfo search kerneldebuginfo-install --enablerepo=debuginfo search glibc
8.3 安装
git clone https://github.com/lidaohang/quick_location.gitcd quick_location
8.4 CPU级别火焰图
cpu占用太高，或者使用率提不上来，你能快速定位到代码的哪块有问题吗？
通常的作法可能就是经过日志等方式去肯定问题。如今咱们有了火焰图，可以很是清晰的发现哪一个函数占用cpu太高，或者太低致使的问题。
8.4.1 on-CPU
cpu占用太高，执行中的时间一般又分为用户态时间user和系统态时间sys。
使用方式：
//on-CPU user sh ngx_on_cpu_u.sh pid //进入结果目录 cd ngx_on_cpu_u //on-CPU kernel sh ngx_on_cpu_k.sh pid //进入结果目录 cd ngx_on_cpu_k //开一个临时端口8088 python -m SimpleHTTPServer 8088 //打开浏览器输入地址 127.0.0.1:8088/pid.svg
DEMO：
#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();
}
}
DEMO火焰图：
8.4.2 off-CPU
cpu太低，利用率不高。等待下一轮CPU，或者等待I/O、锁、换页等等，其状态能够细分为可执行、匿名换页、睡眠、锁、空闲等状态。
使用方式：
// off-CPU user sh ngx_off_cpu_u.sh pid //进入结果目录 cd ngx_off_cpu_u //off-CPU kernel sh ngx_off_cpu_k.sh pid //进入结果目录 cd ngx_off_cpu_k //开一个临时端口8088 python -m SimpleHTTPServer 8088 //打开浏览器输入地址 127.0.0.1:8088/pid.svg
官网DEMO：
8.5 内存级别火焰图
若是线上程序出现了内存泄漏，而且只在特定的场景才会出现。这个时候咱们怎么办呢？有什么好的方式和工具能快速的发现代码的问题呢？一样内存级别火焰图帮你快速分析问题的根源。
使用方式：
sh ngx_on_memory.sh pid //进入结果目录 cd ngx_on_memory //开一个临时端口8088 python -m SimpleHTTPServer 8088 //打开浏览器输入地址 127.0.0.1:8088/pid.svg
官网DEMO：
8.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();
}
}
DEMO红蓝差分火焰图：
九、.案例分析
9.1 接入层nginx集群异常现象
经过监控插件发如今2017.09.25 19点nginx集群请求流量出现大量的499，5xx状态码。而且发现机器cpu使用率升高，目前一直持续中。
9.2 分析nginx相关指标
a) _**_分析nginx请求流量：
结论：
经过上图发现流量并无突增，反而降低了，跟请求流量突增不要紧。
b) _**_分析nginx响应时间 
结论：
经过上图发现nginx的响应时间有增长可能跟nginx自身有关系或者跟后端upstream响应时间有关系。
c) _**_分析nginx upstream响应时间
结论：
经过上图发现nginx upstream 响应时间有增长，目前猜想可能后端upstream响应时间拖住nginx，致使nginx出现请求流量异常。
9.3 分析系统cpu状况
a) _**_经过top观察系统指标
top
结论：
发现nginx worker cpu比较高
b) _**_分析nginx进程内部cpu状况
perf top -p pid
结论：
发现主要开销在free,malloc,json解析上面
9.4 火焰图分析cpu
a) _**_生成用户态cpu火焰图
//on-CPU user sh ngx_on_cpu_u.sh pid //进入结果目录 d ngx_on_cpu_u //开一个临时端口8088 python -m SimpleHTTPServer 8088 //打开浏览器输入地址 127.0.0.1:8088/pid.svg
结论：
发现代码里面有频繁的解析json操做，而且发现这个json库性能不高，占用cpu挺高。
9.5 案例总结
a) 分析请求流量异常，得出nginx upstream后端机器响应时间拉长
b) 分析nginx进程cpu高，得出nginx内部模块代码有耗时的json解析以及内存分配回收操做
9.5.1 深刻分析
根据以上两点问题分析的结论，咱们进一步深刻分析。
后端upstream响应拉长，最多可能影响nginx的处理能力。可是不可能会影响nginx内部模块占用过多的cpu操做。而且当时占用cpu高的模块，是在请求的时候才会走的逻辑。不太多是upstram后端拖住nginx，从而触发这个cpu的耗时操做。
9.5.2 解决方式
遇到这种问题，咱们优先解决已知的，而且很是明确的问题。那就是cpu高的问题。解决方式先降级关闭占用cpu太高的模块，而后进行观察。通过降级关闭该模块cpu降下来了，而且nginx请求流量也正常了。之因此会影响upstream时间拉长，由于upstream后端的服务调用的接口多是个环路再次走回到nginx。
十、参考资料
- 1. Linux 问题故障定位，看这一篇就够了
- 2. Linux问题故障定位
- 3. 搞定SEO，看这一篇就够了
- 4. 排查 Linux 系统故障，看这一篇足够了。
- 5. nginx看这篇就够了
- 6. 了解 MongoDB 看这一篇就够了
- 7. RunLoop看这篇就够了
- 8. mongoDB看这篇就够了
- 9. npm，看这篇就够了
- 10. Lombok 看这篇就够了
- 更多相关文章...
- • Markdown 标题 - Markdown 教程
- • jQuery Mobile 主题 - jQuery Mobile 教程
- • 再有人问你分布式事务，把这篇扔给他
- • PHP Ajax 跨域问题最佳解决方案
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Linux 问题故障定位，看这一篇就够了
- 2. Linux问题故障定位
- 3. 搞定SEO，看这一篇就够了
- 4. 排查 Linux 系统故障，看这一篇足够了。
- 5. nginx看这篇就够了
- 6. 了解 MongoDB 看这一篇就够了
- 7. RunLoop看这篇就够了
- 8. mongoDB看这篇就够了
- 9. npm，看这篇就够了
- 10. Lombok 看这篇就够了