- uptime命令查看1 5 15分钟的负载情况，如果相差不大说明系统负载平稳，1分钟远大于15分钟说明最近一分钟负载很高
- lscpu：查看cpu信息
- 假设我们在一个单 CPU 系统上看到平均负载为 1.73，0.60，7.98，那么说明在过去 1 分钟内，系统有 73% 的超载，而在 15 分钟内，有 698% 的超载，从整体趋势来看，系统的负载在降低。
- 平均负载高于70%时就不好了
- 平均负载案例：安装stress和sysstat
- stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。
- 而 sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。
- mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有CPU的平均指标。
- pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。
- 安装两个性能测试工具
apt install stress sysstat
- 给一个cpu模拟100%负载
stress --cpu 1 --timeout 600
- -d 参数表示高亮显示变化的区域
watch -d uptime
- -P ALL 表示监控所有CPU，后面数字5表示间隔5秒后输出一组数据
mpstat -P ALL 5
- 到底是哪个进程导致了 CPU 使用率为 100% 呢？你可以使用 pidstat 来查询：
- 间隔5秒后输出一组数据
pidstat -u 5 1
总结：
平均负载高有可能是 CPU 密集型进程导致的；
平均负载高并不一定代表 CPU 使用率高，还有可能是 I/O 更繁忙了；
当发现负载高的时候，你可以使用 mpstat、pidstat 等工具，辅助分析负载的来源。
cpu核数: lscpu、 grep ‘model name’ /proc/cpuinfo | wc -l
显示平均负载：uptime、top，显示的顺序是最近1分钟、5分钟、15分钟，从此可以看出平均负载的趋势。
watch -d uptime: -d会高亮显示变化的区域。
strees: 压测命令，–cpu cpu压测选项，-i io压测选项，-c 进程数压测选项，–timeout 执行时间。
mpstat: 多核cpu性能分析工具，-P ALL监视所有cpu。
pidstat: 进程性能分析工具，-u 显示cpu利用率。
- 还是建议用top和ps或者lsof来分析，因为一般线上的机器不会额外安装这之外的工具，而且很多公司用堡垒机登录上去之后其他的基本上都用不了，用其自带的最保险
CPU上下文切换
- 进程上下文切换，线程上下文切换，中断上下文切换
- 同一个进程的线程上下文切换海星
vmstat 5
-
cs（context switch）是每秒上下文切换的次数。
-
in（interrupt）则是每秒中断的次数。
-
r（Running or Runnable）是就绪队列的长度，也就是正在运行和等待CPU的进程数。
-
b（Blocked）则是处于不可中断睡眠状态的进程数。
-
所谓自愿上下文切换，是指进程无法获取所需资源，导致的上下文切换。比如说， I/O、内存等系统资源不足时，就会发生自愿上下文切换。
-
而非自愿上下文切换，则是指进程由于时间片已到等原因，被系统强制调度，进而发生的上下文切换。比如说，大量进程都在争抢 CPU 时，就容易发生非自愿上下文切换。
-
sysbench来模拟系统多线程调度切换的情况
自愿上下文切换变多了，说明进程都在等待资源，有可能发生了 I/O 等其他问题；
非自愿上下文切换变多了，说明进程都在被强制调度，也就是都在争抢 CPU，说明 CPU 的确成了瓶颈；
中断次数变多了，说明 CPU 被中断处理程序占用，还需要通过查看 /proc/interrupts 文件来分析具体的中断类型。
某个应用使用率达到了100%该怎么办
- execsnoop可以用来监控短时动态的性能问题
- 碰到常规问题无法解释的 CPU 使用率情况时，首先要想到有可能是短时应用导致的问题，比如有可能是下面这两种情况。
- 第一，应用里直接调用了其他二进制程序，这些程序通常运行时间比较短，通过 top 等工具也不容易发现。
- 第二，应用本身在不停地崩溃重启，而启动过程的资源初始化，很可能会占用相当多的 CPU。
- 对于这类进程，我们可以用 pstree 或者 e xecsnoop 找到它们的父进程，再从父进程所在的应用入手，排查问题的根源。
