本随笔介绍CPU负载的排查手段。
查看系统负载的工具：uptime，w，都能查看系统负载，系统平均负载是处于运行或不可打扰状态的进程的平均数，
- 可运行：运行态，占用CPU，或就绪态，等待CPU调度。
- 不可打扰：阻塞，正在等待I/O
例1. 使用uptime查看系统负载
# uptime
19:26:17 up 49 days, 7:34, 1 user, load average: 0.67, 0.51, 0.41
这里我们关注的是最后三列，即系统1分钟、5分钟、15分钟内的平均负载，判断一个系统负载是否偏高需要计算单核CPU的平均负载，等于这里uptime命令显示的系统平均负载 / CPU核数，一般以0.7为比较合适的值。偏高说明有比较多的进程在等待使用CPU资源。
例2. 使用w查看系统负载
1 # w
2 19:29:47 up 49 days, 7:38, 1 user, load average: 0.42, 0.46, 0.41
3 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
4 openstac pts/1 10.14.16.25 19:21 1.00s 0.19s 0.03s sshd: openstack [priv]
使用 w 命令也可以查看类似的信息，w 命令还提供了当前登录用户，以及正在执行的操作等信息。
系统负载可以是CPU密集型的，也可以是RAM密集型和I/O密集型的，CPU密集型的系统比I/O密集型的系统响应度更好，因为I/O密集型的系统的磁盘I/O可能完全饱和，导致登录就很费事。
2. top命令
top命令不仅可以查看当前系统的平均负载，还可以查看不同进程对于CPU、内存等资源的使用情况，在内存排障部分我们也将介绍top命令。
例3. 使用top命令查看CPU使用率
top - 19:36:00 up 49 days, 7:44, 1 user, load average: 0.34, 0.38, 0.40
Tasks: 216 total, 3 running, 213 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.0 us, 6.1 sy, 0.0 ni, 88.0 id, 1.5 wa, 0.0 hi, 0.4 si, 0.0 st
KiB Mem: 12260128 total, 6160704 used, 6099424 free, 331448 buffers
KiB Swap: 0 total, 0 used, 0 free. 1393220 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
ntp 20 0 33508 2180 1536 S 47.2 0.0 5765:44 ntpd
ceilome+ 20 0 137464 60096 4740 S 5.0 0.5 833:30.17 ceilometer-agen
rabbitmq 20 0 2482652 274620 2612 S 1.7 2.2 1222:49 beam.smp
mysql 20 0 655848 310788 9928 S 1.0 2.5 368:28.78 mysqld
nova 20 0 355508 104096 3944 S 1.0 0.8 284:42.22 nova-conductor
root 39 19 0 0 0 S 0.7 0.0 409:22.74 kipmi0
nova 20 0 356304 105000 3936 S 0.7 0.9 249:34.72 nova-conductor
glance 20 0 182964 88608 4800 S 0.7 0.7 461:00.03 glance-api
例3给出了一个top命令的截图示意，默认情况下，top命令是以CPU使用率由高到低排序显示进程信息的，在 top 信息界面按 K 键，并输入想要终止的PID，就可以直接杀死指定进程。
top的 -b 选项开启批处理模式，将每次刷新全部打印到stdout
top的 -n 选项指定退出top命令前刷新多少次信息。
top命令的输出：
第1行：与uptime相同；
第3行：当前的CPU运行情况：
us：非nice用户进程占用CPU的比率
sy：内核、内核进程占用CPU的比率；
ni：如果一些用户进程修改过优先级，这里显示这些进程占用CPU时间的比率；
id：CPU空闲比率，如果系统缓慢而这个值很高，说明系统慢的原因不是CPU负载高；
wa：CPU等待执行I/O操作的时间比率，该指标可以用来排查磁盘I/O的问题，通常结合wa和id判断
hi：CPU处理硬件终端所占时间的比率；
si：CPU处理软件终端所占时间的比率；
st：流逝的时间，虚拟机中的其他任务所占CPU时间的比率；
用户进程占比高，wa低，说明系统缓慢的原因在于进程占用大量CPU，通常还会伴有教低的id，说明CPU空转时间很少；
wa低，id高，可以排除CPU资源瓶颈的可能。
wa高，说明I/O占用了大量的CPU时间，需要检查交换空间的使用，交换空间位于磁盘上，性能远低于内存，当内存耗尽开始使用交换空间时，将会给性能带来严重影响，所以对于性能要求较高的服务器，一般建议关闭交换空间。另一方面，如果内存充足，但wa很高，说明需要检查哪个进程占用了大量的I/O资源。
3. iostat命令
iostat命令可以查看系统分区的IO使用情况
例4. iostat命令查看系统IO占用
在第2行系统发行版本下面的第4、5行，可以看到与top命令中CPU使用情况类似的信息，
第7行，可以看到一些IO指标：
tps: 每秒I/O传输请求量；
kB_read/s：每秒读取多少KB；
kB_wrtn/s：每秒写多少KB；
kB_read：一共读了多少KB；
kB_wrtn：一共写了多少KB。
iostat命令属于sysstat工具包，由于我们的机器只挂载了一块硬盘，因此不能体现不同设备的I/O区别。
- iotop命令
iotop命令类似于top命令，但是显示的是各个进程的I/O情况，对于定位I/O操作较重的进程有比较大的作用。
例5. iotop命令与进程的IO状况
这里可以看到不同任务的读写强度。
二、 sysstat工具与负载历史回放
很多系统负载过高的时候我们是无法立即获知或者立即解决的，当检测到或者知道历史的高负载状况时，可能需要回放历史监控数据，这时 sar 命令就派上用场了，sar命令同样来自sysstat工具包，可以记录系统的CPU负载、I/O状况和内存使用记录，便于历史数据的回放。
Ubuntu系统上，sysstat的配置文件在/etc/default/sysstat，sysstat默认关闭，通过将该文件中的ENABLED改为"true"启用；历史日志的存放位置为/var/log/sysstat
Red Hat系统上，sysstat的配置文件在/etc/sysconfig/sysstat文件，历史日志的存放位置为/var/log/sa
两种系统上，统计信息都是每10分钟记录一次，每天的23:59会分割统计文件，这些操作的频率都在/etc/cron.d/sysstat文件配置。
1. sar命令查看CPU、内存和磁盘记录
默认情况下，sar命令显示当天的统计信息，不带参数显示CPU统计信息，参数-r显示收集的内存记录，-b显示磁盘I/O
例6. 使用sar命令查看当天CPU使用
例7. 使用sar命令查看当天内存使用
例8. 使用sar命令查看当天IO统计记录
- 使用sar查看指定时间、指定日期的历史记录
例9. 使用参数-s和-e限定查看的时间
例9 只查看当天20:00:00后的CPU统计记录
例10. 使用参数-f查看本月内之前某一天的历史统计信息
sysstat工具只存储1个月内的系统使用记录，每天的记录以saN为文件名保存在相应的日志目录中，这里我们查看本月8号的CPU使用记录。
