一、CPU上下文切换测试场景

使用sysbench模拟多线程调度：

sysbench --threads=10 --time=300 threads run

使用vmstat查看CPU上下文切换：

cs列上下文切换次数超过150万次。

r列就绪队列长度最大达到8，超过系统CPU的个数4，存在大量的CPU竞争。

sy列超过70%，说明CPU主要是被内核占用。

in列中断次数上升到40000以上，说明中断处理也是个潜在的问题。

系统就绪队列过长，即正在运行和等待CPU的进程数过多，导致大量的上下文切换，而上下文切换又导致了系统 CPU 的占用率升高。

使用pidstat -wt 3查看具体线程：

sysbench线程的cswch超过40000，nvcswch超过100000。

观察CPU的中断使用情况：

watch -d cat /proc/interrupts

重调度中断（RES）超过400万次，用于唤醒空闲状态的CPU来调度新的任务运行。多处理器系统（SMP）中，处理器间中断（Inter-Processor Interrupts，IPI）用来分散任务到不同CPU的机制。

二、CPU平均负载测试场景

1、CPU密集型进程

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

stress --cpu 1 --timeout 600

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

watch -d uptime

在第三个终端运行mpstat查看CPU使用率的变化情况。

mpstat -P ALL 5

监控所有CPU，每隔5秒输出一次。

第二个终端uptime监控的1分钟的平均负载会缓慢增加到1.21。

第三个终端中CPU3的使用率为96%，但相应iowait只有0，平均负载的升高是由于CPU使用率为100%。

第四个终端运行pidstat查看进程的CPU使用率，发现stress进程的CPU使用率为100%。

pidstat -u 5 1

2、IO密集型进程

第一个终端运行stress命令，模拟一个IO密集型进程。

stress -i 1 --hdd 1 --timeout 600

第二个终端运行uptime查看平均负载的变化情况。

watch -d uptime

第三个终端运行mpstat查看CPU使用率的变化情况。

mpstat -P ALL 5

第四个终端运行pidstat查看进程的CPU使用率，发现stress进程的CPU使用率相对比较高。

pidstat -u 5 1

3、等待CPU进程

当系统中运行进程超出CPU运行能力时，就会出现等待CPU的进程。

第一个终端运行stress命令，模拟10个进程的场景。

stress -c 10 --timeout 600

由于系统只有4个逻辑CPU，比10个进程要少得多，因而，系统的CPU处于严重过载状态，平均负载高达9.96。

mpstat查看CPU使用率都接近100%。

10个进程争抢4个逻辑CPU，每个进程等待CPU时间（%wait 列）高达60%，严重超出CPU计算能力，最终导致CPU过载。

三、CPU使用率测试场景

1、开启多线程压力测试

sysbench --threads=8 --time=600 cpu run

使用sysbench开启8线程压力测试，持续时间600秒

2、实时分析

sudo perf top -g -p 30388

实时分析sysbench进程30388的性能

选择sysbench，按ENTER键。

选择CPU使用率最大的cpu_execute_eventh函数，按ENTER键进入查看。

选择Annotate cpu_execute_event按ENTER键进入，查看函数内部调用所占CPU。

从cpu_excute_event函数调用看，取模运算占用CPU使用率高达70%以上。

3、离线分析

perf record -g -p 28068

采样sysbench进程性能数据

perf report

解析性能数据