从入门到转型之Linux性能优化实践学习指南

全栈工程师修炼指南

发布于 2022-09-29 15:55:47

5480

发布于 2022-09-29 15:55:47

文章被收录于专栏：全栈工程师修炼之路

[TOC]

0x00 前言简述

本系列是从入门到转型之Linux性能优化实践学习指南,是博主学习Linux性能优化之路的精华版本，我将分享大量性能优化的思路和方法，并进行相应工具使用介绍和总结。

做过开发运维的工作应该知道, 性能优化一直都是大多数软件工程师头上的“紧箍咒”。

Q: 性能问题为什么这么难呢？

答: 我觉得主要是因为性能优化是个系统工程，总是牵一发而动全身。它涉及了从程序设计、算法分析、编程语言，再到系统、存储、网络等各种底层基础设施的方方面面。每一个组件都有可能出问题，而且很有可能多个组件同时出问题。所以: 性能问题往往是跟系统原理关联起来，特别是把系统从应用程序、库函数、系统调用、再到内核和硬件等不同的层级贯穿起来。

毫无疑问，性能优化是软件系统中最有挑战的工作之一，但是换个角度看，它也是最考验体现你综合能力的工作之一。

Q: 那我们究竟如何学习Linux性能优化？

在不断的实践和总结后，我终于知道最好的学习方式一定是带着问题学习。

即学习要会抓重点。其实只要你了解少数几个系统组件的基本原理和协作方式，掌握基本的性能指标和工具，学会实际工作中性能优化的常用技巧，你就已经可以准确分析和优化大多数的性能问题了。在这个认知的基础上，再反过来去阅读那些经典的操作系统或者其它图书，他将事半功倍。
即从资源使用的视角出发，带你分析各种 Linux 资源可能会碰到的性能问题，包括 CPU 性能、磁盘 I/O 性能、内存性能以及网络性能。

其实，性能问题并没有你想像得那么难，只要你理解了应用程序和系统的少数几个基本原理，再进行大量的实战练习，建立起整体性能的全局观，大多数性能问题的优化就会水到渠成。

有得DevOps工程师大佬，在分析应用程序所使用的第三方组件的性能时，并不熟悉这些组件所用的编程语言，却依然可以分析出线上问题的根源，并能通过一些方法进行优化，比如修改应用程序对它们的调用逻辑，或者调整组件的配置选项等。还是那句话你不需要了解每个组件的所有实现细节，只要能理解它们最基本的工作原理和协作方式，你也可以做到。

Q: 性能指标是什么？

答: 我相信“高并发”和“响应快”一定是最先出现在你脑海里的两个词，而它们也正对应着性能优化的两个核心指标——“吞吐”和“延时”。这两个指标是从应用负载的视角来考察性能，直接影响了产品终端的用户体验。跟它们对应的是从系统资源的视角出发的指标，比如资源使用率、饱和度等。

WeiyiGeek.应用负载与系统资源视角(电梯原理)

随着应用负载的增加，系统资源的使用也会升高，甚至达到极限。

实际上性能问题的本质，就是系统资源已经达到瓶颈，但请求的处理却还不够快，无法支撑更多的请求。

Q: 性能分析是什么? 描述: 其实就是找出应用或系统的瓶颈，并设法去避免或者缓解它们，从而更高效地利用系统资源处理更多的请求。通常是包含了一系列的步骤，例如下六个步骤:

选择指标评估应用程序和系统的性能；
为应用程序和系统设置性能目标；
进行性能基准测试；
性能分析定位瓶颈；
优化系统和应用程序；
性能监控和告警。

Tips: 性能相关的基本指标和核心步骤。

Q: 性能优化学习的重点是什么?

描述: 如果想要学习好性能分析和优化，建立整体系统性能的全局观是最核心的话题。因而，理解最基本的几个系统知识原理；掌握必要的性能工具；通过实际的场景演练，贯穿不同的组件。

Q: 怎么学更高效？ 描述: 前面讲解了 Linux 性能优化的学习重点，接下来我再跟你分享一下几个学习技巧：

技巧一：虽然系统的原理很重要，但在刚开始一定不要试图抓住所有的实现细节。你可以先学会我给你讲的这些系统工作原理，但不要去深究 Linux 内核是如何做到的，而是要把你的重点放到如何观察和运用这些原理上，
- 比如：有哪些指标可以衡量性能？指标，比如是内存还是CPU，亦或者io
- 使用什么样的性能工具来观察指标？比如io可以使用iostat 内存可以用mpstat
- 导致这些指标变化的因素等。比如io阻塞出现的问题有：读取小文件过多，网络阻塞，长连接过多等
技巧二：边学边实践，通过大量的案例演习掌握 Linux 性能的分析和优化。
技巧三：勤思考，多反思，善总结，多问为什么。想真正学懂一门知识，最好的方法就是问问题。当你能提出好的问题时，就说明你已经深入了解了它。

前面说到性能工具就不得不提到性能领域的大师布伦丹·格雷格（Brendan Gregg）, 其个人博客主页(http://www.brendangregg.com)国内可访,他不仅是动态追踪工具 DTrace 的作者，还开发了许许多多的性能工具, 我相信你一定见过他所描绘的 Linux 性能工具图谱：

WeiyiGeek.Linux 性能工具图谱

该图是 Linux 性能分析最重要的参考资料之一，它告诉你，在 Linux 不同子系统出现性能问题后，应该用什么样的工具来观测和分析。比如，当遇到 I/O 性能问题时，可以参考图片最下方的 I/O 子系统，使用 iostat、iotop、blktrace 等工具分析磁盘 I/O 的瓶颈

另外，我还要特别强调一点，就是性能工具的选用。有句话是这么说的，一个正确的选择胜过千百次的努力。虽然夸张了些，但是选用合适的性能工具，确实可以大大简化整个性能优化过程。在什么场景选用什么样的工具、以及怎么学会选择合适工具，都是我想教给你的东西。

但是切记，千万不要把性能工具当成学习的全部。工具只是解决问题的手段，关键在于你的用法。只有真正理解了它们背后的原理，并且结合具体场景，融会贯通系统的不同组件，你才能真正掌握它们。

WeiyiGeek.Linux性能优化学习路径

六步总结: 从正确的角度出发，设定目标（性能优化不是漫无目的的），基准测试（了解现有系统应用的运行时情况），根据情况分析瓶颈，优化它，设置监控和告警（其实可以再扩展比如达到一定的负载，采取降级等操作）

说一说你在日常生活中遇到的系统程序异常时排查流程 通常排查流程如下: 监控平台(Grafana+Prometheus) -> 预警信息(AlertManager) -> 应用状态确认 -> 应用部署的系统(Linux) -> CPU使用率(top/htop) -> 内存使用率(free) -> 磁盘使用率(iostat) -> 网络吞吐(iftop) -> 应用进程Heap与Stack调用(jps/) -> 第三方外部系统(比如数据库、缓存、存储等)

激励Buff: “想要得到你就要学会付出，要付出还要坚持；如果你真的觉得很难，那你就放弃，如果你放弃了就不要抱怨。人生就是这样，世界是平衡的，每个人都是通过自己的努力，去决定自己生活的样子。”

0x01 CPU 性能篇

1.平均负载

系统的负载情况可执行 top 或者 uptime 命令来查看。

比如像下面这样，我在命令行里输入了 uptime 命令，系统也随即给出了结果。

$ uptime
  # 02:34:03 up 2 days, 20:14,  1 user,  load average: 0.63, 0.83, 0.88
02:34:03              # 当前时间
up 2 days, 20:14      # 系统运行时间
1 user                # 正在登录用户数
load average: 0.63, 0.83, 0.88  # 依次则是过去 1 分钟、5 分钟、15 分钟的平均负载（Load Average）。

1.1 基础概念

Q: 什么是平均负载(Load Average)吗？

答: 平均负载是最常见、也是最重要的系统指标，但你真正的了解它吗，在博主在当时学习它时候也是一头雾水。我猜一定有人会说，平均负载不就是单位时间内的 CPU 使用率吗？上面的 0.63，就代表 CPU 使用率是 63%。其实并不是这样，如果你方便的话，可以通过执行 man uptime 命令，来了解平均负载的详细解释。

简单来说，平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。

(1) 可运行状态的进程: 是指正在使用 CPU (处在【运行态】)或者正在等待 CPU (【就绪态】)的进程，也就是我们常用 ps 命令看到的，处于 R 状态（Running 或 Runnable）的进程。
(2) 不可中断状态的进程 : 则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 ps 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

简单理解为，平均负载其实就是平均活跃进程数(是被消耗掉的cpu个数)。平均活跃进程数，直观上的理解就是单位时间内的活跃进程数，但它实际上是活跃进程数的指数衰减平均值。

Tips: 这个“指数衰减平均”的详细含义你不用计较，这只是系统的一种更快速的计算方式，你把它直接当成活跃进程数的平均值也没问题。

Tips: 平均负载的理想情况，每个CPU上运行一个进程，这样每个 CPU 都得到了充分利用。

比如.当平均负载为 2 时，意味着什么呢？

在只有 2 个 CPU 的系统上，意味着所有的 CPU 都刚好被完全占用。
在 4 个 CPU 的系统上，意味着 CPU 有 50% 的空闲。
而在只有 1 个 CPU 的系统中，则意味着有一半的进程竞争不到 CPU。

例如,前面1分钟、5分钟、15分钟三个不同时间间隔的平均负载值有何作用。 实际上它给我们提供了，分析系统负载趋势的数据来源，让我们能更全面、更立体地理解目前的负载状况。

打个比方，就像初秋时北京的天气，如果只看中午的温度，你可能以为还在 7 月份的大夏天呢。但如果你结合了早上、中午、晚上三个时间点的温度来看，基本就可以全方位了解这一天的天气情况了。

同样的，前面说到的 CPU 的三个负载时间段也是这个道理。
如果 1 分钟、5 分钟、15 分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。
但如果 1 分钟的值远小于 15 分钟的值，就说明系统最近 1 分钟的负载在减少，而过去 15 分钟内却有很大的负载。反过来，如果 1 分钟的值远大于 15 分钟的值，就说明最近 1 分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦 1 分钟的平均负载接近或超过了 CPU 的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了。

再举个例子，假设我们在一个单 CPU 系统上看到平均负载为 1.73，0.60，7.98，那么说明在过去 1 分钟内，系统有 73% 的超载，而在 15 分钟内，有 698% 的超载，从整体趋势来看，系统的负载在降低。

Q: 平均负载为多少时是合理?

首先,你要知道系统有几个 CPU，这可以通过 nproc 命令 或 top 命令(按1) 或者从文件 /proc/cpuinfo 中读取，比如：grep 'model name' /proc/cpuinfo | wc -l
其次，当平均负载高于 CPU 数量 70% 的时候，当然这并不是绝对的最推荐的方法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势。

Q: 平均负载与 CPU 使用率的区别 描述: 可能你会疑惑，既然平均负载代表的是活跃进程数，那平均负载高了，不就意味着 CPU 使用率高吗？平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。所以，它不仅包括了正在使用 CPU 的进程，还包括等待 CPU 和等待 I/O 的进程(【等待IO】是【处于不可中断状态的进程】)。

而 CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。比如：

CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。

Tips: 一句话表明CPU负载高不代表使用率高，还有可能等待IO线程导致。

1.2 案例分析

此处我们需要准备一台Linux系统，我准备是 Ubuntu 20.04 后续案例都是基于此系统进行。

环境工具准备:

虚拟机 Ubuntu 20.04 , 4CPU , 8GB内存
预先安装 stress 和 sysstat 包，如 apt install -y stress sysstat。

stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。 sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能，此处使用到是 mpstat 和 pidstat两个命令。

mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

此外，每个场景都需要你开三个终端，登录到同一台 Linux 机器中。

场景一：CPU 密集型进程

# 1.首先，我们在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景：
$ stress --cpu 1 --timeout 600
  stress: info: [13476] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

# 2.接着，在第二个终端运行 uptime 查看平均负载的变化情况：
# -d 参数表示高亮显示变化的区域
$ watch -d uptime
  Every 2.0s: uptime weiyigeek: Wed Nov 24 09:51:01 2021
  09:51:01 up 4 days, 22:52,  3 users,  load average: 1.03[关键点], 0.66, 0.29

# 3.最后，在第三个终端运行 mpstat 查看 CPU 使用率的变化情况：
# -P ALL 表示监控所有CPU，后面数字5表示间隔5秒后输出一组数据
$ mpstat -P ALL 5
  09:51:42 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
  09:51:47 AM  all   25.01    0.00    0.10    0.00    0.00    0.15    0.00    0.00    0.00   74.74
  09:51:47 AM    0    0.20    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00   99.60
  09:51:47 AM    1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00 # [关键点] %usr 
  09:51:47 AM    2    0.00    0.00    0.20    0.00    0.00    0.60    0.00    0.00    0.00   99.20
  09:51:47 AM    3    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

  Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
  Average:     all   24.99    0.00    0.03    0.00    0.00    0.16    0.00    0.00    0.00   74.82
  Average:       0    0.04    0.00    0.06    0.00    0.00    0.17    0.00    0.00    0.00   99.73
  Average:       1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00 # [关键点] %usr  
  Average:       2    0.03    0.00    0.04    0.00    0.00    0.37    0.00    0.00    0.00   99.56
  Average:       3    0.02    0.00    0.03    0.00    0.00    0.09    0.00    0.00    0.00   99.86

# 4.那么，到底是哪个进程导致了 CPU 使用率为 100% 呢？
# -u 参数表示间隔5秒后输出一组数据
$ pidstat -u 5 1
09:51:47      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
09:51:48        0      3962  100.00    0.00    0.00    0.00  100.00     1  stress  # 明显看到, stress 进程的  %usr 与 CPU 使用率为 100%。

从终端二中可以看到，1 分钟的平均负载会慢慢增加到 1.03，而从终端三中还可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明平均负载的升高正是由于 CPU 使用率为 100% 。

Tips : 执行stress进行系统压力测试时, 可以看见负载是以线性进行增长的特征。

场景二：I/O 密集型进程

# 1.首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync：
$ stress -i 1 --timeout 600
  stress: info: [14844] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd

# 2.还是在第二个终端运行 uptime 查看平均负载的变化情况：
# -n 表示每10s刷新一次
$ watch -n 10 -d uptime
  Every 10.0s: uptime     weiyigeek: Wed Nov 24 11:35:03 2021
  11:35:03 up 5 days, 36 min,  3 users,  load average: 1.03, 0.68, 0.31

# 3.然后，第三个终端运行 mpstat 查看 CPU 使用率的变化情况：
# 显示所有CPU的指标，并在间隔5秒输出一组数据
$ mpstat -P ALL 5 1
  Linux 5.4.0-90-generic (weiyigeek)   11/24/2021      _x86_64_        (4 CPU)
  11:35:18 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
  11:35:23 AM  all    1.04    0.00   23.68    0.00    0.00    1.38    0.00    0.00    0.00   73.90
  11:35:23 AM    0    4.20    0.00   95.80    0.00    0.00    0.00    0.00    0.00    0.00    0.00 # 关键点 %sys 与 物理机 %iowait 
  11:35:23 AM    1    0.00    0.00    0.00    0.00    0.00    1.19    0.00    0.00    0.00   98.81
  11:35:23 AM    2    0.00    0.00    0.00    0.00    0.00    4.21    0.00    0.00    0.00   95.79
  11:35:23 AM    3    0.00    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00   99.80

  Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
  Average:     all    1.04    0.00   23.68    0.00    0.00    1.38    0.00    0.00    0.00   73.90
  Average:       0    4.20    0.00   95.80    0.00    0.00    0.00    0.00    0.00    0.00    0.00 # 关键点 %sys与 物理机 %iowait 
  Average:       1    0.00    0.00    0.00    0.00    0.00    1.19    0.00    0.00    0.00   98.81
  Average:       2    0.00    0.00    0.00    0.00    0.00    4.21    0.00    0.00    0.00   95.79
  Average:       3    0.00    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00   99.80

# 4.最后，还是用 pidstat 来查询是哪个进程，导致 iowait 偏高，不用多说可以看到仍然是stress
$ pidstat -u 5 1
  Linux 5.4.0-90-generic (weiyigeek)   11/24/2021      _x86_64_        (4 CPU)
  11:37:09 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
  11:37:14 AM     0       738    0.20    0.00    0.00    0.00    0.20     0  vmtoolsd
  11:37:14 AM  1000     14845    3.59   96.21    0.00    0.20   99.80     1  stress    # 关键点: %system 与 %CPU 看到CPU使用率已经达到99.8%

从这里可以看到，1 分钟的平均负载会慢慢增加到 1.03，第一个 CPU 使用率升高了%system 为 95.80%，%iowait 为 0.0%（虚拟机的影响）。通常情况下如果是磁盘性能不好 %iowait 值应该是偏高的，上面种种特征表明平均负载的升高是由于 iowait 的升高。

Tips : 经过测试如果是虚拟机，此时 iowait 是没有变化的，但是物理机的情况下数值是可变化的。。

场景三：大量进程的场景 当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。

# 1.首先，我们还是使用 stress，但这次模拟的是 8 个进程：
$ stress -c 8 --timeout 600
  stress: info: [15174] dispatching hogs: 8 cpu, 0 io, 0 vm, 0 hdd


# 2.其次,利用 uptime 命令查看系统的负载情况
由于系统只有 4 个 CPU，明显比 8 个进程要少得多，因而，系统的 CPU 处于严重过载状态，平均负载高达 6.84：
$ watch -n 10 -d uptime
  Every 10.0s: weiyigeek: Wed Nov 24 12:02:17 2021
  12:02:17 up 5 days,  1:03,  3 users,  load average: 6.84, 3.24, 1.55

# 3.然后,运行 mpstat 查看 CPU 使用率的变化情况：
$ mpstat -P ALL 5 1
  Linux 5.4.0-90-generic (weiyigeek)   11/24/2021      _x86_64_        (4 CPU)
  12:02:17 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
  12:02:22 PM  all  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   # 关键点 %usr
  12:02:22 PM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
  12:02:22 PM    1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
  12:02:22 PM    2  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
  12:02:22 PM    3  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00

# 4.最后,运行 pidstat 来看一下进程的情况：
$ pidstat -u 5 1
  Linux 5.4.0-90-generic (WeiyiGeek)   11/24/2021      _x86_64_        (4 CPU)
  12:02:50 PM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
  12:02:55 PM     0     15175   49.90    0.00    0.00   49.90   49.90     3  stress   # 关键点 %usr & %wait & %CPU
  12:02:55 PM     0     15176   49.90    0.00    0.00   49.90   49.90     2  stress
  12:02:55 PM     0     15177   49.90    0.00    0.00   50.10   49.90     1  stress
  12:02:55 PM     0     15178   50.10    0.00    0.00   49.70   50.10     1  stress
  12:02:55 PM     0     15179   50.10    0.00    0.00   49.90   50.10     2  stress
  12:02:55 PM     0     15180   49.70    0.00    0.00   50.10   49.70     0  stress
  12:02:55 PM     0     15181   49.90    0.00    0.00   49.90   49.90     0  stress
  12:02:55 PM     0     15182   49.70    0.00    0.00   50.10   49.70     3  stress
  12:02:55 PM     0     15215    0.00    0.20    0.00    0.20    0.20     3  pidstat

从上述结果，可以看出 8 个进程在争抢 4 个 CPU，每个进程等待 CPU 的时间（也就是代码块中的 %wait 列）高达50.10%, 这些超出 CPU 计算能力的进程，最终导致 CPU 过载。

Tips: 上面用三了个案例展示了不同场景下平均负载升高的分析方法。

本节总结: 描述: 平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现，到底是哪里出现了瓶颈。所以，在理解平均负载时也需要注意：

1) 平均负载高有可能是 CPU 密集型进程导致的；
2) 平均负载高并不一定代表 CPU 使用率高，还有可能是 I/O 更繁忙了；
3) 当发现负载高的时候，你可以使用 mpstat、pidstat 等工具，辅助分析负载的来源。

更为简洁的说明: 平均负载是是平均活跃进程数(是被消耗掉的cpu个数), 其表示针对 CPU + IO 两者消耗性的集合:

针对CPU消耗性的进程。
针对IO消耗性的进程。
针对CPU+IO消耗性：例如大量的进程调度

2.上下文切换

本节主题，经常说的 CPU 上下文切换是什么意思？

2.1 基础概念

Q: 进程在竞争 CPU 的时候并没有真正运行，为什么还会导致系统的负载升高呢?

答: 因为多进程竞争CPU会导致上下文的切换, 所以CPU 上下文切换就是罪魁祸首(本节主题)。

我们都知道 Linux 是一个多任务操作系统，它支持远大于 CPU 数量的任务同时运行。

在每个任务运行前，CPU 都需要知道任务从哪里加载、又从哪里开始运行，也就是说需要系统事先帮它设置好 CPU 寄存器（Register）和程序计数器（Program Counter，PC）。

CPU 寄存器（Register） : 是 CPU 内置的容量小、但速度极快的内存。程序计数器（Program Counter，PC） : 用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置。

Tips : 它们都是 CPU 在运行任何任务前，必须的依赖环境，因此也被叫做 CPU 上下文。

WeiyiGeek.CPU寄存器&内存

Q: 那什么是cpu上下文切换?

答: 就是先把前一个任务的 CPU 上下文（也就是 CPU 寄存器和程序计数器）保存起来, 然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。而这些保存下来的上下文，会存储在系统内核中，并在任务重新调度执行时再次加载进来, 这样就能保证任务原来的状态不受影响，让任务看起来还是连续运行。

Tips: 保存的上下文是存储在系统内核(OS kernel)中的。

我猜肯定会有人说，CPU 上下文切换无非就是更新了 CPU 寄存器的值嘛，但这些寄存器，本身就是为了快速运行任务而设计的，为什么会影响系统的 CPU 性能呢？操作系统管理的这些“任务”到底是什么呢？

答: 进程和线程正是最常见的任务, 而硬件通过触发信号会导致中断处理程序的调用这也是任务。

所以根据任务的不同，CPU 的上下文切换就可以分为进程上下文切换、线程上下文切换以及中断上下文切换等几种不同的场景。

(1) 进程上下文切换

Linux 按照特权等级，把进程的运行空间分为内核空间和用户空间，分别对应着下图中 CPU 特权等级的 Ring 0 和 Ring 3(保存在某一个寄存器中)，CPU进行切换会根据这个值进行区分。

内核空间（Ring 0）: 具有最高权限，可以直接访问所有资源；
用户空间（Ring 3）: 只能访问受限资源，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中，才能访问这些特权资源。

WeiyiGeek.Linux特权等级

换个角度看，也就是说进程既可以在用户空间运行，又可以在内核空间中运行。

进程在用户空间运行时，被称为进程的用户态，而陷入内核空间的时候，被称为进程的内核态, 他们之间的转变需要通过系统调用来完成。

比如，当我们查看文件内容时，就需要多次系统调用来完成：首先调用 open() 打开文件，然后调用 read() 读取文件内容，并调用 write() 将内容写到标准输出，最后再调用 close() 关闭文件。

系统调用的过程是发生了 CPU 上下文的切换的， CPU 寄存器里原来用户态的指令位置，需要先保存起来。接着，为了执行内核态代码，CPU 寄存器需要更新为内核态指令的新位置。最后才是跳转到内核态运行内核任务。而系统调用结束后，CPU 寄存器需要恢复原来保存的用户态，然后再切换到用户空间，继续运行进程。

所以，一次系统调用的过程，其实是发生了两次 CPU 上下文切换（用户态 -->> 内核态，内核态 -->> 用户态）。

Tips: 需要注意的是系统调用过程中，并不会涉及到虚拟内存等进程用户态的资源也不会切换进程，跟我们通常所说的进程上下文切换是不一样的：进程上下文切换，是指从一个进程切换到另一个进程运行，而系统调用过程中一直是同一个进程在运行。

Tips: 系统调用过程通常称为特权模式切换，而不是上下文切换。但实际上，系统调用过程中，CPU 的上下文切换还是无法避免的。

Q: 进程切换可类比在银行柜台办理业务的那几种情形?

1) 银行分配各个窗口给来办理业务的人。 2) 如果只有1个窗口开放（系统资源不足），大部分都得等。 3) 如果正在办理业务的突然说自己不办了（sleep）,那他就去旁边再想想（等）。 4) 如果突然来了个VIP客户，可以强行插队。 5) 如果突然断电了（中断）, 都得等。

Q: 进程上下文切换跟系统调用又有什么区别呢?

答: 进程是由内核来管理和调度的，进程的切换只能发生在内核态。所以进程的上下文不仅包括了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的状态。因此，进程的上下文切换就比系统调用时多了一步：在保存当前进程的内核状态和 CPU 寄存器之前，需要先把该进程的虚拟内存、栈等保存下来；而加载了下一进程的内核态后，还需要刷新进程的虚拟内存和用户栈。

如下图所示，保存上下文和恢复上下文的过程并不是“免费”的，需要内核在 CPU 上运行才能完成.

WeiyiGeek.进程间的上下文切换

频繁上下文切换导致性能问题 : 每次上下文切换都需要几十纳秒到数微秒的 CPU 时间。这个时间还是相当可观的，特别是在进程上下文切换次数较多的情况下，很容易导致 CPU 将大量时间耗费在寄存器、内核栈以及虚拟内存等资源的保存和恢复上，进而大大缩短了真正运行进程的时间。

Linux 通过 TLB（Translation Lookaside Buffer-变换索引缓冲）来管理虚拟内存到物理内存的映射关系。当虚拟内存更新后，TLB 也需要刷新，内存的访问也会随之变慢。特别是在多处理器系统上，缓存是被多个处理器共享的，刷新缓存不仅会影响当前处理器的进程，还会影响共享缓存的其他处理器的进程。

Q: 什么是TLB(translation lookaside buffer)?

答: CPU里有一个TLB，用于缓存虚拟内存到物理内存映射关系的页表，如果发生上下文切换，会导致该部分缓冲的上一个进程的页表映射关系成为脏页，此时CPU会刷新整个TLB为新进程的页表。在多核处理器中TLB是它们共享的，频繁刷脏导致命中率下降，CPU会通过页表转换之后访问物理地址，此时性能是明显低于直接访问TLB里缓存的物理地址的。

Tips: 大内存页的使用还可以通过减少变换索引缓冲（translation lookaside buffer，TLB）的失败次数来提高性能。

Q: 究竟什么时候会切换进程上下文?

答: 显然，进程切换时才需要切换上下文，换句话说，只有在进程调度的时候，才需要切换上下文。 Linux 为每个 CPU 都维护了一个就绪队列，将活跃进程（即正在运行和正在等待 CPU 的进程）按照优先级和等待 CPU 的时间排序，然后选择优先级最高和等待 CPU 时间最长的进程来运行。

Q: 进程在什么时候才会被调度到 CPU 上运行呢？

答: 最容易想到的一个时机，就是进程执行完终止了，它之前使用的 CPU 会释放出来，这个时候再从就绪队列里，拿一个新的进程过来运行。

其实还有很多其他场景，也会触发进程调度，在这里我给你逐个梳理下:

其一，为了保证所有进程可以得到公平调度，CPU 时间被划分为一段段的时间片，这些时间片再被轮流分配给各个进程。这样当某个进程的时间片耗尽了，就会被系统挂起，切换到其它正在等待 CPU 的进程运行。（一个进程结束，需要从队列中重新选择一个）
其二，进程在系统资源不足（比如内存不足）时，要等到资源满足后才可以运行，这个时候进程也会被挂起，并由系统调度其他进程运行。 (如果不访问磁盘I/O等资源就不能继续，它会休眠直到资源可用。)
其三，当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时，自然也会重新调度。(如果进程用完时间片或被抢占，则返回到运行队列。)
其四，当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级进程来运行。(更高优先级进程进来)
其五, 发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序。(硬件坏了，会转移到内核中断程序)

Tips: 了解上述几个场景是非常有必要的，因为一旦出现上下文切换的性能问题，它们就是幕后凶手。

(2) 线程上下文切换

Q: 什么是进程和线程?之间区别是什么(老生常谈了)

进程 : 是系统资源分配的基本单位。
线程 : 是调度的基本单位。

说白了，所谓内核中的任务调度，实际上的调度对象是线程,而进程只是给线程提供了虚拟内存、全局变量等资源。

所以，对于线程和进程可以这么理解：

当进程只有一个线程时，可以认为进程就等于线程。
当进程拥有多个线程时，这些线程会共享相同的虚拟内存和全局变量等资源(上下文切换时不需要修改)。
此外线程也有自己的私有数据，比如栈和寄存器等(上下文切换时需要保存私有数据)。

线程的上下文切换其实就可以分为两种情况：

第一种，前后两个线程属于不同进程。此时，因为资源不共享，所以切换过程就跟进程上下文切换是一样。
第二种，前后两个线程属于同一个进程。此时，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据。

Tips：此时你会发现虽然同为上下文切换，但同进程内的线程切换，要比多进程间的切换消耗更少的资源，而这，也正是多线程代替多进程的一个优势。

(3) 中断上下文切换

描述: 为了快速响应硬件的事件，中断处理会打断进程的正常调度和执行，转而调用中断处理程序，响应设备事件。而在打断其他进程时，就需要将进程当前的状态保存下来，这样在中断结束后，进程仍然可以从原来的状态恢复运行。

因为中断上下文切换并不涉及到进程的用户态。所以即便中断过程打断了一个正处在用户态的进程，也不需要保存和恢复这个进程的虚拟内存、全局变量等用户态资源，它其实只包括内核态中断服务程序执行所必需的状态，包括 CPU 寄存器、内核堆栈、硬件中断 参数等。

对同一个 CPU 来说，中断处理比进程拥有更高的优先级，所以中断上下文切换并不会与进程上下文切换同时发生(中断的优先级更高，中断的是进程)。

所以: 由于中断会打断正常进程的调度和执行，所以大部分中断处理程序都短小精悍，以便尽可能快的执行结束。

注意: 中断上下文切换也需要消耗 CPU，切换次数过多也会耗费大量的 CPU，甚至严重降低系统的整体性能。(异常排查时非常注意中断次数过多带来的影响)

2.2 实践案例

Q: 用什么工具查看系统的上下文切换情况?

答: 首当其冲选择 vmstat 系统性能分析工具，来查询系统的上下文切换情况, 可用于分析系统内存和分析CPU上下文切换以及中断的次数。

# 前间隔1秒后，后输出1组数据
$ vmstat 1 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 6995904  68004 677452    0    0     0     1    3   13  0  0 100  0  0

此处着重注意下面前四列的内容：

r（Running or Runnable）是就绪队列的长度，也就是正在运行和等待 CPU 的进程数。
b（Blocked）则是处于不可中断睡眠状态的进程数。
in（interrupt）则是每秒中断的次数。
cs（context switch）是每秒上下文切换的次数。

例子中的上下文切换次数 cs 是 13 次，而系统中断次数 in 则是 3 次，而就绪队列长度 r 和不可中断状态进程数 b 都是 0。

Q: 用什么工具查看每个进程的详细情况?

答: 使用我们前面提到过的 pidstat 工具, 我们只需要加上 -w 选项即可查看每个进程上下文切换的情况了。

# 每隔5秒输出1组数据
$ pidstat -w 5 1
  Linux 5.4.0-90-generic (WeiyiGeek1)   11/24/2021      _x86_64_        (4 CPU)
                                     # 关键项
  05:29:33 PM   UID       PID   cswch/s nvcswch/s  Command
  05:29:38 PM     0        11     21.20      0.00  rcu_sched
  05:29:38 PM     0        12      0.20      0.00  migration/0
  05:29:38 PM     0        17      0.20      0.00  migration/1
  05:29:38 PM     0        18      0.20      0.00  ksoftirqd/1
  05:29:38 PM     0        23      0.20      0.00  migration/2
  05:29:38 PM     0        29      0.20      0.00  migration/3

此处着重关注以下两列的内容

cswch : 表示每秒自愿上下文切换（voluntary context switches）的次数. voluntary 英 ['vɒləntri]
nvcswch : 表示每秒非自愿上下文切换（non voluntary context switches）的次数。

下面两个概念意味着不同的性能问题:

自愿上下文切换，是指进程无法获取所需资源，导致的上下文切换。比如说， I/O、内存等系统资源不足时，就会发生自愿上下文切换。
非自愿上下文切换，则是指进程由于时间片已到等原因，被系统强制调度，进而发生的上下文切换。比如说，大量进程都在争抢 CPU 时，就容易发生非自愿上下文切换。

今天的案例，我们将使用 sysbench 是一个多线程的基准测试工具，一般用来评估不同系统参数下的数据库负载情况，此处用于模拟系统多线程调度切换的情况。

我们需要在前面的基础环境之上执行apt install sysbench进行安装基准测试工具，此处安装的版本sysbench 1.0.18。

# 1.首先，在第一个终端里运行 sysbench ，模拟系统多线程调度的瓶颈：
# 以20个线程运行5分钟的基准测试，模拟多线程切换的问题
$ sysbench --threads=20 --time=300 threads run
  Number of threads: 20
  Threads started!
  # 性能测试结果
  General statistics:
    total time:                          300.5970s
    total number of events:              646476
  Latency (ms):
    min:                                    0.44
    avg:                                    9.30
    max:                                 3359.40
    95th percentile:                       30.81
    sum:                              6011429.64
  Threads fairness:
    events (avg/stddev):           32323.8000/246.36
    execution time (avg/stddev):   300.5715/0.01


# 2.接着,在第二个终端运行 vmstat ，观察上下文切换情况：
# 每隔1秒输出2组数据，共执行一次。
$ vmstat 1 2
  procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
  14  0      0 6957600  70408 692940    0    0     0     0 63535 1484981 28 58 14  0  0
  9  0      0 6957600  70408 692940    0    0     0     0 69282 1576618 29 61 10  0  0  # 关键点

发现 `cs列` 的上下文切换次数从之前的13骤然上升到了 157 万左右。
发现 `r列` 就绪从14到9远远超过系统CPU的个数4个所以存在大量的CPU竞争。
发现 `in列` 中断次数也上升到了 6 万左右，说明中断处理也是个潜在的问题。
发现 `us（user）和 sy（system）列` , 这两列的 CPU 使用率加起来上升到了90%, 其中系统 CPU 使用率(sy)为61%,说明主要是被内核占用。


# 3.然后,在第三个终端再用 pidstat 来看一下， CPU 和进程上下文切换的情况：
# 每隔1秒输出1组数据（需要 Ctrl+C 才结束）
# -w参数表示输出进程切换指标，而-u参数则表示输出CPU使用指标
$ pidstat -w -u 1
  Linux 5.4.0-90-generic (WeiyiGeek1)   11/24/2021      _x86_64_        (4 CPU)
  09:09:25 PM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
  09:26:22 PM     0     16814  116.83  226.73    0.00    0.00  343.56     0  sysbench  # 关键点
  09:26:22 PM     0     16837    0.00    0.99    0.00    0.00    0.99     3  pidstat
# 从 pidstat 的输出你可以发现，CPU 使用率的升高果然是 sysbench 导致的，它的 CPU 使用率已经达到了343.56%。
  09:26:22 PM   UID       PID   cswch/s nvcswch/s  Command
  09:26:22 PM     0        10      0.99      0.00  ksoftirqd/0
  09:26:22 PM     0        11     34.65      0.00  rcu_sched
  09:26:22 PM     0        30      2.97      0.00  ksoftirqd/3
  09:26:22 PM     0       347      2.97      0.00  irq/16-vmwgfx
  09:26:22 PM     0       691      0.99      0.00  multipathd
  09:26:22 PM     0       738      8.91      0.00  vmtoolsd
  09:26:22 PM     0     14042      2.97      0.00  kworker/0:1-events
  09:26:22 PM     0     15931      3.96      0.00  kworker/u256:2-events_power_efficient
  09:26:22 PM     0     15954      5.94      0.00  kworker/1:2-events
  09:26:22 PM     0     15959      3.96      0.00  kworker/3:2-events
  09:26:22 PM     0     16803      0.99      0.00  kworker/2:0-events
  09:26:22 PM  1000     16622    308.00      0.00  sshd
  09:26:22 PM     0     16803      2.00      0.00  kworker/2:0-events_freezable
  09:26:22 PM     0     17060      1.00    320.00  pidstat
# 但上下文切换则是来自其他进程，包括非自愿上下文切换频率最高的 pidstat ，以及自愿上下文切换频率最高的内核线程 kworker 和 sshd 、rcu_sched(发生过资源抢占)。

# 通过运行 man pidstat ，你会发现 pidstat 默认显示进程的指标数据，加上 -t 参数后，才会输出线程的指标。
# -wt 参数表示输出线程的上下文切换指标
$ pidstat -wt 1 1  
  Linux 5.4.0-90-generic (WeiyiGeek1)   11/24/2021      _x86_64_        (4 CPU)
  09:09:55 PM   UID      TGID       TID   cswch/s nvcswch/s  Command
  ... # 可以看到如下的 20 个 sysbench 子线程，下面的 cswch/s + nvcswch/s 只和就基本接近上面 157 万的上下文切换。
  09:09:56 PM     0         -     16815  19581.48  63652.78  |__sysbench  
  09:09:56 PM     0         -     16816  13800.93  46843.52  |__sysbench
  09:09:56 PM     0         -     16817  16292.59  56557.41  |__sysbench
  09:09:56 PM     0         -     16818  21408.33  59123.15  |__sysbench
  09:09:56 PM     0         -     16819  15557.41  72369.44  |__sysbench
  09:09:56 PM     0         -     16820  12700.00  65770.37  |__sysbench
  09:09:56 PM     0         -     16821  18720.37  58808.33  |__sysbench
  09:09:56 PM     0         -     16822  21382.41  64792.59  |__sysbench
  09:09:56 PM     0         -     16823  16299.07  63200.00  |__sysbench
  09:09:56 PM     0         -     16824  16655.56  65888.89  |__sysbench
  09:09:56 PM     0         -     16825  20249.07  57767.59  |__sysbench
  09:09:56 PM     0         -     16826  19690.74  55725.93  |__sysbench
  09:09:56 PM     0         -     16827  20281.48  65908.33  |__sysbench
  09:09:56 PM     0         -     16828  17264.81  70136.11  |__sysbench
  09:09:56 PM     0         -     16829  13706.48  68283.33  |__sysbench
  09:09:56 PM     0         -     16830  19050.00  68422.22  |__sysbench
  09:09:56 PM     0         -     16831  14403.70  66034.26  |__sysbench
  09:09:56 PM     0         -     16832  19878.70  59848.15  |__sysbench
  09:09:56 PM     0         -     16833  18844.44  69676.85  |__sysbench
  09:09:56 PM     0         -     16834  17438.89  76772.22  |__sysbench
  ...

# 4.最后,从 /proc/interrupts 这个只读文件中查看中断的信息:
# 上升到6万左右的中断数，我们可以通过/proc/interrupts了解到到底什么类型的中断上升了。
$watch -d cat /proc/interrupts
Every 2.0s: cat /proc/interrupts   WeiyiGeek1: Wed Nov 24 21:12:52 2021
             CPU0       CPU1       CPU2       CPU3
  LOC:   11290842    8264060    8456662   11519861   Local timer interrupts  #  本地定时器中断
  ....
  RES:    8259277    9027295    9254487    9912950   Rescheduling interrupts  # 重新调度中断记录的累积变化量，需要观察的是它的变化率。

# RES : 它变化的速度比较快,该中断类型表示唤醒空闲状态的CPU来调度新的任务运行。
# 这是多处理器系统（SMP）中的特性，调度器用来分散任务到不同 CPU 的机制，通常也被称为处理器间中断（Inter-Processor Interrupts，IPI）。

通过上面分析，我们可知道，系统的就绪队列过长，也就是正在运行和等待 CPU 的进程数过多，导致了大量的上下文切换，而上下文切换又导致了系统 CPU 的占用率升高，并且中断升高还是因为过多任务的调度问题导致得。

Tips: /proc 实际上是 Linux 的一个虚拟文件系统，用于内核空间与用户空间之间的通信, 而 /proc/interrupts 就是这种通信机制的一部分，提供了一个只读的中断使用情况。

Tips: 友情提醒，sudo -i就可以快速切换到root啦😄 , 不加-i的话是以非登录模式切换sudo su root，不会拿到root的环境变量。

2.3 本章总结

上下文切换是什么？ 上下文切换是对任务当前运行状态的暂存和恢复
CPU为什么要进行上下文切换？ 当多个进程竞争CPU的时候，CPU为了保证每个进程能公平被调度运行，采取了处理任务时间分片的机制，轮流处理多个进程，由于CPU处理速度非常快，在人类的感官上认为是并行处理，实际是”伪”并行，同一时间只有一个任务在运行处理。
上下文切换主要消耗什么资源，为什么说上下文切换次数过多不可取？ 根据 Tsuna (https://blog.tsunanet.net/) 的测试报告，每次上下文切换都需要几十纳秒到到微秒的CPU时间，这些时间对CPU来说，就好比人类对1分钟或10分钟的感觉概念。在分秒必争的计算机处理环境下，浪费太多时间在切换上，只能会降低真正处理任务的时间，表象上导致延时、排队、卡顿现象发生。

Tips: 过多的上下文切换，会把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上。

上下文切换分几种？ 进程上下文切换、线程上下文切换、中断上下文切换.
什么情况下会触发上下文切换？ 系统调用、进程状态转换(运行、就绪、阻塞)、时间片耗尽、系统资源不足、sleep、优先级调度、硬件中断等.
线程上下文切换和进程上下文切换的最大区别？ 线程是调度的基本单位，进程是资源拥有的基本单位，同属一个进程的线程，发生上下文切换，只切换线程的私有数据，共享数据不变，因此速度非常快。
中断上下文切换，如何理解？ 为了快速响应硬件的事件(如USB接入)，中断处理会打断进程的正常调度和执行，转而调用中断处理程序，响应设备事件。而打断其它进程执行时，需要进行上下文切换。中断事件过多，会无谓的消耗CPU资源，导致进程处理时间延长。
有哪些减少上下文切换的技术用例？ 数据库连接池（复用连接）、合理设置应用的最大进程，线程数、直接内存访问DMA、零拷贝技术.
自愿与非自愿上下文切换的出现意味着那些性能问题? 自愿上下文切换变多（系统资源不足，进程在等待资源）以及非自愿上下文切换变多（进程都在被强制调度，都在争抢CPU资源）。可以看出一般性能问题: 主要分为两大类，一大类是IO类的，另外一类则是 cpu类的。
系统中断详细以及中断发生类型如何查看? 中断只发生在内核态，如果中断次数变多，则说明CPU 被中断处理程序占用，在操作系统可通过查看/proc/interuppts的文件查询详细的中断信息（分析中断类型）。
每秒上下文切换多少次才算正常呢？ 其实取决于系统本身的 CPU 性能，但是通常系统上下文切换次数比较稳定的区间在从数百到一万以内，但如果上下文切换次数超过一万次，或者切换次数出现数量级的增长时，就很可能已经出现了性能问题(然后具体问题具体分析！)。
分析上下文切换次数过多问题的分析需要用到那些工具? 我们需要用到 vmstat(查看系统整体的平均上下文切换情况)、pidstat(查看进程或线程详细的上下文切换情况)以及/proc/interrupts()等工具，来辅助排查性能问题的根源。