在平时的运维工作中，当一台服务器的性能出现问题时，通常会去看当前的CPU使用情况，尤其是看下CPU的负载情况(load average)。对一般的系统来说，根据cpu数量去判断。比如有2颗cup的机器。如果平均负载始终在1.2以下，那么基本不会出现cpu不够用的情况。也就是Load平均要小于Cpu的数量。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 | 对于cpu负载的理解，首先需要搞清楚下面几个问题： 1）系统load高不一定是性能有问题。因为Load高也许是因为在进行cpu密集型的计算 2）系统Load高不一定是CPU能力问题或数量不够。因为Load高只是代表需要运行的队列累计过多了。但队列中的任务实际可能是耗Cpu的，也可能是耗i/0或者其他因素的。 3）系统长期Load高，解决办法不是一味地首先增加CPU因为Load只是表象，不是实质。增加CPU个别情况下会临时看到Load下降，但治标不治本。 4）在Load average 高的情况下需要鉴别系统瓶颈到底是CPU不足，还是io不够快造成或是内存不足造成的。 ===============================================================================================================要想获得服务器的CPU负载情况，有下面几种命令：1）w命令[root@localhost ~]# w 12:12:41 up 167 days, 20:46, 2 users, load average: 0.00, 0.01, 0.05USER TTY FROM LOGIN@ IDLE JCPU PCPU WHATroot pts/0 192.168.1.5 10:01 1.00s 0.11s 0.00s wroot pts/2 192.168.1.5 10:19 1:47m 0.04s 0.04s -bash 2）uptime命令（一般首先会根据最后那个15分钟的load负载为准）[root@localhost ~]# uptime 12:12:55 up 167 days, 20:46, 2 users, load average: 0.00, 0.01, 0.05 3）top命令[root@localhost ~]# toptop - 12:13:22 up 167 days, 20:47, 2 users, load average: 0.00, 0.01, 0.05Tasks: 272 total, 1 running, 271 sleeping, 0 stopped, 0 zombie%Cpu(s): 0.0 us, 0.1 sy, 0.0 ni, 99.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stKiB Mem : 65759080 total, 58842616 free, 547908 used, 6368556 buff/cacheKiB Swap: 2097148 total, 2097148 free, 0 used. 64264884 avail Mem................ 对上面第三行的解释：us（user cpu time）：用户态使用的cpu时间比。该值较高时，说明用户进程消耗的 CPU 时间比较多，比如，如果该值长期超过 50%，则需要对程序算法或代码等进行优化。sy（system cpu time）：系统态使用的cpu时间比。ni（user nice cpu time）：用做nice加权的进程分配的用户态cpu时间比id（idle cpu time）：空闲的cpu时间比。如果该值持续为0，同时sy是us的两倍，则通常说明系统则面临着 CPU 资源的短缺。wa（io wait cpu time）：cpu等待磁盘写入完成时间。该值较高时，说明IO等待比较严重，这可能磁盘大量作随机访问造成的，也可能是磁盘性能出现了瓶颈。hi（hardware irq）：硬中断消耗时间si（software irq）：软中断消耗时间st（steal time）：虚拟机偷取时间 以上解释的这些参数的值加起来是100%。 4）vmstat[root@localhost ~]# vmstatprocs -----------memory---------------------swap-------io---------system--------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st3 0 0 1639792 724280 4854236 0 0 4 34 4 0 19 45 35 0 0 解释说明：-----------------------------procs部分的解释r 列表示运行和等待cpu时间片的进程数，如果长期大于1，说明cpu不足，需要增加cpu。b 列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。-----------------------------cpu部分的解释us 列显示了用户方式下所花费 CPU 时间的百分比。us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期大于50%，需要考虑优化用户的程序。sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%，如果us+sy 大于 80%说明可能存在CPU不足。wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%，如果wa超过30%，说明IO等待严重，这可能是磁盘大量随机访问造成的，也可能磁盘或者 磁盘访问控制器的带宽瓶颈造成的(主要是块操作)。id 列显示了cpu处在空闲状态的时间百分比-----------------------------system部分的解释in 列表示在某一时间间隔中观测到的每秒设备中断数。cs列表示每秒产生的上下文切换次数，如当 cs 比磁盘 I/O 和网络信息包速率高得多，都应进行进一步调查。-----------------------------memory部分的解释swpd 切换到内存交换区的内存数量(k表示)。如果swpd的值不为0，或者比较大，比如超过了100m，只要si、so的值长期为0，系统性能还是正常free 当前的空闲页面列表中内存数量(k表示)buff 作为buffer cache的内存数量，一般对块设备的读写才需要缓冲。cache: 作为page cache的内存数量，一般作为文件系统的cache，如果cache较大，说明用到cache的文件较多，如果此时IO中bi比较小，说明文件系统效率比较好。-----------------------------swap部分的解释si 由内存进入内存交换区数量。so由内存交换区进入内存数量。-----------------------------IO部分的解释bi 从块设备读入数据的总量（读磁盘）（每秒kb）。bo 块设备写入数据的总量（写磁盘）（每秒kb） 5）也可以使用dstat命令查看cpu信息[root@localhost ~]# dstat----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--usr sys idl wai hiq siq| read writ| recv send| in out | int csw 19 45 35 0 0 0| 30k 265k| 0 0 | 0 0 |9025 12k 9 18 73 0 0 0| 0 144k|2578k 65k| 0 0 |3956 4343 6）可以使用iostat查看IO负载[root@localhost ~]# iostat 1 1Linux 2.6.32-696.16.1.el6.x86_64 (nc-ftp01.kevin.cn) 2017年12月29日 _x86_64_ (4 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 19.32 0.00 45.44 0.06 0.26 34.93 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtnxvda 14.17 29.94 265.17 63120486 558975100解释说明：avg-cpu: 总体cpu使用情况统计信息，对于多核cpu，这里为所有cpu的平均值%user: 在用户级别运行所使用的CPU的百分比.%nice: nice操作所使用的CPU的百分比.%sys: 在系统级别(kernel)运行所使用CPU的百分比.%iowait: CPU等待硬件I/O时,所占用CPU百分比.%idle: CPU空闲时间的百分比.Device段:各磁盘设备的IO统计信息tps: 每秒钟发送到的I/O请求数.Blk_read /s: 每秒读取的block数.Blk_wrtn/s: 每秒写入的block数.Blk_read: 读入的block总数.Blk_wrtn: 写入的block总数.[root@localhost ~]# iostat -x -k -d 1Linux 2.6.32-696.el6.x86_64 (centos6-vm02) 01/04/2018 _x86_64_ (4 CPU)Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilscd0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 0.36 0.36 0.00 0.36 0.00vda 0.01 0.13 0.04 0.13 0.60 0.89 18.12 0.00 2.78 0.19 3.53 2.55 0.04dm-0 0.00 0.00 0.04 0.22 0.58 0.88 11.25 0.00 3.27 0.25 3.82 1.61 0.04dm-1 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 0.13 0.13 0.00 0.04 0.00dm-2 0.00 0.00 0.00 0.00 0.00 0.00 7.91 0.00 0.19 0.10 5.00 0.16 0.00解释说明：rrqm/s: 每秒对该设备的读请求被合并次数，文件系统会对读取同块(block)的请求进行合并wrqm/s: 每秒对该设备的写请求被合并次数r/s: 每秒完成的读次数w/s: 每秒完成的写次数rkB/s: 每秒读数据量(kB为单位)wkB/s: 每秒写数据量(kB为单位)avgrq-sz:平均每次IO操作的数据量(扇区数为单位)avgqu-sz: 平均等待处理的IO请求队列长度await: 平均每次IO请求等待时间(包括等待时间和处理时间，毫秒为单位)svctm: 平均每次IO请求的处理时间(毫秒为单位)%util: 采用周期内用于IO操作的时间比率，即IO队列非空的时间比率如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。idle小于70% IO压力就较大了,一般读取速度有较多的wait。同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高) |
简单说下CPU负载和CPU利用率的区别
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | 0）load average：系统平均负载是CPU的Load，它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息， 也就是CPU使用队列的长度的统计信息，这个数字越小越好。1）CPU使用率：显示的是程序在运行期间实时占用的CPU百分比。2）CPU负载：显示的是一段时间内正在使用和等待使用CPU的平均任务数。CPU使用率高，并不意味着负载就一定大。举例来说：如果我有一个程序它需要一直使用CPU的运算功能，那么此时CPU的使用率可能达到100%，但是CPU的工作负载则是趋近于"1"，因为CPU仅负责一个工作啊。如果同时执行这样的程序两个呢？CPU的使用率还是100%，但是工作负载则变成2了。所以也就是说，当CPU的工作负载越大，代表CPU必须要在不同的工作之间进行频繁的工作切换。 3）CPU利用率高，并不意味着负载就一定大。举例来说：如果有一个程序它需要一直使用CPU的运算功能，那么此时CPU的使用率可能达到100%，但是CPU的工作负载则是趋近于"1"，因为CPU仅负责一个工作！如果同时执行这样的程序两个呢？CPU的使用率还是100%，但是工作负载则变成2了。所以也就是说，当CPU的工作负载越大，代表CPU必须要在不同的工作之间进行频繁的工作切换。 ------------------------下面通过一个电话亭打电话的比喻来说明这两者之间的区别------------------------某公用电话亭，有一个人在打电话，四个人在等待，每人限定使用电话一分钟，若有人一分钟之内没有打完电话，只能挂掉电话去排队，等待下一轮。电话在这里就相当于CPU，而正在或等待打电话的人就相当于任务数。 在电话亭使用过程中，肯定会有人打完电话走掉，有人没有打完电话而选择重新排队，更会有新增的人在这儿排队，这个人数的变化就相当于任务数的增减。为了统计平均负载情况，我们5分钟统计一次人数，并在第1、5、15分钟的时候对统计情况取平均值，从而形成第1、5、15分钟的平均负载。 有的人拿起电话就打，一直打完1分钟，而有的人可能前三十秒在找电话号码，或者在犹豫要不要打，后三十秒才真正在打电话。如果把电话看作CPU，人数看作任务，我们就说前一个人（任务）的CPU利用率高，后一个人（任务）的CPU利用率低。当然， CPU并不会在前三十秒工作，后三十秒歇着，只是说，有的程序涉及到大量的计算，所以CPU利用率就高，而有的程序牵涉到计算的部分很少，CPU利用率自然就低。但无论CPU的利用率是高是低，跟后面有多少任务在排队没有必然关系。 |
=========正确理解%iowait和CPU使用率=========
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | 1）%steal一般是在虚拟机中才能看到数值，比如CPU overcommitment很严重的VPS，而%guest和%nice一般都很低,所以也可以根据/proc/stat或者top可得，user + nice + system + idle + iowait + irq + softirq + steal = 1002）Linux进程状态运行状态（TASK_RUNNING）： 是运行态和就绪态的合并，表示进程正在运行或准备运行，Linux 中使用TASK_RUNNING 宏表示此状态可中断睡眠状态（浅度睡眠）（TASK_INTERRUPTIBLE）： 进程正在睡眠（被阻塞），等待资源到来是唤醒，也可以通过其他进程信号或时钟中断唤醒，进入运行队列。Linux 使用TASK_INTERRUPTIBLE 宏表示此状态。不可中断睡眠状态（深度睡眠状态）（TASK_UNINTERRUPTIBLE）： 其和浅度睡眠基本类似，但有一点就是不可被其他进程信号或时钟中断唤醒。Linux 使用TASK_UNINTERRUPTIBLE 宏表示此状态。暂停状态（TASK_STOPPED）： 进程暂停执行接受某种处理。如正在接受调试的进程处于这种状态，Linux 使用TASK_STOPPED 宏表示此状态。僵死状态（TASK_ZOMBIE）： 进程已经结束但未释放PCB，Linux 使用TASK_ZOMBIE 宏表示此状态。3）%iowait 的正确认知%iowait 表示在一个采样周期内有百分之几的时间属于以下情况：CPU空闲、并且有仍未完成的I/O请求。对 %iowait 常见的误解有两个： 一是误以为 %iowait 表示CPU不能工作的时间， 二是误以为 %iowait 表示I/O有瓶颈。首先 %iowait 升高并不能证明等待I/O的进程数量增多了，也不能证明等待I/O的总时间增加了。例如：在CPU繁忙期间发生的I/O，无论IO是多还是少，%iowait都不会变；当CPU繁忙程度下降时，有一部分IO落入CPU空闲时间段内，导致%iowait升高。再比如：IO的并发度低，%iowait就高；IO的并发度高，%iowait可能就比较低。可见%iowait是一个非常模糊的指标，如果看到 %iowait 升高，还需检查I/O量有没有明显增加，avserv/avwait/avque等指标有没有明显增大，应用有没有感觉变慢，如果都没有，就没什么好担心的。4）查看CPU使用率，推荐如下Linux命令：# top# sar -u 1 5# vmstat -n 1 5# mpstat -P ALL 1 5查看Load的值，推荐如下Linux命令：# top# uptime# sar -q 1 5 |
load average相关梳理（一分钟，五分钟，十五分钟的平均CPU负载，最重要的指标是最后一个数字，即前15分钟的平均CPU负载，这个数字越小越好。所谓CPU负载指的是一段时间内任务队列的长度，通俗的讲，就是一段时间内一共有多少任务在使用或等待使用CPU。（当前的"负载值除以cpu核数"就是cpu的利用率））
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 | load average表示的是系统的平均负荷，即CPU的Load。它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。它包括3个数字，分别表示系统在1、5、15分钟内进程队列中的平均进程数量（即处理的进程情况），原则上来说这3个数字越小越好，数字越小表示服务器的工作量越小，系统负荷比较轻 当CPU完全空闲的时候，平均负荷为0（即load average的值为0）；当CPU工作量饱和的时候，平均负荷为1。 这里需要注意的是：load average这个输出值，这三个值的大小一般不能大于系统逻辑CPU的个数比如一台服务器有4个逻辑CPU，如果load average的三个值长期大于4时，说明CPU很繁忙，负载很高，可能会影响系统性能；但是偶尔大于4时，倒不用担心，一般不会影响系统性能。相反，如果load average的输出值小于CPU的个数，则表示CPU还有空闲，比如本例中的输出，CPU是比较空闲的。 -------------load average举例理解---------------判断系统负荷是否过重，必须理解load average的真正含义。假设当前我的一台服务器只有一个CPU，所有的运算都必须由这个CPU来完成。不妨把这个CPU想象成一座大桥，桥上只有一根车道，所有车辆都必须从这根车道上通过（很显然，这座桥只能单向通行）。1）系统负荷为0，意味着大桥上一辆车也没有。2）系统负荷为0.5，意味着大桥一半的路段有车。3）系统负荷为1.0，意味着大桥的所有路段都有车，也就是说大桥已经"满"了。但是必须注意的是，直到此时大桥还是能顺畅通行的。4）系统负荷为1.7，意味着车辆太多了，大桥已经被占满了（100%），后面等着上桥的车辆为桥面车辆的70%。 以此类推，系统负荷2.0，意味着等待上桥的车辆与桥面的车辆一样多； 系统负荷3.0，意味着等待上桥的车辆是桥面车辆的2倍。 总之，当系统负荷大于1，后面的车辆就必须等待了；系统负荷越大，过桥就必须等得越久。 CPU的系统负荷，基本上等同于上面的类比。大桥的通行能力，就是CPU的最大工作量；桥梁上的车辆，就是一个个等待CPU处理的进程（process）。如果CPU每分钟最多处理100个进程，那么：系统负荷0.2，意味着CPU在这1分钟里只处理20个进程；系统负荷1.0，意味着CPU在这1分钟 里正好处理100个进程；系统负荷1.7，意味着除了CPU正在处理的100个进程以外，还有70个进程正排队等着CPU处理。 为了服务器顺畅运行，系统负荷最好不要超过1.0，这样就没有进程需要等待了，所有进程都能第一时间得到处理。很显然，1.0是一个关键值，超过这个值，系统就不在最佳状态了，就需要动手干预了。 --------1.0是系统负荷的理想值吗？-----------不一定，系统管理员往往会留一点余地，当这个值达到0.7，就应当引起注意了。以往经验是这样的：当系统负荷持续大于0.7，必须开始调查了，问题出在哪里，防止情况恶化。当系统负荷持续大于1.0，必须动手寻找解决办法，把这个值降下来。当系统负荷达到5.0，就表明系统有很严重的问题，长时间没有响应，或者接近死机了。觉不能让系统达到这个值。 上面，假设我的这台服务器只有1个CPU。如果它装了2个CPU，就意味着服务器的处理能力翻了一倍，能够同时处理的进程数量也翻了一倍。还是用大桥来类比，两个CPU就意味着大桥有两根车道了，通车能力翻倍了。所以，2个CPU表明系统负荷可以达到2.0，此时每个CPU都达到100%的工作量。推广开来，n个CPU的服务器，可接受的系统负荷最大为n.0。 ---------至于load average是多少才算理想，这个有争议，各有各的说法---------个人比较赞同CPU负载小于等于"内核数乘以0.5-0.7"算是一种理想状态。比如4核CPU的服务器，理想负载是小于等于2，最好不要超过2.8，否则性能多少会受影响。 不管某个CPU的性能有多好，1秒钟能处理多少任务，可以认为它无关紧要，虽然事实并非如此。在评估CPU负载时，只以5分钟为单位做统计任务队列长度。如果每隔5分钟统计的时候，发现任务队列长度都是1，那么CPU负载就为1。 假如现在某台服务器只有一个单核的CPU，负载一直为1，意味着没有任务在排队，还不错。但是这台服务器是双核CPU，等于是有4个内核，每个内核的负载为1的话，总负载为4。这就是说，如果这台服务器的CPU负载长期保持在4左右，还可以接受。但是每个内核的负载为1，并不能算是一种理想状态！这意味着服务器的CPU一直很忙，不得清闲。 -----------load average返回三个平均值应该参考哪个值？------------如果只有1分钟的系统负荷大于1.0，其他两个时间段都小于1.0，这表明只是暂时现象，问题不大。如果15分钟内，平均系统负荷大于1.0（调整CPU核心数之后），表明问题持续存在，不是暂时现象。所以应该主要观察"15分钟系统负荷"，将它作为服务器正常运行的指标。 ----------如何来降低服务器的CPU负载？--------------最简单办法的是更换性能更好的服务器，不要想着仅仅提高CPU的性能，那没有用，CPU要发挥出它最好的性能还需要其它软硬件的配合。在服务器其它方面配置合理的情况下，CPU数量和CPU核心数（即内核数）都会影响到CPU负载，因为任务最终是要分配到CPU核心去处理的。两块CPU要比一块CPU好，双核要比单核好。因此，需要记住的是：除去CPU性能上的差异，CPU负载是基于内核数来计算的。有一个说法是"有多少内核，即有多少负载"。 |