一、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解析性能数据
