该怎么理解”平均负载”
平均负载多少时合理
CPU 密集型进程，大量 CPU 使用会导致平均负载升高，此时两者一致 I/O 密集型进程，等待 I/O 也会导致平均负载升高，此时 CPU 使用率并不一定高 大量等待 CPU 的进程调度会导致平均负载升高，此时 CPU 使用率也会比较高
CPU
CPU上下文切换(上)
按照任务类型，CPU 上下文切换分为：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.html
- 进程上下文切换
- 线程上下文切换
- 中断上下文切换
进程上下文切换
Linux 进程按照等级权限将进程的运行空间分为内核空间和用户空间。从用户态向内核态转变时需要通过系统调用来完成。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.html
一次系统调用过程其实进行了两次 CPU 上下文切换：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.html
- CPU 寄存器中用户态的指令位置先保存起来，CPU 寄存器更新为内核态指令的位置，跳转到内核态运行内核任务；
- 系统调用结束后，CPU 寄存器恢复原来保存的用户态数据，再切换到用户空间继续运行。
系统调用过程中并不会涉及虚拟内存等进程用户态资源，也不会切换进程。和传统意义上的进程上下文切换不同。因此系统调用通常称为特权模式切换。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.html
进程是由内核管理和调度的，进程上下文切换只能发生在内核态。因此相比系统调用来说，在保存当前进程的内核状态和CPU寄存器之前，需要先把该进程的虚拟内存，栈保存下来。再加载新进程的内核态后，还要刷新进程的虚拟内存和用户栈。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.html
进程只有在调度到CPU上运行时才需要切换上下文，有以下几种场景：CPU时间片轮流分配，系统资源不足导致进程挂起，进程通过sleep函数主动挂起，高优先级进程抢占时间片，硬件中断时CPU上的进程被挂起转而执行内核中的中断服务。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.html
线程上下文切换
线程上下文切换分为两种：文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.html
- 前后线程同属于一个进程，切换时虚拟内存资源不变，只需要切换线程的私有数据，寄存器等；
- 前后线程属于不同进程，与进程上下文切换相同。
同进程的线程切换消耗资源较少，这也是多线程的优势。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.html
中断上下文切换
中断上下文切换并不涉及到进程的用户态，因此中断上下文只包括内核态中断服务程序执行所必须的状态（CPU寄存器，内核堆栈，硬件中断参数等）。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.html
中断处理优先级比进程高，所以中断上下文切换和进程上下文切换不会同时发生文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.html
CPU上下文切换(下)
通过 vmstat 可以查看系统总体的上下文切换情况文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.htmlvmstat 5 #每隔5s输出一组数据procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 103388 145412 511056 0 0 18 60 1 1 2 1 96 0 0 0 0 0 103388 145412 511076 0 0 0 2 450 1176 1 1 99 0 0 0 0 0 103388 145412 511076 0 0 0 8 429 1135 1 1 98 0 0 0 0 0 103388 145412 511076 0 0 0 0 431 1132 1 1 98 0 0 0 0 0 103388 145412 511076 0 0 0 10 467 1195 1 1 98 0 0 1 0 0 103388 145412 511076 0 0 0 2 426 1139 1 0 99 0 0 4 0 0 95184 145412 511108 0 0 0 74 500 1228 4 1 94 0 0 0 0 0 103512 145416 511076 0 0 0 455 723 1573 12 3 83 2 0
- cs （context switch） 每秒上下文切换次数
- in （interrupt） 每秒中断次数
- r （runnning or runnable）就绪队列的长度，正在运行和等待CPU的进程数
- b （Blocked） 处于不可中断睡眠状态的进程数
要查看每个进程的详细情况，需要使用pidstat来查看每个进程上下文切换情况文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.htmlpidstat -w 514时51分16秒 UID PID cswch/s nvcswch/s Command14时51分21秒 0 1 0.80 0.00 systemd14时51分21秒 0 6 1.40 0.00 ksoftirqd/014时51分21秒 0 9 32.67 0.00 rcu_sched14时51分21秒 0 11 0.40 0.00 watchdog/014时51分21秒 0 32 0.20 0.00 khugepaged14时51分21秒 0 271 0.20 0.00 jbd2/vda1-814时51分21秒 0 1332 0.20 0.00 argusagent14时51分21秒 0 5265 10.02 0.00 AliSecGuard14时51分21秒 0 7439 7.82 0.00 kworker/0:214时51分21秒 0 7906 0.20 0.00 pidstat14时51分21秒 0 8346 0.20 0.00 sshd14时51分21秒 0 20654 9.82 0.00 AliYunDun14时51分21秒 0 25766 0.20 0.00 kworker/u2:114时51分21秒 0 28603 1.00 0.00 python3
- cswch 每秒自愿上下文切换次数（进程无法获取所需资源导致的上下文切换）
- nvcswch 每秒非自愿上下文切换次数（时间片轮流等系统强制调度）
vmstat 1 1 #新终端观察上下文切换情况此时发现cs数据明显升高，同时观察其他指标：r列：远超系统CPU个数，说明存在大量CPU竞争us和sy列：sy列占比80%，说明CPU主要被内核占用in列：中断次数明显上升，说明中断处理也是潜在问题
pidstat -w -u 1 #查看到底哪个进程导致的问题从结果中看出是 sysbench 导致 CPU 使用率过高，但是 pidstat 输出的上下文次数加起来也并不多。分析 sysbench 模拟的是线程的切换，因此需要在 pidstat 后加 -t 参数查看线程指标。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.htmlwatch -d cat /proc/interrupts
发现次数变化速度最快的是重调度中断（RES），该中断用来唤醒空闲状态的CPU来调度新的任务运行。分析还是因为过多任务的调度问题，和上下文切换分析一致。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/30925.html