隐藏

c# 获取所有的进程的cpu使用率_如何找出让CPU使用率达到100%的应用

发布:2022/12/2 9:39:45作者:管理员 来源:本站 浏览次数:808

CPU使用率是单位时间内CPU使用情况的统计,以百分比的方式展示。那么作为最常用也是最熟悉的CPU指标,你能说出CPU使用率到底是怎么算出来的吗?再有,诸如top、ps之类的性能工具展示的%user、%nice、%system、%iowait、%steal等等,你又能弄清楚它们之间的不同吗?


今天我就带你了解CP∪使用率的内容,同时,我也会以我们最常用的反向代理服务器 Nginx为例,带你在一步步操作和分析中深入理解。


CPU使用率


在上一期我曾提到, Linux作为一个多任务操作系统,将每个CPU的时间划分为很短的时间片再通过调度器轮流分配给各个任务使用,因此造成多任务同时运行的错觉。


为了维护CPU时间, Linux通过事先定义的节拍率(内核中表示为Hz),触发时间中断,并使用全局变量 Jiffies记录了开机以来的节拍数。每发生一次时间中断, Jiffies的值就加1。


节拍率HZ是内核的可配选项,可以设置为100、250、1000等。不同的系统可能设置不同数值,你可以通过查询/ boot/config内核选项来查看它的配置值。比如在我的系统中,节拍率设置成了250,也就是每秒钟触发250次时间中断。

184f3e6a4323ef9a3733bdd5891b6b39.png


同时,正因为节拍率HZ是内核选项,所以用户空间程序并不能直接访问。为了方便用户空间程序,内核还提供了一个用户空间节拍率 USER HZ,它总是固定为100,也就是1/100秒。这样,用户空间程序并不需要关心内核中HZ被设置成了多少,因为它看到的总是固定值USER_HZ。


linux通过/proc虚拟文件系统,向用户空间提供了系统内部状态的信息,而/proc/stat提供的就是系统的CPU和任务统计信息。比方说,如果你只关注CPU的话,可以执行下面的命令:

26b2472078e65839cb451eb3ee94a2e2.png


这里的输出结果是一个表格。其中,第一列表示的是CPU编号,如cpu0、Cpu1,而第一行没有编号的Cpu,表示的是所有CPU的累加。其他列则表示不同场景下CPU的累加节拍数,它的单位是USER_HZ,也就是10ms(1/100秒),所以这其实就是不同场景下的CPU时间。


当然,这里每一列的顺序并不需要你背下来。你只要记住,有需要的时候,查询man proc就可以。不过,你要清楚 man proc文档里每一列的涵义,它们都是CPU使用率相关的重要指标你还会在很多其他的性能工具中看到它们。下面,我来依次解读一下。


1)、user(通常缩写为us),代表用户态CPU时间。注意,它不包括下面的nice时间,但包括了guest时间。


2)、nice(通常缩写为mi),代表低优先级用户态CPU时间,也就是进程的nice值被调整为1-19之间时的CPU时间。这里注意,nice可取值范围是-20到19,数值越大,优先级反而越。


3)、system(通常缩写为sys),代表内核态CPU时间。


4)、idle(通常缩写为id),代表空闲时间。注意,它不包括等待I/O的时间( iowait)。


5)、iowait(通常缩写为wa),代表等待I/O的CPU时间。


6)、irq(通常缩写为hi),代表处理硬中断的CPU时间。


7)、softirq(通常缩写为si),代表处理软中断的CPU时间。


8)、steal(通常缩写为st),代表当系统运行在虚拟机中的时候,被其他虚拟机占用的CPU时间。


9)、guest(通常缩写为guest),代表通过虚拟化运行其他操作系统的时间,也就是运行虚拟机的CPU时间。


10)、guest_nice(通常缩写为gnice),代表以低优先级运行虚拟机的时间。


而我们通常所说的CPU使用率,就是除了空闲时间外的其他时间占总CPU时间的百分比,用公式来表示就是:

d985c643653646001c1b4775373b4ccc.png


根据这个公式,我们就可以从/proc/stat中的数据,很容易地计算出CPU使用率。当然,也可以用每一个场景的CPU时间,除以总的CPU时间,计算出每个场景的CPU使用率。


不过先不要着急计算,你能说出,直接用/proc/stat的数据,算的是什么时间段的CPU使用率吗?


看到这里,你应该想起来了,这是开机以来的节拍数累加值,所以直接算出来的,是开机以来的平均CPU使用率,一般没啥参考价值。


事实上,为了计算CPU使用率,性能工具一般都会取间隔一段时间(比如3秒)的两次值,作差后,再计算出这段时间内的平均CPU使用率,即:

aeea44ca0f9a72bd366ea663e822b8c7.png


这个公式,就是我们用各种性能工具所看到的CPU使用率的实际计算方法。


现在,我们知道了系统CPU使用率的计算方法,那进程的呢?跟系统的指标类似,Linu也给每个进程提供了运行情况的统计信息,也就是/proc/[pid]/stat。不过,这个文件包含的数据就比较丰富了,总共有52列的数据。


当然,不用担心,因为你并不需要掌握每一列的含义。还是那句话,需要的时候,查 man proc就行。


回过头来看,是不是说要查看CPU使用率,就必须先读取/proc/stat和/proc/[pid]/stat这两个文件,然后再按照上面的公式计算出来呢?


当然不是,各种各样的性能分析工具已经帮我们计算好了。不过要注意的是,性能分析工具给出的都是间隔一段时间的平均CPU使用率,所以要注意间隔时向间的设置,特别是用多个工具对比分析时,你一定要保证它们用的是相同的间隔时间。


比如,对比一下top和ps这两个工具报告的CPU使用率,默认的结果很可能不一样,因为top默认使用3秒时间间隔,而pS使用的却是进程的整个生命周期。


怎么查看CPU使用率


知道了CPU使用率的含义后,我们再来看看要怎么查看CPU使用率。说到查看CPU使用率的工具,我猜你第一反应肯定是top和ps。的确,top和ps是最常用的性能分析工具:


1)、top显示了系统总体的CPU和内存使用情况,以及各个进程的资源使用情况。


2)、ps则只显示了每个进程的资源使用情况。


比如,top的输出格式为:

280adbefeb428e42bd8e80d918acdf7e.png


这个输出结果中,第三行%Cpu就是系统的CPU使用率,具体每一列的含义上一节都讲过,只是把CPU时间变换成了CPU使用率,我就不再重复讲了。不过需要注意,top默认显示的是所有CPU的平均值,这个时候你只需要按下数字1,就可以切换到每个CPU的使用率了。


继续往下看,空白行之后是进程的实时信息,每个进程都有一个%CPU列,表示进程的CPU使用率。它是用户态和内核态CPU使用率的总和,包括进程用户空间使用的CPU、通过系统调用执行的内核空间CPU、以及在就绪队列等待运行的CPU。在虚拟化环境中,它还包括了运行虚拟机占用的CPU。


所以,到这里我们可以发现,top并没有细分进程的用户态CPU和内核态CPU。那要怎么查看每个进程的详细情况呢?你应该还记得上一节用到的 pidstat吧,它正是一个专门分析每个进程CPU使用情况的工。


比如,下面的 pidstat命令,就间隔1秒展示了进程的5组CPU使用率,包括


1)、用户态CPU使用率(%usr)


2)、内核态CPU使用率(% system)


3)、运行虚拟机CPU使用率(% guest)


4)、等待CPU使用率(%Wait)


5)、以及总的CPU使用率(%CPU)


最后的 Average部分,还计算了5组数据的平均值。

73a3b218e2bd0595ff9240fb7a574ed6.png


CPU使用率过高怎么办?


通过top、ps、 pidstat等工具,你能够轻松找到CPU使用率较高(比如100%)的进程。接下来,你可能又想知道,占用CPU的到底是代码里的哪个函数呢?找到它,你才能更高效、更针对性地进行优化。


我猜你第一个想到的,应该是GDB( The GNU Project Debugger),这个功能强大的程序调试利器。的确,GDB在调试程序错误方面很强大。但是,我又要来"挑刺"了。请你记住GDB并不适合在性能分析的早期应用。


为什么呢?因为GDB调试程序的过程会中断程序运行,这在线上环境往往是不允许的。所以GDB只适合用在性能分析的后期,当你找到了出问题的大致函数后,线下再借助它来进一步调试函数内部的问题。


那么哪种工具适合在第一时间分析进程的CPU问题呢?我的推荐是perf。perf是 Linux2.6.31以后内置的性能分析工具。它以性能事件采样为基础,不仅可以分析系统的各种事件和内核性能,还可以用来分析指定应用程序的性能问题。


使用pef分析CPU性能问题,我来说两种最常见、也是我最喜欢的用法。


第一种常见用法是 perf top,类似于top,它能够实时显示占用CPU时钟最多的函数或者指令,因此可以用来查找热点函数,使用界面如下所示:

5feebdbd6d522d72233df9f9cabdf97f.png


输出结果中,第一行包含三个数据,分别是采样数( Samples)、事件类型( event)和事件数量( Event count)。比如这个例子中,pef总共采集了833个CPU时钟事件,而总事件数则为97742399。


另外,采样数需要我们特别注意。如果采样数过少(比如只有十几个),那下面的排序和百分比就没什么实际参考价值了。


再往下看是一个表格式样的数据,每一行包含四列,分别是:


第一列 Overhead,是该符号的性能事件在所有采样中的比例,用百分比来表示。


第二列 Shared,是该函数或指令所在的动态共享对象( Dynamic Shared Object),如内核、进程名、动态链接库名、内核模块名等。


第三列 Object,是动态共享对象的类型。比如[表示用户空间的可执行程序、或者动态链接库,而[K]则表示内核空间。


最后一列 Symbol是符号名,也就是函数名。当函数名未知时,用十六进制的地址来表示。


还是以上面的输出为例,我们可以看到,占用CPU时钟最多的是per工具自身,不过它的比例也只有7.28%,说明系统并没有CPU性能问题。 perf top的使用你应该很清楚了吧。


接着再来看第二种常见用法,也就是 perf record和 perf report。 perf top虽然实时展示了系统的性能信息,但它的缺点是并不保存数据,也就无法用于离线或者后续的分析。而perf record则提供了保存数据的功能,保存后的数据,需要你用 perf report解析展示。

73c1f30b138b112a5af1dfcb57c3cb8a.png


在实际使用中,我们还经常为perf top和perf record加上-g参数,开启调用关系的采样,以便我们根据调用链来分析性能问题。