性能：如何优化一个系统的性能（总结）

性能的目标

从应用负载方面来看，系统应该做到：

• 高并发
• 低延迟

从系统资源方面来看：

• 资源使用率
• 饱和度

如何优化

系统响应变慢了，可以从CPU、内存、磁盘、网络四个维度来分析

第一步，先来看系统整体资源使用情况

（1）相关命令

• top命令可以查看CPU平均负载、系统任务情况、每个CPU的使用率、内存使用率
• df命令可以查询文件系统的使用情况：
  • df -h的%usr可以查看整体的文件系统使用情况；如果正常，那么用df -i查询是不是大量的小文件引起的

（2）举个例子：

# 按下数字 1 切换到所有 CPU 的使⽤情况，观察⼀会⼉按 Ctrl+C 结束
$ top
top - 05:56:23 up 17 days, 16:45, 2 users, load average: 2.00, 1.68, 1.39
Tasks: 247 total, 1 running, 79 sleeping, 0 stopped, 115 zombie
%Cpu0 : 0.0 us, 0.7 sy, 0.0 ni, 38.9 id, 60.5 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 0.0 us, 0.7 sy, 0.0 ni, 4.7 id, 94.6 wa, 0.0 hi, 0.0 si, 0.0 st
---
KiB Mem : 8169348 total, 6871440 free, 267096 used, 1030812 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7607492 avail Mem
...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4340 root 20 0 44676 4048 3432 R 0.3 0.0 0:00.05 top
4345 root 20 0 37280 33624 860 D 0.3 0.0 0:00.01 app
4344 root 20 0 37280 33624 860 D 0.3 0.4 0:00.01 app
1 root 20 0 160072 9416 6752 S 0.0 0.1 0:38.59 systemd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

• 第一行是平均负载，主要关注两点：
  • （1）趋势：正常情况下趋势应该是平稳的
  • （2）取值，正常情况下取值和CPU个数相同，如果取值超过CPU个数70%那么需要调试
• 第二行是任务情况，主要关注两点：
  • （1）有多少个运行的进程，正常取值应该小于等于CPU个数（如果个数超过CPU个数，那么会有大量进程切换导致CPU升高）
  • （2）有多少个僵尸进程，正常取值应该是0，如果非0，说明有子进程没有被清理，这样可能导致资源耗尽
• 第三行是每个CPU的使用率
  • （1）主要关注四个方面：用户CPU使用率（us、ni）、内核CPU使用率（sy）、等待IO的CPU使用率（wa）、中断CPU使用率
    • 用户CPU使用率（用户态CPU使用率%usr、低优先级CPU使用率%nice）太高，说明应用程序比较繁忙
    • 内核CPU使用率（%sys）太高，说明内核调度比较繁忙
    • 等待IO即(iowait)太高，说明系统频繁和硬件设备打交道
    • 软中断和硬中断CPU太高，说明发生了大量的中断
  • （2）CPU使用率异常分三种情况（可能需要计算出每一个CPU的整体使用率）
    • 某个CPU的使用率远远高于其他CPU使用率。又分为两种情况：
      • iowait高而其他低，那么就是因为IO密集型任务引起的，需要查看进行的IO使用情况
      • iowait低而sys高，那么可能是因为CPU密集型任务，接下来的排除方向是进程的CPU使用
    • 如果所有CPU的使用率都将近打满，那么可能是因为大量进程切换导致的
    • 如果所有CPU的使用率很低（小于%10），有可能是因为中断比较多导致的，实际情况中，如果是中断引起的，那么基本上都是因为网络接收的软中断引起的
• 第四行是系统内存的整体使用情况（这个我不怎么关注，对于内存，会使用另外的工具)
  • 有两行：总物理内存Mem和交换分区Swap
  • 有5列，包括total总内存大小、free未使用内存大小、used已用内存大小、buff/cache缓存和缓冲区大小
    • Buffer是对磁盘数据的缓存，而Cache是对文件数据的缓存。
    • 在读写普通文件时，会经过文件系统，由文件系统负责和磁盘交互；而读写磁盘或者分区时，会跳过文件系统，也就是所谓的“裸IO”
• 最后注意：指标太多了，应该找到最可疑的，不要纠结细节

第二步：如果确定是CPU异常

（1）CPU平均负载出问题了

• 表现形式：超载
• 可能原因有三个：
  • CPU密集型(%usr)应用导致某个CPU超载
  • IO太过繁忙（%sys）缓冲区频繁刷新导致某个CPU超载
  • 进程太多大量切换也会导致CPU升高，则是所有的CPU的使用率都会接近满载
• 如果需要调试，那么：
  • 先使用mpstat -P ALL监控所有CPU
  • 然后使用pidstat查看所有进程，找出到底是哪个进程的什么行为导致了CPU超载（即CPU的使用率（%CPU））
    • 先竖着看，找出%cpu最高的哪一行
    • 然后横着看，看到时是因为%usr、%system等引起%CPU升高的

（2）CPU的使用率出问题：

• 分析到底是 IO密集型线程引起的、还是CPU密集型线程引起的、还是进程太多切换引起的
• 然后具体类型具体分析

（3）CPU上下文切换出问题了（任务异常）

• top查看就绪队列长度：
  • running任务个数远远超过了系统CPU的个数，那么会有大量的CPU竞争，导致大量上下文切换
  • 如果某个CPU的%sys远高于其他
    • 那么可能是一个进程里有很多个线程在争抢CPU
    • 此时就绪队列也是异常的，因为上下文切换需要系统调度
  • 如果所有CPU的使用率都上去了，那么基本上是多个进程争抢CPU
• 可以使用vmstat查看每秒上下文切换次数：
  • 数值是正确的呢？这取决于系统性能。所以我们应该关注趋势
    • 如果系统的上下文切换次数比较稳定，那么应该是正常的；
    • 如果出现指数级异常增长，那么说明异常
• 还需要使用pidstat -wt查看每个进程的CPU使用率情况以及每个进程、线程（linux调度的基本单位实现上是线程）的自愿（ cswch/s）和非自愿上下文切换次数（ cswch/s）。
  • 如果某个进程的CPU使用率远远高于其他进程，那么说明它是可疑的
  • 自愿上下文切换变多了，说明进程都在等待资源，有可能已经发生了IO等其他问题
  • ⾮⾃愿上下⽂切换变多了，说明进程都在被强制调度，也就是都在争抢 CPU，说明 CPU 的确成了瓶颈

（4）CPU中断出问题了

• （%hi为irq处理程序的CPU时间，si为软中断的处理时间）
• 原因：
  • 中断只发生在内核态
  • 中断次数变多了，说明 CPU 被中断处理程序占⽤，还需要通过查看 /proc/interrupts ⽂件来分析具体的中断类型

（5）CPU缓存命中率出问题了