电子元器件外贸网站建设,汽车之家官网网页版入口,影视网站建设策划文案,建设银行北京市分行网站转自#xff1a;Lucien_168https://www.jianshu.com/p/0bbac570fa4c1、背景有时候会遇到一些疑难杂症#xff0c;并且监控插件并不能一眼立马发现问题的根源。这时候就需要登录服务器进一步深入分析问题的根源。那么分析问题需要有一定的技术经验积累#xff0c;并且有些问题…转自Lucien_168https://www.jianshu.com/p/0bbac570fa4c1、背景有时候会遇到一些疑难杂症并且监控插件并不能一眼立马发现问题的根源。这时候就需要登录服务器进一步深入分析问题的根源。那么分析问题需要有一定的技术经验积累并且有些问题涉及到的领域非常广才能定位到问题。所以分析问题和踩坑是非常锻炼一个人的成长和提升自我能力。如果我们有一套好的分析工具那将是事半功倍能够帮助大家快速定位问题节省大家很多时间做更深入的事情。2、说明本篇文章主要介绍各种问题定位的工具以及会结合案例分析问题。3、分析问题的方法论套用5W2H方法可以提出性能分析的几个问题What-现象是什么样的When-什么时候发生Why-为什么会发生Where-哪个地方发生的问题How much-耗费了多少资源How to do-怎么解决问题4、cpu4.1 说明针对应用程序我们通常关注的是内核CPU调度器功能和性能。线程的状态分析主要是分析线程的时间用在什么地方而线程状态的分类一般分为a. on-CPU执行中执行中的时间通常又分为用户态时间user和系统态时间sys。 b. off-CPU等待下一轮上CPU或者等待I/O、锁、换页等等其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。如果大量时间花在CPU上对CPU的剖析能够迅速解释原因如果系统时间大量处于off-cpu状态定位问题就会费时很多。但是仍然需要清楚一些概念处理器核硬件线程CPU内存缓存时钟频率每指令周期数CPI和每周期指令数IPCCPU指令使用率用户时间内核时间调度器运行队列抢占多进程多线程字长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-clock5、内存5.1 说明内存是为提高效率而生实际分析问题的时候内存出现问题可能不只是影响性能而是影响服务或者引起其他问题。同样对于内存有些概念需要清楚主存虚拟内存常驻内存地址空间OOM页缓存缺页换页交换空间交换用户分配器libc、glibc、libmalloc和mtmallocLINUX内核级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 --toolmemcheck --leak-checkfull --log-file./log.txt ./程序名6、磁盘IO6.1 说明磁盘通常是计算机最慢的子系统也是最容易出现性能瓶颈的地方因为磁盘离 CPU 距离最远而且 CPU 访问磁盘要涉及到机械操作比如转轴、寻轨等。访问硬盘和访问内存之间的速度差别是以数量级来计算的就像1天和1分钟的差别一样。要监测 IO 性能有必要了解一下基本原理和 Linux 是如何处理硬盘和内存之间的 IO 的。在理解磁盘IO之前同样我们需要理解一些概念例如文件系统VFS文件系统缓存页缓存page cache缓冲区高速缓存buffer cache目录缓存inodeinode缓存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 report7、网络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.18、系统负载8.1 说明Load 就是对计算机干活多少的度量(WikiPediathe 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//查看内核日志信息dmesg9、火焰图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 --enablerepodebuginfo search kerneldebuginfo-install --enablerepodebuginfo search glibc9.3 安装git clone https://github.com/lidaohang/quick_location.gitcd quick_location9.4 CPU级别火焰图cpu占用过高或者使用率提不上来你能快速定位到代码的哪块有问题吗一般的做法可能就是通过日志等方式去确定问题。现在我们有了火焰图能够非常清晰的发现哪个函数占用cpu过高或者过低导致的问题。9.4.1 on-CPUcpu占用过高执行中的时间通常又分为用户态时间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//开一个临时端口8088python -m SimpleHTTPServer 8088//打开浏览器输入地址127.0.0.1:8088/pid.svgDEMO#include #include void foo3(){}void foo2(){ int i; for(i0 ; 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-CPUcpu过低利用率不高。等待下一轮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官网DEMO9.5 内存级别火焰图如果线上程序出现了内存泄漏并且只在特定的场景才会出现。这个时候我们怎么办呢有什么好的方式和工具能快速的发现代码的问题呢同样内存级别火焰图帮你快速分析问题的根源。使用方式sh ngx_on_memory.sh pid//进入结果目录cd ngx_on_memory//开一个临时端口8088python -m SimpleHTTPServer 8088//打开浏览器输入地址127.0.0.1:8088/pid.svg官网DEMO9.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.svgDEMO//test.c#include #include void foo3(){}void foo2(){ int i; for(i0 ; 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 #include void foo3(){}void foo2(){ int i; for(i0 ; 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集群请求流量出现大量的4995xx状态码。并且发现机器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火焰图//test.c#include #include //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内部模块代码有耗时的json解析以及内存分配回收操作10.5.1 深入分析根据以上两点问题分析的结论我们进一步深入分析。后端upstream响应拉长最多可能影响nginx的处理能力。但是不可能会影响nginx内部模块占用过多的cpu操作。并且当时占用cpu高的模块是在请求的时候才会走的逻辑。不太可能是upstram后端拖住nginx从而触发这个cpu的耗时操作。10.5.2 解决方式遇到这种问题我们优先解决已知的并且非常明确的问题。那就是cpu高的问题。解决方式先降级关闭占用cpu过高的模块然后进行观察。经过降级关闭该模块cpu降下来了并且nginx请求流量也正常了。之所以会影响upstream时间拉长因为upstream后端的服务调用的接口可能是个环路再次走回到nginx。11、参考资料http://www.brendangregg.com/index.htmlhttp://www.brendangregg.com/FlameGraphs/cpuflamegraphs.htmlhttp://www.brendangregg.com/FlameGraphs/memoryflamegraphs.htmlhttp://www.brendangregg.com/FlameGraphs/offcpuflamegraphs.htmlhttp://www.brendangregg.com/blog/2014-11-09/differential-flame-graphs.htmlhttps://github.com/openresty/openresty-systemtap-toolkithttps://github.com/brendangregg/FlameGraphhttps://www.slideshare.net/brendangregg/blazing-performance-with-flame-graphsEND
