Linux 运维故障排查思绪，有这篇文章就够了~
1. 配景
有时间会遇到一些疑难杂症，并且监控插件并不可一眼立马发明问题的泉源。这时间就需要登录效劳器进一步深入剖析问题的泉源。那么剖析问题需要有一定的手艺履历积累，并且有些问题涉及到的领域很是广，才华定位到问题。以是，剖析问题和踩坑是很是磨炼一小我私人的生长和提升自我能力。若是我们有一套好的剖析工具，那将是事半功倍，能够资助各人快速定位问题，节约各人许多时间做更深入的事情。
2. 说明
本篇文章主要先容种种问题定位的工具以及会团结案例剖析问题。
3. 剖析问题的要领论
套用5W2H要领，可以提出性能剖析的几个问题
What-征象是什么样的
When-什么时间爆发
Why-为什么会爆发
Where-哪个地方爆发的问题
How much-泯灭了几多资源
How to do-怎么解决问题
4. cpu
4.1 说明
针对应用程序，我们通常关注的是内核CPU调理器功效和性能。
线程的状态剖析主要是剖析线程的时间用在什么地方，而线程状态的分类一样平常分为：
on-CPU：执行中，执行中的时间通常又分为用户态时间user和系统态时间sys。
off-CPU：期待下一轮上CPU，或者期待I/O、锁、换页等等，其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。
若是大宗时间花在CPU上，对CPU的剖析能够迅速诠释缘故原由；若是系统时间大宗处于off-cpu状态，定位问题就会费时许多。可是仍然需要清晰一些看法：
处理器
核
硬件线程
CPU内存缓存
时钟频率
每指令周期数CPI和每周期指令数IPC
CPU指令
使用率
用户时间／内核时间
调理器
运行行列
抢占
多历程
多线程
字长
4.2 剖析工具
说明:
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. 内存
5.1 说明
内存是为提高效率而生，现实剖析问题的时间，内存泛起问题可能不但是影响性能，而是影响效劳或者引起其他问题。同样关于内存有些看法需要清晰：
牛逼�。〗铀交畋乇傅� N 个开源项目！赶忙珍藏
登录后复制
主存
虚拟内存
常驻内存
地点空间
OOM
页缓存
缺页
换页
交流空间
交流
用户分派器libc、glibc、libmalloc和mtmalloc
LINUX内核级SLUB分派器
5.2 剖析工具
说明：
free，vmstat，top，pidstat，pmap只能统计内存信息以及历程的内存使用情形。
valgrind 可以剖析内存走漏问题。
dtrace 动态跟踪。需要对内核函数有很深入的相识，通过D语言编写剧本完成跟踪。
5.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 ./程序名
登录后复制
6. 磁盘IO
6.1 说明
磁盘通常是盘算机最慢的子系统，也是最容易泛起性能瓶颈的地方，由于磁盘离 CPU 距离最远并且 CPU 会见磁盘要涉及到机械操作，好比转轴、寻轨等。会见硬盘和会见内存之间的速率差别是以数目级来盘算的，就像1天和1分钟的差别一样。要监测 IO 性能，有须要相识一下基来源理和 Linux 是如那里置硬盘和内存之间的 IO 的。
在明确磁盘IO之前，同样我们需要明确一些看法，例如：
文件系统
VFS
文件系统缓存
页缓存page cache
缓冲区高速缓存buffer cache
目录缓存
inode
inode缓存
noop挪用战略
6.2 剖析工具
6.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
登录后复制
7. 网络
7.1 说明
网络的监测是所有 Linux 子系统内里最重大的，有太多的因素在内里，好比：延迟、壅闭、冲突、丢包等，更糟的是与 Linux 主机相连的路由器、交流机、无线信号都会影响到整体网络并且很难判断是由于 Linux 网络子系统的问题照旧别的装备的问题，增添了监测和判断的重漂后。现在我们使用的所有网卡都称为自顺应网卡，意思是说能凭证网络上的差别网络装备导致的差别网络速率和事情模式举行自动调解。
7.2 剖析工具
7.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
登录后复制
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 剖析工具
8.3 使用方法
//审查负载情形uptimetopvmstat//统计系统挪用耗时情形strace -c -p pid//跟踪指定的系统操作例如epoll_waitstrace -T -e epoll_wait -p pid//审查内核日志信息dmesg
登录后复制
9. 火焰图
9.1 说明
火焰图（Flame Graph是 Bredan Gregg 建设的一种性能剖析图表，由于它的样子近似 ?而得名。
火焰图主要是用来展示 CPU的挪用栈。
y
轴体现挪用栈，每一层都是一个函数。挪用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。
x
轴体现抽样数，若是一个函数在 x 轴占有的宽度越宽，就体现它被抽到的次数多，即执行的时间长。注重，x 轴不代表时间，而是所有的挪用栈合并后，按字母顺序排列的。
火焰图就是看顶层的哪个函数占有的宽度最大。只要有”平顶”（plateaus），就体现该函数可能保存性能问题。颜色没有特殊寄义，由于火焰图体现的是 CPU 的忙碌水平，以是一样平常选择暖色调。
常见的火焰图类型有 On-CPU、Off-CPU、Memory、Hot/Cold、Differential等等。
9.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
登录后复制
9.3 装置
git clone https://github.com/lidaohang/quick_location.gitcd quick_location
登录后复制
9.4 CPU级别火焰图
cpu占用过高，或者使用率提不上来，你能快速定位到代码的哪块有问题吗 ？
一样平常的做法可能就是通过日志等方法去确定问题。现在我们有了火焰图，能够很是清晰的发明哪个函数占用cpu过高，或者过低导致的问题。另外，搜索民众号Linux就该这样学后台回复“猴子”，获取一份惊喜礼包。
9.4.1 on-CPU
cpu占用过高，执行中的时间通常又分为用户态时间user和系统态时间sys。
使用方法：
//on-CPU usersh ngx_on_cpu_u.sh pid//进入效果目录 cd ngx_on_cpu_u//on-CPU kernelsh 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火焰图：
9.4.2 off-CPU
cpu过低，使用率不高。期待下一轮CPU，或者期待I/O、锁、换页等等，其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。
使用方法：
// off-CPU usersh ngx_off_cpu_u.sh pid//进入效果目录cd ngx_off_cpu_u//off-CPU kernelsh ngx_off_cpu_k.sh pid//进入效果目录cd ngx_off_cpu_k//开一个暂时端口8088python -m SimpleHTTPServer 8088//翻开浏览器输入地点127.0.0.1:8088/pid.svg
登录后复制
官网DEMO：
9.5 内存级别火焰图
若是线上程序泛起了内存走漏，并且只在特定的场景才会泛起。这个时间我们怎么办呢 ？有什么好的方法和工具能快速的发明代码的问题呢 ？同样内存级别火焰图帮你快速剖析问题的泉源。
使用方法：
sh ngx_on_memory.sh pid//进入效果目录cd ngx_on_memory//开一个暂时端口8088python -m SimpleHTTPServer 8088//翻开浏览器输入地点127.0.0.1:8088/pid.svg
登录后复制
官网DEMO：
9.6 性能回退-红蓝差分火焰图
你能快速定位CPU性能回退的问题么 ？若是你的事情情形很是重大且转变快速，那么使用现有的工具是来定位这类问题是很具有挑战性的。当你花掉数周时间把根因找到时，代码已经又变换了好几轮，新的性能问题又冒了出来。主要可以用到每次构建中，每次上线做比照看，若是损失严重可以立马解决修复。
通过抓取了两张通俗的火焰图，然后举行比照，并对差别部分举行标色：红色体现上升，蓝色体现下降。差分火焰图是以目今（“修改后”）的profile文件作为基准，形状和巨细都坚持稳固。因此你通过色彩的差别就能够很直观的找到差别部分，且可以看出为什么会有这样的差别。
使用方法：
cd quick_location//抓取代码修改前的profile 1文件perf record -F 99 -p pid -g -- sleep 30perf script > out.stacks1//抓取代码修改后的profile 2文件perf record -F 99 -p pid -g -- sleep 30perf 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红蓝差分火焰图：
10. 案例剖析
10.1 接入层nginx集群异常征象
通过监控插件发明在 2017.09.25 19 点nginx集群请求流量泛起大宗的499，5xx状态码。并且发明机械cpu使用率升高，现在一直一连中。另外，搜索民众号顶级算法后台回复“算法”，获取一份惊喜礼包。
10.2 剖析nginx相关指标
a) **剖析nginx请求流量：
结论：
通过上图发明流量并没有突增，反而下降了，跟请求流量突增没关系。
b) **剖析nginx响应时间
结论：
通过上图发明nginx的响应时间有增添可能跟nginx自身有关系或者跟后端upstream响应时间有关系。
c) **剖析nginx upstream响应时间
结论：
通过上图发明nginx upstream 响应时间有增添，现在推测可能后端upstream响应时间拖住nginx，导致nginx泛起请求流量异常。
10.3 剖析系统cpu情形
a) **通过top视察系统指标
top
结论：
发明nginx worker cpu较量高
b) **剖析nginx历程内部cpu情形
perf top -p pid
结论：
发明主要开销在free,malloc,json剖析上面
10.4 火焰图剖析cpu
a) **天生用户态cpu火焰图
//on-CPU usersh ngx_on_cpu_u.sh pid//进入效果目录cd ngx_on_cpu_u//开一个暂时端口8088python -m SimpleHTTPServer 8088//翻开浏览器输入地点127.0.0.1:8088/pid.svg
登录后复制
结论：
发明代码内里有频仍的剖析json操作，并且发明这个json库性能不高，占用cpu挺高。
10.5 案例总结
a) 剖析请求流量异常，得出nginx upstream后端机械响应时间拉长
b) 剖析nginx历程cpu高，得出nginx内部� ？榇胗泻氖钡膉son剖析以及内存分派接纳操作
10.5.1 深入剖析
凭证以上两点问题剖析的结论，我们进一步深入剖析。
后端upstream响应拉长，最多可能影响nginx的处理能力。可是不可能会影响nginx内部� ？檎加霉嗟腸pu操作。并且其时占用cpu高的� ？�，是在请求的时间才会走的逻辑。不太可能是upstram后端拖住nginx，从而触发这个cpu的耗时操作。
10.5.2 解决方法
遇到这种问题，我们优先解决已知的，并且很是明确的问题。那就是cpu高的问题。解决方法先降级关闭占用cpu过高的� ？�，然后举行视察。经由降级关闭该� ？閏pu降下来了，并且nginx请求流量也正常了。之以是会影响upstream时间拉长，由于upstream后端的效劳挪用的接口可能是个环路再次走回到nginx。
11.参考资料
http://www.brendangregg.com/index.html
http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
http://www.brendangregg.com/FlameGraphs/memoryflamegraphs.html
http://www.brendangregg.com/FlameGraphs/offcpuflamegraphs.html
http://www.brendangregg.com/blog/2014-11-09/differential-flame-graphs.html
https://github.com/openresty/openresty-systemtap-toolkit
https://github.com/brendangregg/FlameGraph
https://www.slideshare.net/brendangregg/blazing-performance-with-flame-graphs
以上就是Linux 运维故障排查思绪，有这篇文章就够了~的详细内容，更多请关注本网内其它相关文章！
