cpu使用率总是100怎么办,cpu使用率100是什么意思
CPU利用率的概念是通过将CPU时间分成时间片，按顺序执行任务，达到多任务并发的效果。时间由CPU以拍率和拍数来维护。节拍单位为HZ，分为内核节拍率和用户节拍率。用户拍率固定在100(即1/100秒，10ms)，每秒触发100次时间中断，完全不发生时间中断。
在/proc虚拟文件系统中，用户可以看到关于系统内部状态的信息。此外，还可以通过/proc/stat查看系统的CPU和任务统计。接下来，CPU的：
$ cat/proc/stat grep CPU CPU 292464724367061293118901003184404804609190 CPU 014567277219354818594761835380172020220 CPU 130第2至11列按场景显示累计CPU节拍。
第一列表示CPU，其他列的含义如下：
User(us)表示用户状态CPU时间，Nice time nice) ni)的友好值不包括在内，表示低优先级的用户状态CPU时间，范围从-20到19。值越大，优先级越低system(sys)car O time Low wait(wa)CPU time wait I/O IRQ)hi)CPU time handling hardware interruptions steal(ST)虚拟机运行时消耗的CPU时间(guest)虚拟机运行时所需的CPU时间(guest_nice) gnice)低优先级虚拟机运行时一般指(总CPU空闲时间-总CPU空闲时间)/各种性能工具基本上是用同样的方法计算的：比如top命令取每一秒间隔的平均值，而ps取全进程生命周期。
关于如何显示CPU利用率的一般命令：
Top显示系统整体的CPU和内存使用情况，以及默认情况下每个进程的资源使用情况。按1键分别显示每个CPU的值，ps为每个进程的资源使用情况top-18336039336024天。55分钟平均负载：01、0.24、0.32任务：总计166、2运行、164睡眠、0停止、0僵尸%Cpu0 : 1.3 us、0.7 sy、0.7 sy 0.0 wa、0.0 hi、0.0 si、0.0 st%Cpu1: 1.0 us、0.3 sy、0.0 ni、98.3 id、0.0 wa、0.0 hi、0.3 si、0.0stkibmem3881688查看每个流程的详细信息。
$ pidstat 1 2 #秒间隔内两组CPU利用率Linux 3 . 10 . 0-693 . 11 . 1 . el7 . x86 _ 64(ML dhb 2 zeap 40j 01 VG 100 ifs F4Z)01/15/2019 _ x86)06336044336029 pmuipid % usr % system % guest % cpucpucommand 063604336030pm 03871.99
9 1 celery 06:44:30PM 0 19437 0.00 0.99 0.00 0.99 1 PID stat 06:44:30PM UID PID % usr % system % guest % CPU CPU命令06:44:31PM 0 3871 0.00 1.00 0 0.00 1。00 0阿里云敦06:44:31下午0 7125 1.00 0.00 0.00 1.00 1 docker-proxy 06:44:31下午0 26056 0.00 1.00 0.00 1.00 0 0工作人员/0:2.Average:UID PID % usr % system % guest % CPU CPU命令平均值：0 3871 0.50 0.50 0.00 1.00-AliYunDunAverage:0 7125 0.50 0.00 0.00 0.50-docker-proxy平均值：0 18681 0.50 0 0.00 0 0.00-0.50-celery平均值：0 19437 0.00 0 0 0.50 0 0 0.00 0perf性能分析工具通过上述工具找到CPU利用率高的进程后，如何进一步定位是哪个函数造成的？
Perf是linux内置的性能分析工具(如果没有，可以通过yum手动安装)。我们来看看如何用它来解决上述问题。
perf的3种常见用法：
顶部穿孔系统画像工具，用来实时显示占用中央处理器时钟最多的函数或指令性能记录采样性能数据并保存绩效报告解析性能记录保存的数据最高性能$最高性能#具体含义可以男人性能顶部查看样本：26万的事件“中央处理器时钟",事件计数（大约1117764011Overhead共享对象符号14.82%[kernel][k]_ raw _ spin _ unlock _ irqrestore 5.45%[kernel][k]run _ timer _ softirq 4.98%[kernel][k]finish _ task _ switch 2.49%[kernel][k]_ _ do _ softirq 1.21%[kernel][k]tick _ nohz _ idle _ exit 1.17% perf .]Rb _ next 1.01%[内核][k]sk _ run _ filter 0.95%[内核][k]rcu _ process _ callbacks 0.94% python 2.7[.]0x00000000001614bb第一行有3个参数：
样品采样数事件事件类型事件计数时间总数这里的情况是，性能采集了260千个的中央处理器时钟时间，而总事件数是1326083091
下面具体列的含义：
在头顶上占用比例共享对象函数/指定所在的【动态共享对象】,比如内核，进程名，动态链接库名，内核模块等目标动态共享对象的类型： [.]用户空间的可执行程序或动态链接库[k]内核空间标志函数名（未知的用16进制地址表示)性能记录性能报告性能排名展示的系统实时性能信息，但是数据无法保存，也就不能用于离线或后续分析性能记录提供了保存采样数据，然后使用绩效报告自动解析数据并展示：
$性能记录#性能记录开始采样，ctrl c终止采样^C[性能记录：被唤醒26次写入数据][性能记录：捕获并写入7.034 MB性能数据(140390个样本)]$性能报告#展示形式同顶部穿孔压测分析这里我们使用ab(阿帕奇板凳),来模拟客户端的超文本传送协议请求。
服务器A运行网应用，服务器B使用腹肌进行模拟请求
$ a b-c 100-n 1000 http://API。server _ a . com/home/all/#-c 100并发100个请求-n 1000总共1000个请求基准测试api.server_a.com(耐心等待)完成100个请求完成200个请求完成300个请求完成400个请求完成500个请求完成600个请求完成700个请求完成800个请求完成900个请求完成1000个请求完成1000个请求服务器软件：nginx/1。12 .2服务器主机名：API。server _ a . com服务器端口：80文档路径：/home/com每秒可以承受的平均请求每次请求的时间：826.014[毫秒]每个请求的（平均)时间：8.260[毫秒](所有并发请求的平均时间)#平均每个请求的响应时间传输速率：636.92[千字节/秒]接收的连接次数（毫秒)分钟平均值[/-标清]中值最大连接数：2 3 3 3.8 3 122处理：82 778 158.6 784 1473等待：80 778 158.6 784 1473总计：85 781 158.6 787 1476在特定时间内处理的请求的百分比（毫秒)50% 787 66% 819运行以上测试期间，通过顶端查看服务器A的性能情况：
top - 16:21:45 up 74 days，22:38，4个用户，平均负载：1.23，0.50，0.37任务：总计142，8个运行，127个睡眠，7个停止，0个僵尸%Cpu0 : 94.6 us，3.0 sy，0.0 ni，0.7 id，0.0 wa，0.0 hi，1.7 si，0.0 st%Cpu1 : 94.0 us，2.3 sy，0.0 ni，320356可用内存PID用户PR NI VIRT RES SHR S %CPU %MEM时间命令11684 Root 20 0 369276 104768 3656S 20.3 2.7 0:12.24 uwsgi 11600 Root 20 0 516668 107452 7028S 19.3 2 . 8 0:22.65 uwsgi 11674 Root 20 368764
使用perf分析调用链，我们可以找到导致CPU利用率增加的函数：
Perf top -g -p 1651# -g打开调用关系分析；-p指定进程号。注意，如果应用程序运行在docker容器中，上面的输出结果不能显示具体的函数名，而是一串十六进制字符。因此，不建议在docker中进行测试。
短时进程有时候CPU利用率很高，但是我们找不到是哪个进程造成的。原因可能如下：
进程不断崩溃重启(可能是配置错误的原因)。短期进程：调用应用程序中执行的命令，这些命令只运行很短的时间。对于短期流程，常用的性能检测工具很难有效监控(可能在top(状态为R)出现一次，然后消失，又突然出现)。有时，您可以通过pstree找到调用短时进程的父进程来解决问题：
Pstree grep短时进程名称常用工具难以监控短时进程。Execsoop3359github.com/Brendan Gregg/perf-tools/blob/master/Execsoop()是一个用于监控短时流程的特殊工具：
Execsoop #为了结束监控，ctl c通过Execsoop找到父进程，从父进程所在的应用程序开始，然后对问题进行故障排除。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。