CPU理论，平均负载和CPU密集型场景

一. CPU理论知识点

二. 进程和线程

1. 什么是进程？

进程是正在进行的一个过程或者说一个任务，而负责执行任务的是CPU

2. 什么是线程？

线程是进程里面执行的最小单元，例如：一条流水线工作的过程（流水线的工作需要电源，电源就相当于CPU），而一条流水线必须属于一个车间，一个车间的工作过程就是一个进程，车间负责把资源整合到一起，是一个资源单元，而一个车间内至少有一条流水线

注意：

(1) LoadRunner中既有进程，又有线程

一般的HTTP协议：使用线程跑

java vuser协议：使用进程跑，要不然会出现失败或者压力上不去

(2) jmeter中只有线程

3. 进程与线程的区别

(1) 同一个进程内的多个线程共享该进程内的地址资源

(2) 创建线程的开销要远小于创建进程的开销（创建一个进程，就是创建一个车间，涉及到申请空间，而且在该空间内至少建一条流水线，但创建线程，就只是车间内建一条流水线，不需要申请空间，所以创建开销小）

三. CPU

1. 什么是CPU？

CPU就像人的大脑，主要负责相关事情的判断以及实际处理的机制

2. 查看命令

查看CPU的配置信息

cat /proc/cpuinfo   #查看CPU的配置信息

查看物理CPU的个数

cat /proc/cpuinfo | grep "physical id" | sort | uniq | wc -l   #sort：排序，uniq去重，wc -l 统计数量

查看每个物理CPU中core的个数（核数）

cat /proc/cpuinfo | grep "cpu cores" | uniq

查看逻辑CPU的个数

cat /proc/cpuinfo | grep "processor" | wc -l

逻辑CPU的个数/总核数 = 物理CPU的个数 x 每个物理CPU的核数

3. CPU架构

从处理器层面进行查看，从操作系统层面查看

四. 平均负载

在做性能测试的时候，发现响应时间越来越慢，或者功能测试的点点点，发现系统没有响应，我们通常做的第一件事，就是执行top或者uptime命令，来看系统的负载情况

1. uptime

这些输出是什么含义？最后这三个数字（重要）：load average：0.00，0.01，0.05，依次表示：过去1分钟，5分钟，15分钟的平均负载（load average）

2. 平均负载

平均负载指的是单位时间内，系统处于可运行状态和不可中断的平均进程数，也就是平均活跃进程数，它和CPU的使用率并没有直接关系

可运行状态的进程是指正在使用CPU或者正在等待CPU的进程，也就是我们常用ps命令看到的进程

不可中断的进程是指处于内核状态关键流程中的进程，并且这些流程是不可打断的，比如最常见的等待硬件设备的I/O响应，可以通过top命令看到的状态（sleeping）。比如当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或中断打断的。所以不可中断状态实际上是系统对进程和硬件设施的一种保护机制

因此，可以简单理解为：平均负载就是平均活跃的进程数。平均活跃的进程数，直观上的理解就是单位时间内的活跃进程数

3. 平均负载的理想状态

每个CPU上刚好运行着一个进程，这样每个CPU都得到了充分利用，比如当平均负载为2时，意味着在只有2个CPU的系统上面，所有的CPU刚好被完全占用；在4个CPU的系统上面，CPU还有50%的空闲；在只有1个CPU的系统上面，有一半的进程竞争不到CPU

4. 在做性能测试的时候，平均负载为多少时合理？在uptime命令里，这三个时间段的平均负载数，多大时说明系统负载高？

load average：0.00，0.01，0.05

(1) 首先要知道有几个CPU

(2) 有了CPU个数，可以做出判断：当平均负载比CPU个数大时，系统出现了负载

那么这三个值（0.00，0.01，0.05），以哪个为参考？

实际上三个都要看，三个负载有什么参考意义呢？

如果1分钟，5分钟，15分钟的三个值基本相同或者相差不大，说明系统负载很平稳

如果1分钟的值远小于15分钟的值，说明系统最近1分钟的负载在减小，而过去15分钟内有很大的负载

反过来，如果1分钟的值远大于15分钟，说明系统最近1分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以需要持续观察

一旦1分钟的平均负载接近或超过CPU的个数，意味着系统正在发生过载的问题，需要分析哪里导致的

比如：在一个单CPU系统上面看到负载为1.73，0.60，7.98，那么说明在过去1分钟，系统有73%的负载，而在15分钟内，有698%的负载，从整体趋势来看，系统的负载在降低

5. 在实际生产环境中，平均负载多高时，就需要关注？

当平均负载超过CPU的70%的时候，就要进行分析排查负载过高的问题了，一旦负载过高，就可能导致进程响应变慢，影响服务的正常功能

6. 平均负载和CPU使用率：平均负载高了，是不是以为着CPU使用率也高了？

不一定。还是回到平均负载的含义上来：平均负载指的是单位时间内，处于可运行状态和不可中断状态的进程数，所以，它不仅包括了正在使用CPU的进程，还包括等待CPU和等待I/O的进程

五. 平均负载案例分析

三个不同的示例（CPU密集型进程，I/O密集型进程，大量等待CPU的进程），并用（iostat，mpstat，pidstat），找出平均负载升高的根源

1. 准备工作：预先安装stress和sysstat

stress是一个Linux系统压力测试工具

sysstat包含了常用的多核CPU性能工具，用来监控和分析系统的性能，包括了mpstat、pidstat、iostat、sar、sadf等

　　mpstat是一个常用的多核CPU性能分析工具，用来实时查看每个CPU的性能指标以及所有CPU的平均指标

　　pidstat是一个常用的进程性能分析工具，用来实时查看进程的CPU，内存，I/O以及上下文切换等性能指标

(1) 安装stress

yum install -y epel-release   #epel-release，这个软件包会自动配置yum的软件仓库。当然你也可以不安装这个包，自己配置软件仓库也是一样的
yum install -y stress

(2) 通过sz命令将sysstat-12.1.5.tar.gz上传到/opt目录下

cd /opt
tar -zxvf sysstat-12.1.5.tar.gz
cd sysstat-12.1.5
./configure
make
make install

2. 场景一：CPU密集型进程

(1) 在第一个终端运行stress命令，模拟一个CPU使用率100%的场景

stress --cpu 1 --timeout 600   #600，表示运行600s，也就是10分钟。对一个cpu进行压力测试，timeout就是要执行多长时间

(2) 在第二个终端运行uptime查看平均负载的变化情况

#直接输入uptime，只出现一次。要动态变化需要使用watch -d uptime
watch -d uptime   # -d：表示高亮显示变化的区域

(3) 在第三个终端运行mpstat查看CPU使用率变化情况

#-P ALL：表示监听所有的CPU，后面数字5表示间隔5秒更新一组数据
mpstat -P ALL 5

CPU：逻辑CPU ID，或者all表示总信息

%usr：用户态占用的比例

%nice：以nice优先级运行的进程用户态时间

%sys：系统时间（内核占用CPU的比例）

%iowait：I/O等待

%irq：硬件中断CPU的比例

%soft：软件中断CPU的比例

%steal：耗费在服务其他用户的时间

%guest：花在访客虚拟机的时间

%gnice

%idle：空闲的CPU时间

从终端二种可以看到，1分钟的平均负载会慢慢增加到1.00，从终端三中还可以看到，正好有一个CPU的使用率为100%，但它的iowait只有0。这说明：平均负载的升高正是由于CPU使用率为100%导致的

(4) 定位：是哪一个进程导致了CPU使用率为100%？

# -u：每隔5s后输出一组数据
pidstat -u 5 1

可以看到，stress进程的CPU使用率为100%