[TOC]

0x00 前言简述

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

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

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

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

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


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

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

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

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

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


Q: 性能指标是什么?

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

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

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

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

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


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

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

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

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

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


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

  1. 技巧一:虽然系统的原理很重要,但在刚开始一定不要试图抓住所有的实现细节。 你可以先学会我给你讲的这些系统工作原理,但不要去深究 Linux 内核是如何做到的,而是要把你的重点放到如何观察和运用这些原理上,

    • 比如:有哪些指标可以衡量性能?指标,比如是内存还是CPU,亦或者io
    • 使用什么样的性能工具来观察指标?比如io可以使用iostat 内存可以用mpstat
    • 导致这些指标变化的因素等。比如io阻塞出现的问题有: 读取小文件过多,网络阻塞,长连接过多等
  2. 技巧二:边学边实践,通过大量的案例演习掌握 Linux 性能的分析和优化。

  3. 技巧三:勤思考,多反思,善总结,多问为什么。想真正学懂一门知识,最好的方法就是问问题。当你能提出好的问题时,就说明你已经深入了解了它。


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

WeiyiGeek.Linux 性能工具图谱

WeiyiGeek.Linux 性能工具图谱

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

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

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

WeiyiGeek.Linux性能优化学习路径

WeiyiGeek.Linux性能优化学习路径

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


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


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


0x01 CPU 性能篇

1.平均负载

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

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

1
2
3
4
5
6
$ 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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# 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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# 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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# 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 两者消耗性的集合:

  1. 针对CPU消耗性的进程。
  2. 针对IO消耗性的进程。
  3. 针对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寄存器&内存

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特权等级

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.进程间的上下文切换

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
2
3
4
5
# 前间隔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 选项即可查看每个进程上下文切换的情况了。

1
2
3
4
5
6
7
8
9
10
11
# 每隔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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
# 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()等工具,来辅助排查性能问题的根源。

Tips: 如果在 CentOS 中安装sysbench 执行后很快完事了的可以设置下 max-requests,执行命令如下sysbench --num-threads=10 --max-time=300 --max-requests=10000000 --test=threads run