学习重点
理解最基本的几个知识原理；掌握必要的性能工具；通过实际的场景演练，贯穿不同的组件常用工具图解：
本片文章基于极客时间Linux优化教程进行学习、并实操记录实验过程（坑）！
平均负载（Load Average）
是指时间单位内，系统处于**可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和CPU使用率并没有直接关系；
可运行状态：指正在使用CPU或者等待CPU的进程，处于running状态；不可中断状态：正处于系统内核中处理的进程，这些进程是不可打断的。比如正在向磁盘中写数据的进程或者正在处理HTTP请求的进程，如果被强行打断(kill，服务器突然断电)，就又可能出现数据丢失或者客户正在访问的页面数据丢失；所以不可中断状态是系统对进程和硬件设备的一种保护措施
简单来说：平均负载=单位时间内平均活跃进程
例如：运行htop
Load average平均负载在1分钟，5分钟，15分钟分别为：0.16，0.06，0.06；说明在时间段内有平均有
判断平均负载大小
首先负载率和CPU的核数有很大的关系。假如有1个单核CPU，如果此时的平均负载率为1，说明CPU的利用率为最理想，如果负载为2，说明CPU负载过大，有了超时等待，进程处理慢
所以当负载大于CPU核数的时候，说明CPU负载率过高了
查看线总核数
cat /proc/cpuinfo| grep "processor" # 显示有4个核心，0，1，2，3processor: 0model name: Common KVM processorprocessor: 1model name: Common KVM processorprocessor: 2model name: Common KVM processorprocessor: 3model name: Common KVM processor
查看CPU核数
cat /proc/cpuinfo| grep "cpu cores"| uniq2
查看CPU个数
cat /proc/cpuinfo| grep "physical id" |sort | uniq | wc -l # 显示有2个物理CPU2
分析平均负载
上面已经知道，平均负载有3个数值，到底该参考哪一个呢？
实际上都要看，三个数值显示了CPU1~15分钟内的负载趋势。
如果1~15分钟内，3个数值基本相同或者变化不大，那就说明负载很平稳；如果1分钟数值小于5~15分钟的数值，说名负载一直在减小；如果1分钟数值大于5~15分的数值，说明负载一直在持续增加，需要使用top或者hop持续观察，如果负载超过了CPU个数，说明系统正在发生过载现象，需要查找原因或者优化
在实际生产环境中，当平均负载高于CPU数量70%的时候，就应该分析排查问题了，但70%不是绝对，推荐还是把平均负载监控起来，形成历史数据，判断负载变化趋势。
平均负载与CPU使用率
在实际工作中，非常容易把平均负载和CPU使用率混淆。可能会有疑问，平均负载代表的是活跃进程数，那负载高了不就代表CPU使用率高了？
我们在看看平均负载的定义：时间单位内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数。
所以它不仅包括了正在使用的CPU进程，还包括等待的CPU和等I/O的进程
CPU使用率包括了单位时间内CPU繁忙度的统计，跟平均负载不一定对的上,例如:
CPU密集型：短时间内使用大量CPU会导致平均负载过高，此时平局负载和CPU使用率是对应的；I/O密集型：等待I/O也会导致平局负载过高，但CPU使用率不一定高；大量等待CPU进程调度，也会导致平均负载过高，此时的CPU使用率也比较高；
模拟实验
安装工具包
YUM安装
注意坑一：yum 安装的sysstat版本过低（版本为10.X），在pidstat里没有wait选项，建议使用编译安装！
实验需要安装2个软件包：stress和sysstat，2个安装包需要epel源，可以直接使用yum install -y epel-release或者手动添加：
vim /etc/yum.repos.d/epel.repo
添加如下内容：
[epel]name=Extra Packages for Enterprise Linux 7 - $basearch# It is much more secure to use the metalink, but if you wish to use a local mirror# place its address here.#baseurl=http://download.example/pub/epel/7/$basearchmetalink=/metalink?repo=epel-7&arch=$basearch&infra=$infra&content=$contentdirfailovermethod=priorityenabled=1gpgcheck=1gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7[epel-debuginfo]name=Extra Packages for Enterprise Linux 7 - $basearch - Debug# It is much more secure to use the metalink, but if you wish to use a local mirror# place its address here.#baseurl=http://download.example/pub/epel/7/$basearch/debugmetalink=/metalink?repo=epel-debug-7&arch=$basearch&infra=$infra&content=$contentdirfailovermethod=priorityenabled=0gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7gpgcheck=1[epel-source]name=Extra Packages for Enterprise Linux 7 - $basearch - Source# It is much more secure to use the metalink, but if you wish to use a local mirror# place it's address here.#baseurl=http://download.example/pub/epel/7/source/tree/metalink=/metalink?repo=epel-source-7&arch=$basearch&infra=$infra&content=$contentdirfailovermethod=priorityenabled=0gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7gpgcheck=1
更新缓存
yum makecacheyum update
查看是否添加成功
[root@pev ~]# yum repolist Loaded plugins: fastestmirror, product-id, search-disabled-repos, subscription-managerThis system is not registered with an entitlement server. You can use subscription-manager to register.Repository mariadb is listed more than once in the configurationLoading mirror speeds from cached hostfile* centos-sclo-rh: * centos-sclo-sclo: * epel: mirrors.repo id repo namestatusbase/7/x86_64 CentOS-7 - Base10,072centos-sclo-rh/x86_64CentOS-7 - SCLo rh 7,819centos-sclo-sclo/x86_64 CentOS-7 - SCLo sclo 816epel/x86_64Extra Packages for Enterprise Linux 7 - x86_64 13,713extras/7/x86_64CentOS-7 - Extras 500mariadb MariaDB 100mariadb-main MariaDB Server93mariadb-maxscaleMariaDB MaxScale 4mariadb-tools MariaDB Tools15updates/7/x86_64CentOS-7 - Updates 3,297repolist: 36,429
安装工具包
yum install stress -yyum install sysstat -y
编译安装 sysstat
安装之前卸载旧的sysstat
yum remove sysstat.x86_64
下载、解压安装
wet http://pagesperso-orange.fr/sebastien.godard/sysstat-12.5.5.tar.gztar xvf sysstat-12.5.5.tar.gzcd sysstat-12.5.5/# 开启定时搜集./configure --enable-install-cronmakemake install
修改sysstat配置文件，/etc/sysconfig/sysstat为sysstat为全局配置文件
vim /etc/sysconfig/sysstatSADC_OPTIONS="-D -L -S INT,DISK,XDISK "DELAY_RANGE=5 # 每天0时生成报告，为了避免其他定时任务挣I/O，延时5秒以后生成报告# 参数解析# -D 指定文件名，默认为saDD，DD代表天，-D指定为saYYMMDD，格式为年月日# -L 文件加锁，避免同样进程重写# -S 指定收集选项，INT为系统负载，DISK为块设备I/O，XDISK为扩展选项，统计分区使用率，其他还支持IPV6, POWER, SNMP,# ALL and XALL.具体可以参考：/linux/man-pages/man8/sadc.8.html
启动服务
[root@pev ~]# systemctl enable sysstat[root@pev ~]# systemctl start sysstat
启动服务后，会有配套的其他服务完成整个收集和报告流程，功能分别如下
生成的二进报告默认在：/var/log/sa下，名字为：sa+当前日期例如sa0120
生成得二进制报告文件可以使用sadf进行转换查看，例如查看CPU负载:
sadf -d -T -P ALL /var/log/sa/sa# -d：打印数据库格式，即上面由字段名+数据组成# -T：显示本地服务器时间# -P ALL ：显示所有CPU负载
显示内容如下
pev.154;-1;-01-20 11:59:18;LINUX-RESTART(4 CPU)# hostname;interval;timestamp;CPU;%user;%nice;%system;%iowait;%steal;%idlepev.154;600;-01-20 12:10:00;-1;0.03;0.00;0.03;0.00;0.00;99.94pev.154;600;-01-20 12:10:00;0;0.03;0.00;0.02;0.00;0.00;99.95pev.154;600;-01-20 12:10:00;1;0.03;0.00;0.03;0.02;0.00;99.92pev.154;600;-01-20 12:10:00;2;0.04;0.00;0.03;0.00;0.00;99.93pev.154;600;-01-20 12:10:00;3;0.03;0.00;0.02;0.00;0.00;99.95pev.154;600;-01-20 12:20:00;-1;0.05;0.01;0.03;0.00;0.00;99.90pev.154;600;-01-20 12:20:00;0;0.05;0.04;0.06;0.00;0.00;99.85pev.154;600;-01-20 12:20:00;1;0.03;0.00;0.02;0.02;0.00;99.92pev.154;600;-01-20 12:20:00;2;0.03;0.00;0.02;0.00;0.00;99.95pev.154;600;-01-20 12:20:00;3;0.09;0.00;0.04;0.00;0.00;99.87pev.154;600;-01-20 12:30:00;-1;0.03;0.00;0.02;0.00;0.00;99.94pev.154;600;-01-20 12:30:00;0;0.03;0.00;0.02;0.00;0.00;99.95
sysstat相关资料：
sysstat git_hub地址：/sysstat/sysstat
作者主页：http://sebastien.godard.pagesperso-orange.fr/
man文件：/linux/man-pages/man5/sysstat.5.html
sadf文件：/linux/man-pages/man1/sadf.1.html
开始实验
实验机器配置，和线上环境配置一致：
CPU：1个，4核内存：16G操作系统：CentOs7.9
工具包介绍：
stress：Linux系统压力测试工具，在此模拟异常进程导致的平均负载过高sysstat：包含了常用的Linux性能监测工具，用来分析系统的性能。案例中会用到mpstat和pidstat
测试时需要用到2个命令mpstat和pidstat：
mpstat：多核CPU性能分析工具，用来查看CPU性能指标，以及所有CPU平均指标pidstat：进程分析工具，用来时时查看进程的CPU、内存、I/O和上下文切换等性能指标
场景一：模拟CPU密集型实验
步骤1：打开3个终端，登录同一台服务器，记录当前时间段内的负载，可以看到1~15分钟平均负载分别为：0.01, 0.03, 0.03
[root@pev ~]# uptime14:23:46 up 21 min, 3 users, load average: 0.01, 0.03, 0.03
步骤2：在第一个终端打开stress，模拟一个CPU占用率100%的场景
-c：–cpu 1，指定一个1个cpu进程
-t：–timeout 600：600秒后超时退出
stress -c 1 -t 600
步骤3：在二个终端在此开启uptime，记录变化，使用参数-d，高亮显示变化的区域
watch -d uptime
步骤3：在第三个终端，运行mpstat，查看CPU使用率变化情况
-P ALL：监控所有进程
5：5秒输出一次报告
mpstat -P ALL 5
uptime显示负载逐渐提高
大概1分多钟，mpstat显示CPU第一个内核负载率上升为100%，但是iowait为0.00，所以说明高正是由CPU引起的
使用pidstat来查询哪个进程导致的CPU占用率为100%
-u：报告CPU使用率，5秒输出一次报告
pidstat -u 5 1
可以看到stress占用了100%
停止stress后，CPU恢复正常
uptime显示负载率正在下降：
场景二：模拟I/O密集型
步骤一：运行stress，模拟1个CPU下1条I/O读写，即不停的写入uplink，每次为1GB；
-i 1：执行1条worker
-d：模拟写入uplink，写入量默认为1GB
-t：600秒后超时退出
*注坑二：极客时间里使用的命令是：****stress -i 1 -t 600****使用sync把内存中的内容写到硬盘上；如果此时你内存上的临时文件过少或者没有，就会起不到压测作用，参考了一篇文章改为如下命令：**
stress -i 1 -d --timeout 600
步骤2和上面一样，不在叙述
观察uptime显示平均负载到2.93，并且%sys负载率达到48.44%，%iowait也达到了20.4%
使用pidstat -u 5 1发现还是stress造成的
场景三：模拟大量进程场景
步骤一：使用stress模拟8个进程
tress -c 8 -t 600
uptime：因为只有4个核心，所以负载率上升非常快
mpstat显示4个核心占用率接近100%
pidstat显示CPU实际只使用了%cpu:50%来处理进程，剩下的%wait:50%一直在等待
总结
平均负载方便我们及时对系统进行评估，但是单纯的观察平均负载并不能让我们仔细分辨出到底是什么原因造成的过高？
此时我们需要借助工具mpstat和pidstat进行分析，分析到底是CPU进行了密集计算或者是磁盘I/O不足造成的负载过高。
应在平均负载在70%（不是绝对）的时候开始排查，排查需要过程，并且排查的过程中负载会一直在增加
此篇文章涉及的命令：
mpstat -P -ALL 5pidstat -u 5 1
更多功能请使用man pidstat查看。
写文章不易，如果此篇文章能帮助你，欢迎点赞、收藏并关注我！
