当前位置: 首页 > 科技观察

Linux运维排查思路,这篇文章就够了

时间:2023-03-13 20:56:18 科技观察

1。后台有时会遇到一些疑难杂症,监控插件无法第一时间找到问题根源。这时候就需要登录服务器进一步分析问题的根源。那么分析问题需要一定的技术经验积累,有些问题涉及的领域非常广泛,才能定位问题。所以,分析问题,踩坑,是一个人成长和自我提升的一大锻炼。如果我们有一套好的分析工具,就会事半功倍。它可以帮助你快速定位问题,为你节省大量时间去做更深入的事情。2.描述本文主要介绍各种问题定位工具,并结合案例分析问题。3.问题分析方法应用5W2H方法,可以提出性能分析的几个问题。什么——什么现象?何时-何时发生?为什么——为什么会发生?todo-howtosolveproblem4.cpu4.1Description对于应用程序,我们通常关注内核CPU调度器的功能和性能。线程状态分析主要是分析线程时间花在了哪里,线程状态的分类一般分为:on-CPU:在执行中,执行时间通常分为用户态时间user和系统态时间sys。off-CPU:等待下一轮CPU,或等待I/O、锁、分页等,其状态可细分为可执行、匿名分页、睡眠、锁、空闲等状态。如果在CPU上花费了大量时间,对CPU进行性能分析可以快速说明原因;如果系统长时间处于off-cpu状态,定位问题会花费很多时间。不过有些概念还是需要搞清楚:处理器核心硬件线程CPU内存缓存时钟频率CPI和每周期指令数IPCCPU指令使用率用户时间/内核时间调度器运行队列抢占多进程多线程字长4.2分析工具说明:uptime、vmstat、mpstat、top、pidstat只能查询cpu和load的使用情况。perf可以跟踪进程内部具体函数的耗时情况,可以指定内核函数进行统计,指的是命中到哪里。4.3如何使用//查看系统cpu使用率top//查看所有cpu核心信息mpstat-PALL1//查看cpu使用率和平均负载vmstat1//进程cpu统计信息pidstat-u1-ppid//跟踪进程内部函数级别cpu使用率perftop-ppid-ecpu-clock5。内存5.1说明创建内存是为了提高效率。在实际分析问题的时候,内存的问题不仅会影响性能,还会影响业务或者引发其他问题。还有内存的一些概念需要明确:主存虚拟内存驻留内存地址空间OOMpagecachepagefaultpagechangeswapspaceswapuserallocatorlibc,glibc,libmallocandmtmallocLINUXkernellevelSLUBallocator5.2分析工具说明:free,vmstat、top、pidstat、pmap只能统计内存信息和进程内存使用情况。valgrind可以分析内存泄漏。dtrace动态跟踪。需要对核函数有深入的理解,通过用D语言编写脚本完成trace。5.3如何使用//查看系统内存使用情况free-m//虚拟内存统计vmstat1//查看系统内存top//1s收集周期,获取内存统计信息pidstat-ppid-r1//查看进程内存映像信息pmap-dpid//Detectprogrammemoryproblemsvalgrind--tool=memcheck--leak-check=full--log-file=./log.txt./Programname6.DiskIO6.1表示磁盘通常是最慢的子系统也是最容易出现性能瓶颈的地方,因为磁盘离CPU最远,CPU对磁盘的访问涉及机械操作,比如转轴、跟踪等。访问硬盘和访问内存的速度差异是按数量级计算的,就像1天和1分钟的差异一样。监控IO性能,需要了解基本原理,了解Linux是如何处理硬盘和内存之间IO的。在了解磁盘IO之前,我们还需要先了解一些概念,比如:文件系统VFS文件系统缓存页缓存页缓存缓冲区缓存缓冲区缓存目录缓存inodeinode缓存noop调用策略6.2分析工具6.3用法//查看系统io信息iotop//统计io详细信息iostat-d-x-k110//查看进程级别的io信息pidstat-d1-ppid//查看系统IO请求,比如当发现系统IO异常时可以使用该命令进行排查,可以指定导致IO异常的原因perfrecord-eblock:block_rq_issue-ag^Cperfreport7。Network7.1可见网络监控是所有Linux子系统中最复杂的,里面的因素太多了,比如:延迟,阻塞,冲突,丢包等等,更糟糕的是路由器,交换机,无线信号连接Linux主机会影响整体网络,很难判断是Linux网络子系统问题还是其他设备问题。判断复杂度。我们现在使用的所有网卡都称为自适应网卡,意思是可以根据网络上不同网络设备造成的不同网速和工作模式进行自动调整。7.2分析工具7.3如何使用//显示网络统计netstat-s//显示当前UDP连接状态netstat-nu//显示UDP端口号使用情况netstat-apu//统计本机各状态下的网络连接数netstat-a|awk'/^tcp/{++S[$NF]}END{for(ainS)printa,S[a]}'//显示TCP连接ss-t-a//显示套接字摘要信息ss-s//显示所有udpsocketsss-u-a//tcp,etcpstatussar-nTCP,ETCP1//查看网络IOsar-nDEV1//抓包到包中输出tcpdump-ieth1host192.168.1.1andport80//抓包到流中显示数据单位内容tcpflow-cphost192.168.1.18。SystemLoad8.1说明Loadisameasureofthecomputerisdoing(维基百科:thesystemLoadisameasureofworkofworkthatancomputesystemisdoing)简单地说,它是一个进程队列长度。LoadAverage是一段时间内(1分钟、5分钟、15分钟)的平均Load。8.2分析工具8.3使用方法//查看负载状态uptimetopvmstat//统计系统调用耗时strace-c-ppid//跟踪epoll_wait等指定系统操作strace-T-eepoll_wait-ppid//查看内核日志信息dmesg9.Flamegraph9.1火焰图解释(FlameGraph是BredanGregg创建的性能分析图,因长得像?而得名。火焰图主要用于显示CPU的调用堆栈。y轴代表调用栈,每一层都是一个函数,调用栈越深,火焰越高。上面是正在执行的函数,下面是它的父函数。x轴代表样本数。如果一个函数在x轴上占据更宽的宽度,意味着它的draw次数多,也就是执行时间长,注意x轴不代表时间,而是所有的调用栈合并排列按字母顺序排列,火焰图就是看最顶层哪个函数占用的宽度最大,只要有“平台”,就说明这个函数可能有性能问题。颜色没有特殊意义,因为火焰图表示CPU的繁忙程度,所以一般选择暖色。常见的火焰图类型包括On-CPU、Off-CPU、Memory、Hot/Cold、Differential等。9.2安装依赖库//安装systemtap,默认系统已经安装yuminstallsystemtapsystemtap-runtime//内核调试库必须对应内核版本,例如:uname-r2.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=debuginfosearchkerneldebuginfo-install--enablerepo=debuginfosearchglibc9.3安装gitclonehttps://github.com/lidaohang/quick_location.gitcdquick_location9.4CPU级火焰图cpu使用率过高,或者利用率无法提升,能否快速定位到是哪部分代码有问题?一般的做法可能是通过日志等方式来判断问题。现在有了火焰图,我们就可以清楚地找出是哪个函数占用cpu太多了,还是太低导致的问题。9.4.1on-CPUCPU占用率过高,执行时间通常分为用户态timeuser和系统态timesys。Usage://on-CPUusershngx_on_cpu_u.shpid//进入结果目录cdngx_on_cpu_u//on-CPUkernelshngx_on_cpu_k.shpid//进入结果目录cdngx_on_cpu_k//打开一个临时端口8088python-mSimpleHTTPServer8088//打开浏览器,输入地址127.0.0.1:8088/pid.svgDEMO:#include#includevoidfoo3(){}voidfoo2(){inti;for(i=0;i<10;i++)foo3();}voidfoo1(){inti;for(i=0;i<1000;i++)foo3();}intmain(void){inti;for(i=0;i<1000000000;i++){foo1();foo2();}}DEMO火焰图:9.4.2off-CPUcpu太低,利用率不高。等待下一轮CPU,或者等待I/O、锁、换页等,其状态又可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。Usage://off-CPUusershngx_off_cpu_u.shpid//进入结果目录cdngx_off_cpu_u//off-CPUkernelshngx_off_cpu_k.shpid//进入结果目录cdngx_off_cpu_k//打开一个临时端口8088python-mSimpleHTTPServer8088//打开浏览器,输入地址127.0。0.1:8088/pid.svg官网DEMO:9.5内存级火焰图如果线上程序出现内存泄漏,只会出现在特定场景。这个时候怎么办?有没有什么好的方法和工具可以快速找到代码问题?另外,内存级别的火焰图可以帮助您快速分析问题的根源。使用方法:shngx_on_memory.shpid//进入结果目录cdngx_on_memory//打开一个临时端口8088python-mSimpleHTTPServer8088//打开浏览器输入地址127.0.0.1:8088/pi??d.svg官网DEMO:9.6性能回退-红色而蓝色的微分火焰图能快速定位到CPU性能回归的问题吗?如果您的工作环境非常复杂且瞬息万变,那么使用现有工具定位此类问题可能具有挑战性。当您花了数周时间找出根本原因时,代码又经历了几轮,新的性能问题已经浮出水面。主要可以在每次构建时使用,每次上线时对比。如果损失严重,可以立即修复。通过抓取两个普通的火焰图,比较它们,并对差异进行颜色编码:红色表示上升,蓝色表示下降。微分火焰图基于当前(“修改后”)的profile文件,形状和大小保持不变。所以,通过颜色的差异,可以直观的发现差异,就可以看出为什么会有这样的差异。Usage:cdquick_location//抓取代码修改前的profile1文件perfrecord-F99-ppid-g--sleep30perfscript>out.stacks1//抓取代码修改后的profile2文件perfrecord-F99-ppid-g--sleep30perfscript>out.stacks2//生成微分火焰图:./FlameGraph/stackcollapse-perf.pl../out.stacks1>out.folded1./FlameGraph/stackcollapse-perf.pl../out.stacks2>out.folded2./FlameGraph/difffolded.plout.folded1out.folded2|./FlameGraph/flamegraph.pl>diff2.svgDEMO://test.c#include#includevoidfoo3(){}voidfoo2(){inti;for(i=0;i<10;i++)foo3();}voidfoo1(){inti;for(i=0;i<1000;i++)foo3();}intmain(void){inti;for(i=0;i<1000000000;i++){foo1();foo2();}}//test1.c#include#includevoidfoo3(){}voidfoo2(){inti;for(i=0;i<10;i++)foo3();}voidfoo1(){inti;for(i=0;i<1000;i++)foo3();}voidadd(){inti;for(i=0;i<10000;i++)foo3();}intmain(void){inti;for(i=0;i<1000000000;i++){foo1();foo2();add();}}DEMO红蓝微分火焰图:10.案例分析10.1Th2017.09.2519点通过监控插件发现接入层nginx集群异常现象ginx集群请求流量出现大量499和5xx状态码,发现机器cpu使用率越来越高,一直持续。10.2nginx相关指标分析a)**nginx请求流量分析:结论:通过上图发现流量没有突然增加,而是减少了,与请求的突然增加无关交通。b)**nginx响应时间分析结论:从上图发现,nginx响应时间的增加可能与nginx本身有关,也可能与后端上游响应时间有关。c)**nginx上游响应时间分析结论:从上图发现nginx上游响应时间增加了。目前推测可能是后端upstream响应时间延迟了nginx,导致nginx请求流量异常。10.3分析系统cpu情况a)**通过top观察系统指标top结论:发现nginxworkercpu比较高b)**分析nginx进程perftop-ppid内部cpu情况结论:发现mainoverheadisfree,malloc,jsonanalysisabove10.4Flamegraphanalysiscpua)**生成用户态cpu火焰图//on-CPUusershngx_on_cpu_u.shpid//进入结果目录cdngx_on_cpu_u//打开一个临时端口8088python-mSimpleHTTPServer8088//打开浏览器输入地址127.0.0.1:8088/pi??d。svg结论:发现代码中有频繁的json解析操作,发现这个json库性能不高,CPU占用率还挺高的。10.5案例总结a)分析异常请求流量,发现nginx上游后端机器响应时间延长b)分析nginx进程高cpu,得出nginx内部模块代码有问题JSON解析耗时和内存分配回收操作10.5.1深入分析根据以上两点的分析结论,我们进一步深入分析。后端上游响应时间变长,最多影响nginx的处理能力。但是不可能影响nginx内部模块过多的cpu运行。而当时占用cpu高的模块,都是请求时才走的逻辑。不太可能是upstram后端拖了nginx,触发了这个cpu的耗时操作。10.5.2解决方案遇到此类问题,我们优先解决已知且非常明确的问题。那就是cpu高的问题。解决方法是降级关闭占用CPU过多的模块,然后观察。降级关闭模块后,cpu下降了,nginx请求流量也正常。之所以会影响上游时间,是因为上游后端服务调用的接口可能是一个循环,又回到了nginx。11.参考资料http://www.brendangregg.com/index.htmlhttp://www.brendangregg.com/FlameGraphs/cpuflamegraphs.htmlhttp://www.brendangregg.com/FlameGraphs/memoryflamegraphs.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-工具包https://github.com/brendangregg/FlameGraphhttps://www.slideshare.net/brendangregg/blazing-performance-with-flame-graphs【编者推荐】1行代码实现Python数据分析:图为美观清晰,内置对比功能丨开源印度电商新规遏制亚马逊、谷歌等本土霸权,72小时内提交用户数据数据不会说谎锐捷云桌面与传统PC实战证明实力Linux内核编码标准将新增“包容性术语”指南取代H.265/HEVC!H.266编解码标准发布:视频清晰度不变,数据量减半