centos 系统性能排查

系统的load是指正在运行running one和准备好运行runnable one的进程的总数。比如现在系统有2个正在运行的进程，3个可运行进程，那么系统的load就是5。load average就是一定时间内的load数量。

load average显示的是最近1分钟、5分钟和15分钟的系统平均负载。系统平均负载表示系统平均负载被定义为在特定时间间隔内运行队列中(在CPU上运行或者等待运行多少进程)的平均进程数。

下面来看看描述 CPU 的性能指标：

1. CPU 使用率：CPU 使用率描述了非空闲时间占总 CPU 时间的百分比，根据 CPU 上运行任务的不同，又被分为用户 CPU、系统 CPU、等待 I/O CPU、软中断和硬中断等。
2. 平均负载（Load Average）：是系统的平均活跃进程数。它反应了系统的整体负载情况，主要包括三个数值，分别指过去 1 分钟、过去 5 分钟和过去 15 分钟的平均负载。理想情况下，平均负载等于逻辑 CPU 个数，这表示每个 CPU 都恰好被充分利用。如果平均负载大于逻辑 CPU 个数，就表示负载比较重了。
3. 进程上下文切换：包括：无法获取资源而导致的自愿上下文切换；被系统强制调度导致的非自愿上下文切换。

4. CPU 缓存的命中率：CPU 在访问内存的时候，免不了要等待内存的响应。为了协调这两者巨大的性能差距，CPU 缓存（通常是多级缓存）就出现了。

   
   
   

   image.png

性能指标和性能工具结合使用

思路：

使用top命令查看，如top 发现了软中断 CPU 使用率高后，下一步自然就想知道具体的软中断类型。那在哪里可以观察各类软中断的运行情况呢？当然是 proc 文件系统中的 /proc/softirqs 这个文件。

image.png

注：从上图中看到软中断包括了 10 个类别，分别对应不同的工作类型。比如 NET_RX 表示网络接收中断，NET_TX 表示网络发送中断， BLOCK表示锁，TASKLET表示定时；SCHED表示调度等，可以通过查看 /proc/softirqs 来观察软中断的运行情况。

软中断高的举例：

top发现软中断si很高
vmstat 确认中断很高
watch cat proc/softirqs 查看那个软中断变化最快，发现是网络接受最多
sar 查看哪个网口接受数据包最多
tcpdump 抓包80端口，发现全是S（sync）包
确定是SYN FLOOD

CPU 性能指标的工具：

image.png

工具指标”指南使用"

image.png

!

top、vmstat 和 pidstat 命令详解

image.png

这三个命令，几乎包含了所有重要的 CPU 性能指标，比如：
从 top 的输出可以得到各种 CPU 使用率以及僵尸进程和平均负载等信息。
从 vmstat 的输出可以得到上下文切换次数、中断次数、运行状态和不可中断状态的进程数。
从 pidstat 的输出可以得到进程的用户 CPU 使用率、系统 CPU 使用率、以及自愿上下文切换和非自愿上下文切换情况。
例子1：pidstat 输出的进程用户 CPU 使用率升高，会导致 top 输出的用户 CPU 使用率升高。所以，当发现 top 输出的用户 CPU 使用率有问题时，可以跟 pidstat 的输出做对比，观察是否是某个进程导致的问题。而找出导致性能问题的进程后，就要用进程分析工具来分析进程的行为，比如使用 strace 分析系统调用情况，以及使用 perf 分析调用链中各级函数的执行情况。
例子2：
top 输出的平均负载升高，可以跟 vmstat 输出的运行状态和不可中断状态的进程数做对比，观察是哪种进程导致的负载升高。
如果是不可中断进程数增多了，那么就需要作 I/O 的分析，也就是用 dstat 或 sar 等工具，进一步分析 I/O 的情况。
如果是运行状态进程数增多了，那就需要回到 top 和 pidstat，找出这些处于运行状态的到底是什么进程，然后再用进程分析工具，做进一步分析。
例子3：
top 输出的软中断 CPU 使用率升高时，可以查看 /proc/softirqs 文件中各种类型软中断的变化情况，确定到底是哪种软中断出的问题。比如，发现是网络接收中断导致的问题，那就可以继续用网络分析工具 sar 和 tcpdump 来分析。

查看磁盘io

先用iostat查看磁盘io 是否读写负载很高。
如果 iostat 没有，要 yum install sysstat安装。
如果%util接近100%,表明I/O请求太多,I/O系统已经满负荷，磁盘可能存在瓶颈,一般%util大于70%,I/O压力就比较大，读取速度有较多的wait，然后再看其他的参数。

image.png

rrqm/s:每秒进行merge的读操作数目。即delta(rmerge)/s
wrqm/s:每秒进行merge的写操作数目。即delta(wmerge)/s
r/s:每秒完成的读I/O设备次数。即delta(rio)/s
w/s:每秒完成的写I/0设备次数。即delta(wio)/s
rsec/s:每秒读扇区数。即delta(rsect)/s
wsec/s:每秒写扇区数。即delta(wsect)/s
rKB/s:每秒读K字节数。是rsec/s的一半，因为每扇区大小为512字节
wKB/s:每秒写K字节数。是wsec/s的一半
avgrq-sz:平均每次设备I/O操作的数据大小(扇区)。即delta(rsect+wsect)/delta(rio+wio)
avgqu-sz:平均I/O队列长度。即delta(aveq)/s/1000(因为aveq的单位为毫秒)
await:平均每次设备I/O操作的等待时间(毫秒)。即delta(ruse+wuse)/delta(rio+wio)
svctm:平均每次设备I/O操作的服务时间(毫秒)。即delta(use)/delta(rio+wio)
%util:一秒中有百分之多少的时间用于I/O操作,或者说一秒中有多少时间I/O队列是非空的

iotop找占用io读写很高的进程

yum install iotop -y
用iotop命令查看那个进程的读写，找出进程

image.png

CPU低而负载确很高 的场景

等待被授权予CPU运行权限的进程
等待磁盘I/O完成的进程
cpu低而负载高也就是说等待磁盘I/O完成的进程过多，就会导致队列长度过大，这样就体现到负载过大了，但实际是此时cpu被分配去执行别的任务或空闲，具体场景有如下几种。
场景一：磁盘读写请求过多就会导致大量I/O等待
cpu的工作效率要高于磁盘，而进程在cpu上面运行需要访问磁盘文件，这个时候cpu会向内核发起调用文件的请求，让内核去磁盘取文件，这个时候会切换到其他进程或者空闲，这个任务就会转换为不可中断睡眠状态。当这种读写请求过多就会导致不可中断睡眠状态的进程过多，从而导致负载高，cpu低的情况。
场景二：MySQL中存在没有索引的语句或存在死锁等情况
MySQL的数据是存储在硬盘中，如果需要进行sql查询，需要先把数据从磁盘加载到内存中。当在数据特别大的时候，如果执行的sql语句没有索引，就会造成扫描表的行数过大导致I/O阻塞，或者是语句中存在死锁，也会造成I/O阻塞，从而导致不可中断睡眠进程过多，导致负载过大。
场景三：外接硬盘故障，常见有挂了NFS，但是NFS server故障
系统挂载了外接硬盘如NFS共享存储，经常会有大量的读写请求去访问NFS存储的文件，如果这个时候NFS Server故障，那么就会导致进程读写请求一直获取不到资源，从而进程一直是不可中断状态，造成负载很高。