某个应用的CPU使用率达到100%，该怎么办？
通常用来描述系统的CPU性能指标：平均负载、CPU上下文切换还有CPU使用率php
CPU使用率
Linux做为一个多任务操做系统，将每一个CPU的时间划分为很短的时间片，再经过调度器轮流分配给每一个任务使用，所以形成多任务同时运行的错觉。并发
Linux经过/proc虚拟文件系统，向用户提供了系统内部状态的信息。 好比 /proc/stat 提供了系统的CPU和任务统计信息dom
有须要的时候，查询man proc就能够清楚每一列的涵义，她们都是CPU使用率相关重要指标函数
CPU使用率就是除了空闲时间以外的其余时间占总CPU时间的百分比php-fpm
事实上，为了计算CPU使用率，性能工具通常都会取间隔一段时间(好比3s)的两次值，做差后，再计算出这段时间内的平均CPU使用率，而直接使用/proc/stat的数据通常都是开机以来的累加值而后的平均CPU使用率，通常没有什么参考价值工具
性能分析工具给出的都是间隔一段时间的平均CPU使用率，因此要注意间隔时间的设置，好比 top和ps这两个工具报告CPU使用率，默认的结果极可能不同，由于top默认是3s间隔时间，而ps是用的确实进程的整个生命周期。oop
怎么查看CPU使用率
top和ps是经常使用的性能分析工具，top显示了系统整体的CPU和内存使用状况，以及各个进程的资源使用状况。ps则只显示了每一个进程的资源使用状况性能
第三行 %Cpu就是系统的CPU使用率，只是把CPU时间变化成了CPU使用率，不过top默认显示是全部CPU的平均值，这个时候须要按数字1，就能够切换每一个CPU使用率测试
空白行以后是每一个进程的实时信息，每一个进程都有一个%CPU列，标识进程的CPU使用率。它是用户态和内核态CPU使用率的综合，包括进程用户空间使用的CPU、经过系统调用执行的内核空间CPU、以及在就绪队列等待运行的CPU。在虚拟环境中，还包括运行虚拟机占用的CPU操作系统
top并无细分进程的用户态CPU和内核态CPU，能够用pidstat，它是专门分析每一个进程CPU使用状况的工具
CPU使用率太高怎么办？
经过top、ps、pidstat等工具，可以轻松找到CPU使用率较高的进程，接下来怎么查找占用CPU的代码是哪一个函数呢？
首先是GDB，这个功能强大的程序调试利器，可是，GDB并不适合在性能分析的早期应用，由于GDB调试程序过程会终端程序运行,这在线上环境每每是不容许的。因此，GDB只适合在性能分析的后期，当找到了出问题的大体函数后，线下再借助它进一步调试函数内部问题。
我这里使用pref分析问题，一般使用pref top。表格式样的数据:
其中第二种常见用法也就是perf record和perf report。perf top虽然实时展现系统的性能信息，可是它的缺点并不保存数据，没法用于离线或者后续分析，而perf record则提供了保存数据功能，保存后的数据用perf report解析展现。还能够加-g 参数开启调用关系的采样。
案例：PHP+Nginx的Web服务为例，当发现CPU使用率太高的问题
1>首先，并发10个请求测试Nginx性能，测试100个请求
Nginx承受每秒的平均请求只有89.57，将测试请求增长到10000时候呢。
能够看到PHP-fpm使用率加起来接近
经过perf top -g -p 进程号
而后查找这两个函数，发现了文件的源码
小结：
CPU使用率是最直观最经常使用的系统性能指标，咱们在排查性能问题一般会关注第一个指标，尤为弄清楚用户(%user)、Nice(%nice)、系统(%system)、等待I/O(%iowait)、中断(%irq)以及软中断(%softirq)这几种不一样CPU使用率
好比说：
系统的CPU使用率很高，却找不到缘由？
当系统的的CPU使用率很高的时候，不必定能找到相对应高的CPU使用率进程
案例分析：
1>首先进行ab压力测试
2>而后第一个终端运行top，观看CPU
发现用户的CPU使用达到80%，系统的使用15%，空闲CPU(id)只有2.8。
也没有发现可疑进程：
3>这个时候看来top无论用了，接下来使用pidstat，分析进程的CPU使用状况
这个时候也发现CPU使用率不高，Docker和Nginx也是有4%和3%，可是CPU使用率高达80%
5>咱们再次运行top，而且观察发现
ab测试的参数，并发请求为5，在看进程表的话php-fpm数量也是5，再加上Nginx，一共六个，可是这些都是出于Sleep(S)状态，真正在Running(R)的是stress进程。
6>可是根据进程PID，pidstat分析这几个进程使用-P选项，却没有任何输出
这个时候在怀疑性能工具出问题以前，最好先用其余工具交叉确认下，使用ps查看进程的状态
7>这个时候发现原来进程不存在了，因此pidstat没有任何输出，因此既然进程没有了，那么性能问题也没有了吧
8>这个时候再用top确认一下
结果仍是同样CPU使用率高达80%，而且原来的咱们看到的stress进程的ID跟前面是不一样了。进程的PID再变，这说明什么？
9>这个时候可使用perf record -g命令 ，并等待一会(15s)后按 Ctrl+C退出。而后再运行perf report 查看报告。
这个时候看到stress占用CPU时钟事件的77%，并且调用栈比较最高，是随机生成函数random()，这个时候只要减小或者删除stress调用就能够减轻系统的CPU压力
execsnoop:在这里案例中，咱们使用了top、pidstat、pstree等工具分析了CPU使用率高的问题，并发现CPU升高是短时进程stress致使的，这个分析比较复杂。
这个时候就能够用更好地办法监控，execsnoop就是一个专为短时进程设计的工具。它经过ftrace实时监控进程的exec()行为，并输出短时进程的基本信息，包括进程PID、父进程PID、命令行参数以及执行结果。好比经过execsnoop监控上述案例，就能够直接获得大量stress在不停启动。
execsnoop所用的ftrace是一种经常使用的动态追踪技术，通常用于分析Linux内核的运行时行为
小结：碰到常规问题没法解释的CPU使用率状况时，首先想到有多是短时应用致使的问题。有这两种状况
第一：应用里直接调用了其余二进制程序，这些程序一般运行时间短，经过top等工具不容易发现
第二：应用自己不断的崩溃重启，而启动过程的资源初始化，占用至关多CPU
对于这类进程，咱们能够用pstree或者execsnoop找到他们父进程，再从父进程所在应用入手排查问题的根源
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
