服务器 cpu(服务器CPU突然飙高)

后台工程师与运维工程师常常会遇到这样一个问题,机器的CPU突然就增多了。CPU增高可能会让程序的响应变慢,甚至把整个程序挂住,从而引起流量雪崩,严重影响用户体验。好好的代码,怎么突然CPU就增加了呢?最近虚拟币这么火,不会是有同事利用公司的服务器偷偷进行挖矿吧!假如这个时候,你的Leader突然让你定位这个问题,你要怎么办?难顶!写了几年的ifelse,都不知道如何排查CPU问题。今天我们来讲一个Linux的性能监控神器:Perf。Perf我们先讲一讲这个原理,假如让你来排查一个程序里面,哪些方法更加消耗CPU,你会怎么做。我们很难侵入程序,对每一次调用进行统计,那么我们能否换一个思路,我们每隔一段时间,去看看CPU在干啥。假如我们一秒钟去CPU那里观察100次,发现有70次都是在执行A方法,那么,我们可以近似地认为,CPU有70%的时间,都在执行A方法,那么A方法可能就是最消耗CPU的操作。Perf Top我们可以执行perf top命令,查看当前CPU的运行情况。如下图所示,我们可以看到,a.out这个任务占据了CPU的绝大部资源,其中,我们观察到,func_c占用了39.97%的CPU资源,func_b也是。假如我们希望优化,那么如果能够在这两个大头上有所建树,那么应该能够取得事半功倍的效果。这里需要注意的一点是,虽然我们在使用perf top命令时,能够使用-p参数指定对应的进程ID,但是在现网上,并不推荐这么做。非常有可能挂住原有进程,对线上用户造成影响。火焰图可能你会觉得Perf的看到的结果并不能直观地反馈系统的开销,也不够厉害,那么有没有更厉害的方法呢?能够让你看起来更加厉害。我们可以在Github上面下载FlameGraph,可以对perf的数据进行采集,画出来的图片就像熊熊燃烧的火焰,我们称之为火焰图。那么问题来了,这么高端的火焰图怎么看呢?上面是一个简化的火焰图,假如总共有A到E五个不同的方法,那么我们应该优先看哪一个?有一个最简单的原则,就是减去上层之后,剩余部分,就是当前的方法的开销。例如Func_A虽然很长,但是减去Func_B与Func_C之后,剩余并无多少。在上图,最值得我们关注的,是Func_B与Func_D,对这个两个方法进行重点分析,能够让我们事半功倍。总结以往我工作遇到一些同事,遇到CPU暴涨,第一时间就是看代码,虽然有时候一些死循环、死锁可以发现,但是这种效率仍然非常低下。Perf是一个简单而又有效的工具,能够让我们快速定位问题。有了这个工具,我们带着目的再去看代码,可以更加高效解决问题。

本文出自快速备案,转载时请注明出处及相应链接。

本文永久链接: https://www.175ku.com/27103.html