如何优化MySQL insert性能

测试场景

MySQL 5.7.12

主要测试 不同刷盘参数 对性能的影响, 使用以下三个场景:

sync_binlog=1, innodb_flush_log_at_trx_commit=1, 简写为b1e1 (binlog-1-engine-1)

sync_binlog=0, innodb_flush_log_at_trx_commit=1, 简写为b0e1

sync_binlog=0, innodb_flush_log_at_trx_commit=0, 简写为b0e0

MySQL 环境搭建使用 MySQL sandbox, 对应三个场景的启动参数如下:

1. ./start --sync-binlog=1 --log-bin=bin --server-id=5712 --gtid-mode=ON --enforce-gtid-consistency=1 --log-slave-updates=1

2. ./start --sync-binlog=0 --log-bin=bin --server-id=5712 --gtid-mode=ON --enforce-gtid-consistency=1 --log-slave-updates=1

3. ./start --sync-binlog=0 --log-bin=bin --server-id=5712 --gtid-mode=ON --enforce-gtid-consistency=1 --log-slave-updates=1 --innodb-flush-log-at-trx-commit=0

压力生成使用sysbench:

mysql -h127.0.0.1 -P5712 -uroot -pmsandbox -e"truncate table test.sbtest1"

/opt/sysbench-0.5/dist/bin/sysbench --test=/opt/sysbench-0.5/dist/db/insert.lua --mysql-table-engine=innodb --mysql-host=127.0.0.1 --mysql-user=root --mysql-password=msandbox --mysql-port=5712 --oltp-table-size=1000000 --mysql-db=test --oltp-table-name=stest --num-threads=1 --max-time=30 --max-requests=1000000000 --oltp-auto-inc=off --db-driver=mysql run

性能观测工具使用systemtap(简称stap), version 2.7/0.160

基准

在没有观测压力的情况下, 对三种场景分别进行基准测试, 用以矫正之后测试的误差:

场景

sysbench事务数

b1e1    67546  

b0e1    125699  

b0e0    181612  

火焰图与offcpu

火焰图

火焰图是Brendan Gregg首创的表示性能的图形方式, 其可以直观的看到压力的分布. Brendan提供了丰富的工具生成火焰图.

火焰图比较b0e1和b0e0

使用stap脚本获取CPU profile, 并生成火焰图(火焰图生成的命令略, 参看Brendan的文档)

stap脚本

global tids

probe process("/home/huangyan/sandboxes/5.7.12/bin/mysqld").function("mysql_execute_command") {

       if (pid() == target() &&tids[tid()] == 0) {

               tids[tid()] = 1

       }

}

global oncpu

probe timer.profile {

       if (tids[tid()] == 1) {

               oncpu[ubacktrace()] <<<1

       }

}

probe timer.s(10) {

       exit()

}

probe end {

       foreach (i in oncpu+) {

               print_stack(i)

               printf("\t%d\n", @count(oncpu[i]))

       }

}

注意:

1. 脚本只抓取MySQL的用户线程的CPU profile, 不抓取后台进程.

2. 脚本只抓取10s, 相当于对整个sysbench的30s过程进行了短期抽样.

b0e1生成的火焰图

请点击输入图片描述

性能

在开启观测的情况下, 观察性能:

场景

sysbench事务数

b0e1    119274  

b0e0    166424  

分析

在生成的火焰图中, 可以看到:

在b0e1场景中, _ZL27log_write_flush_to_disk_lowv的占比是12.93%, 其绝大部分时间是用于将innodb的log刷盘.

在b0e0场景中, _ZL27log_write_flush_to_disk_lowv的开销被节省掉, 理论上的事务数比例应是1-12.93%=87.07%, 实际事务数的比例是119274/166424=71.67%, 误差较大

误差较大的问题, 要引入offcpu来解决.

offcpu

在之前的分析中我们看到理论和实际的事务数误差较大. 考虑_ZL27log_write_flush_to_disk_lowv的主要 *** 作是IO *** 作, IO *** 作开始, 进程就会被OS进行上下文切换换下台, 以等待IO *** 作结束, 那么只分析CPU profile就忽略了IO等待的时间, 也就是说_ZL27log_write_flush_to_disk_lowv的开销被低估了.

offcpu也是Brendan Gregg提出的概念. 对于IO *** 作的观测, 除了CPU profile(称为oncpu时间), 还需要观测其上下文切换的代价, 即offcpu时间.

修改一下stap脚本可以观测offcpu时间. 不过为了将oncpu和offcpu的时间显示在一张火焰图上作对比, 我对于Brendan的工具做了微量修改, 本文将不介绍这些修改.

stap脚本

global tids

probe process("/home/huangyan/sandboxes/5.7.12/bin/mysqld").function("mysql_execute_command") {

   if (pid() == target() &&tids[tid()] == 0) {

       tids[tid()] = 1

   }

}

global oncpu, offcpu, timer_count, first_cpu_id = -1

probe timer.profile {

   if (first_cpu_id == -1) {

       first_cpu_id = cpu()

   }

   if (tids[tid()] == 1) {

       oncpu[ubacktrace()] <<<1

   }

   if (first_cpu_id == cpu()) {

       timer_count++

   }

}

global switchout_ustack, switchout_timestamp

probe scheduler.ctxswitch {

   if (tids[prev_tid] == 1) {

       switchout_ustack[prev_tid] = ubacktrace()

       switchout_timestamp[prev_tid] = timer_count

   }

   if (tids[next_tid] == 1 &&switchout_ustack[next_tid] != "") {

       offcpu[switchout_ustack[next_tid]] <<<timer_count - switchout_timestamp[next_tid]

       switchout_ustack[next_tid] = ""

   }

}

probe timer.s(10) {

   exit()

}

probe end {

   foreach (i in oncpu+) {

       print_stack(i)

       printf("\t%d\n", @sum(oncpu[i]))

   }

   foreach (i in offcpu+) {

       printf("---")

       print_stack(i)

       printf("\t%d\n", @sum(offcpu[i]))

   }

}

注意: timer.profile的说明中是这样写的:

Profiling timers are available to provide probes that execute on all CPUs at each system tick.

也就是说在一个时间片中, timer.profile会对每一个CPU调用一次. 因此代码中使用了如下代码, 保证时间片技术的正确性:

   if (first_cpu_id == cpu()) {

       timer_count++

   }

b0e1生成的带有offcpu的火焰图

请点击输入图片描述

性能

由于变更了观测脚本, 需要重新观测性能以减小误差:

场景

sysbench事务数

b0e1    105980  

b0e0    164739  

分析

在火焰图中, 可以看到:

1. _ZL27log_write_flush_to_disk_lowv的占比为31.23%

2. 理论上的事务数比例应是1-31.23%=68.77%, 实际事务数的比例是105980/164739=64.33%, 误差较小.

观测误差的矫正

在比较b0e1和b0e0两个场景时, 获得了比较好的结果. 但同样的方法在比较b1e1和b0e1两个场景时, 出现了一些误差.

误差现象

b1e1的火焰图如图:

请点击输入图片描述

其中_ZN13MYSQL_BIN_LOG16sync_binlog_fileEb(sync_binlog的函数)占比为26.52%.

但性能差异为:

场景

sysbench事务数

b1e1    53752  

b0e1    105980  

理论的事务数比例为1-26.52%=73.48%, 实际事务数比例为53752/105980=50.71%, 误差较大.

分析压力分布

首先怀疑压力转移, 即当sync_binlog的压力消除后, 服务器压力被转移到了其它的瓶颈上. 但如果压力产生了转移, 那么实际事务数比例应大于理论事务数比例, 即sync_binlog=0带来的性能提升更小.

不过我们还是可以衡量一下压力分布, 看看b1e1和b0e1的压力有什么不同, 步骤如下:

修改stap脚本, 在b1e1中不统计sync_binlog的代价. 生成的火焰图表示消除sync_binlog代价后, 理论上的服务器压力类型.

与b0e1产生的火焰图做比较.

stap脚本

只修改了probe end部分, 略过对my_sync堆栈的统计:

probe end {

       foreach (i in oncpu+) {

               if (isinstr(sprint_stack(i), "my_sync")) {

                       continue

               }

               print_stack(i)

               printf("\t%d\n", @sum(oncpu[i]))

       }

       foreach (i in offcpu+) {

               if (isinstr(sprint_stack(i), "my_sync")) {

                       continue

               }

               printf("---")

               print_stack(i)

               printf("\t%d\n", @sum(offcpu[i]))

       }

}

结果

b1e1, 理论的服务器压力图:

请点击输入图片描述

b0e1, 实际的服务器压力图:

请点击输入图片描述

可以看到, 压力分布是非常类似, 即没有发生压力分布.

BTW: 这两张图的类似, 具有一定随机性, 需要做多次试验才能产生这个结果.

分析

既然理论和实际的压力分布类似, 那么可能发生的就是压力的整体等比缩小. 推测是两个场景上的观测成本不同, 导致观测影响到了所有压力的观测.

观察stap脚本, 其中成本较大的是ctxswitch, 即上下文切换时的观测成本.

上下文切换的观测成本

如果 “上下文切换的观测成本 影响 场景观测 的公平性” 这一结论成立, 那么我们需要解释两个现象:

1. b1e1和b0e1的比较, 受到了 上下文切换的观测成本 的影响

2. b0e1和b0e0的比较, 未受到 上下文切换的观测成本 的影响

假设 上下文切换的观测成本 正比于 上下文切换的次数, 那么我们只需要:

1. 观测每个场景的上下文切换次数

2. 对于b1e1和b0e1的比较, 由上下文切换次数计算得到理论的降速比, 与实际的降速比进行比较

3. 对于b0e1和b0e0的比较, 由上下文切换次数计算得到是否会带来降速.

stap脚本

在probe scheduler.ctxswitch和probe end 增加了 ctxswitch_times 相关的内容:

global ctxswitch_times

probe scheduler.ctxswitch {

       ctxswitch_times++

       ...

}

probe end {

       ...

       printf("ctxswitch_times=%d\n", ctxswitch_times)

}

结果

场景

sysbench事务数

上下文切换次数

sync_binlog占比

b1e1    55352    826370    36.80%  

b0e1    105995    693383    –  

b0e0    162709    675092    –  

分析结果:

1. b1e1与b0e1的比较

1. 理论降速比: 693383/826370 = 83.90%

2. 实际降速比: (实际的事务数比例/由sync_binlog占比推算的理论的事务数比例) = (55352/105995)/(1-36.80%) = 0.5222/0.6320 = 82.63%

3. 误差很小. 即b1e1与b0e1的比较中, 理论值和实际值的误差来自于: IO *** 作的减少导致上下文切换的数量减小, 使得两个场景的观察成本不同.

2. b0e1与b0e0的比较: 上下文切换次数相近, 即两个场景的观察成本相同.

实验结果符合之前的分析.

结论

利用火焰图, 可以快速诊断出MySQL服务器级别的性能瓶颈, 做出合理的参数调整

对于IO类型的 *** 作的观测, 需要考虑oncpu和offcpu两种情况

由于观测手段中使用了上下文切换作为观测点, 那IO *** 作数量的不同, 会引起上下文切换次数的不同, 从而引起观测误差.

程序猿

火焰图（Flame Graphs）的安装和基本用法

火焰图（Flame Graphs）

一、概述：

火焰图（flame graph）是性能分析的利器，通过它可以快速定位性能瓶颈点。

perf 命令（performance 的缩写）是 Linux 系统原生提供的性能分析工具，会返回 CPU 正在执行的函数名以及调用栈（stack）。

本文介绍它的安装和基本用法。

二、安装perf和可视化生成器

# yum install perf -y //yum方式安装perf

# git clone https://github.com/brendangregg/FlameGraph.git //选择好火焰图文件存放路径后执行该条命令，从github上获取火焰图的相关文件，获取完成后会有一个FlameGraph的文件夹，如下图

说明：打开文件夹，里面大部分是perf语言写的脚本，生成火焰图后续会用到，如下图，右图为各pl文件用途释义

到此，安装完成。

三、perf 采集数据

# perf record -F 99 -a -g -- sleep 60 //对CPU所有进程以99Hz采集,它的执行频率是 99Hz（每秒99次），如果99次都返回同一个函数名，那就说明 CPU 这一秒钟都在执行同一个函数，可能存在性能问题。执行60秒后会d出如下图提示表示采集完成，在当前目录会生成一个perf.data的文件

# perf record -F 99 -p 181 -g -- sleep 60//对进程ID为181的进程进行采集，采集时间为60秒，执行期间不要退出

上述代码中perf record表示记录，-F 99表示每秒99次，-p 13204是进程号，即对哪个进程进行分析，-g表示记录调用栈，sleep 30则是持续30秒，-a 表示记录所有cpu调用。更多参数可以执行perf --help查看。

perf.data文件生成后，表示采集完成。最好是在火焰图的目录下进行采集，方便转换成SVG图形。

四、生成火焰图

# perf script -i perf.data &>perf.unfold//生成脚本文件

# ./FlameGraph/stackcollapse-perf.pl perf.unfold &>perf.folded

# ./FlameGraph/flamegraph.pl perf.folded >perf.svg //执行完成后生成perf.svg图片，可以下载到本地，用浏览器打开 perf.svg，如下图

五、火焰图的含义

火焰图是基于 perf 结果产生的 SVG 图片，用来展示 CPU 的调用栈。

y 轴表示调用栈，每一层都是一个函数。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。

x 轴表示抽样数，如果一个函数在 x 轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间长。注意，x 轴不代表时间，而是所有的调用栈合并后，按字母顺序排列的。

火焰图就是看顶层的哪个函数占据的宽度最大。只要有"平顶"（plateaus），就表示该函数可能存在性能问题。

颜色没有特殊含义，因为火焰图表示的是 CPU 的繁忙程度，所以一般选择暖色调。

六、互动性

火焰图是 SVG 图片，可以与用户互动。

（1）鼠标悬浮

火焰的每一层都会标注函数名，鼠标悬浮时会显示完整的函数名、抽样抽中的次数、占据总抽样次数的百分比。下面是一个例子。

mysqld'JOIN::exec (272,959 samples, 78.34 percent)

（2）点击放大

在某一层点击，火焰图会水平放大，该层会占据所有宽度，显示详细信息。

左上角会同时显示"Reset Zoom"，点击该链接，图片就会恢复原样。

（3）搜索

按下 Ctrl + F 会显示一个搜索框，用户可以输入关键词或正则表达式，所有符合条件的函数名会高亮显示。

七、火焰图示例

下面是一个简化的火焰图例子。

首先，CPU 抽样得到了三个调用栈。

func_c

func_b

func_a

start_thread

func_d

func_a

start_thread

func_d

func_a

start_thread

上面代码中，start_thread是启动线程，调用了func_a。后者又调用了func_b和func_d，而func_b又调用了func_c。

经过合并处理后，得到了下面的结果，即存在两个调用栈，第一个调用栈抽中1次，第二个抽中2次。

start_threadfunc_afunc_bfunc_c 1

start_threadfunc_afunc_d 2

有了这个调用栈统计，火焰图工具就能生成 SVG 图片。

上面图片中，最顶层的函数g()占用 CPU 时间最多。d()的宽度最大，但是它直接耗用 CPU 的部分很少。b()和c()没有直接消耗 CPU。因此，如果要调查性能问题，首先应该调查g()，其次是i()。

另外，从图中可知a()有两个分支b()和h()，这表明a()里面可能有一个条件语句，而b()分支消耗的 CPU 大大高于h()。

八、局限

两种情况下，无法画出火焰图，需要修正系统行为。

（1）调用栈不完整

当调用栈过深时，某些系统只返回前面的一部分（比如前10层）。

（2）函数名缺失

有些函数没有名字，编译器只用内存地址来表示（比如匿名函数）。

九、常见应用的火焰图

Node 应用的火焰图

Node 应用的火焰图就是对 Node 进程进行性能抽样，与其他应用的 *** 作是一样的。

$ perf record -F 99 -p `pgrep -n node` -g -- sleep 30

详细的 *** 作可以看这篇文章。

Chrome 浏览器的火焰图

Chrome 浏览器可以生成页面脚本的火焰图，用来进行 CPU 分析。

打开开发者工具，切换到 Performance 面板。然后，点击"录制"按钮，开始记录数据。这时，可以在页面进行各种 *** 作，然后停止"录制"。

这时，开发者工具会显示一个时间轴。它的下方就是火焰图。

浏览器的火焰图与标准火焰图有两点差异：它是倒置的（即调用栈最顶端的函数在最下方）；x 轴是时间轴，而不是抽样次数。

参考资料：

https://github.com/brendangregg/FlameGraph

http://www.brendangregg.com/flamegraphs.html

https://www.jianshu.com/p/492218c163d9

http://www.ruanyifeng.com/blog/2017/09/flame-graph.html

--------------------------------------------------------------------------------------------------------------------------------------------------------

欢迎从事性能测试的小伙伴加入性能测试Q群：

原文地址：https://www.cnblogs.com/wx170119/p/11459995.html

推荐文章

Delphi 进阶基础技能说明

delphi indy Idhttp error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version

delphi VCL组件同名继承

delphi 组件安装工具开发

delphi 从 TWebbrowse组件中获取图片

delphi 面向对象实用技能教学二(封装)

delphi 10.2.2.2004 Tokyo 安装步骤

delphi 安卓配置教程

delphi 组件安装教程详解

delphi 验证码识别(XE8源码)

问题：typedef char *pstring????

指向常量的指针

（转）9个offer，12家公司，35场面试，从微软到谷歌，应届计算机毕业生的2012求职之路

编程计算int类型整数的最大值和最小值

fatal error LNK1168: cannot open Debug/opreat.exe for writing

大三寒假学习进度笔记（十七）——机器学习基本知识和Spark的转移算子案例实 ***

大三寒假学习进度笔记（十六）——Spark环境搭建以及常见RDD算子学习

大三寒假学习进度笔记（十五）

scala语言实现客户信息管理系统

大三寒假学习进度笔记（十四）

大三寒假学习进度笔记（十三）

大三寒假学习进度笔记（十二）

大三寒假学习进度笔记（十一）

大三寒假学习进度笔记（十）

大三寒假学习进度笔记（九）

汇编第五章作业

小饼日记2020/12/6

小饼日记2020/12/2

*reverse*练习10--很简单的重邮杯预赛

记录一个牛逼的计算机组成原理老师

Copyright 2008-2020 ©晋ICP备16003840号-1

io_uring 是 Linux 提供的一个异步 I/O 接口。io_uring 在 2019 年加入 Linux 内核，经过了两年的发展，现在已经变得非常强大。本文基于 Linux 5.12.10 介绍 io_uring 接口。

io_uring 的实现主要在 fs/io_uring.c 中。

io_uring 的实现仅仅使用了三个 syscall：io_uring_setup, io_uring_enter 和 io_uring_register。它们分别用于设置 io_uring 上下文，提交并获取完成任务，以及注册内核用户共享的缓冲区。使用前两个 syscall 已经足够使用 io_uring 接口了。

用户和内核通过提交队列和完成队列进行任务的提交和收割。后文中会出现大量的简写，在这里先做一些介绍。

用户通过调用 io_uring_setup 1 初始化一个新的 io_uring 上下文。该函数返回一个 file descriptor，并将 io_uring 支持的功能、以及各个数据结构在 fd 中的偏移量存入 params。用户根据偏移量将 fd 映射到内存 (mmap) 后即可获得一块内核用户共享的内存区域。这块内存区域中，有 io_uring 的上下文信息：提交队列信息 (SQ_RING) 和完成队列信息 (CQ_RING)；还有一块专门用来存放提交队列元素的区域 (SQEs)。SQ_RING 中只存储 SQE 在 SQEs 区域中的序号，CQ_RING 存储完整的任务完成数据。2

在 Linux 5.12 中，SQE 大小为 64B，CQE 大小为 16B。因此，相同数量的 SQE 和 CQE 所需要的空间不一样。初始化 io_uring 时，用户如果不在 params 中设置 CQ 长度，内核会分配 entries 个 SQE，以及 entries * 2 个 CQE。

io_uring_setup 设计的巧妙之处在于，内核通过一块和用户共享的内存区域进行消息的传递。在创建上下文后，任务提交、任务收割等 *** 作都通过这块共享的内存区域进行，在 IO_SQPOLL 模式下（后文将详细介绍），可以完全绕过 Linux 的 syscall 机制完成需要内核介入的 *** 作（比如读写文件），大大减少了 syscall 切换上下文、刷 TLB 的开销。

io_uring 可以处理多种 I/O 相关的请求。比如：

下面以 fsync 为例，介绍执行这个 *** 作中可能用到的结构体和函数。

io_op_def io_op_defs[] 数组中定义了 io_uring 支持的 *** 作，以及它在 io_uring 中的一些参数。3 比如 IORING_OP_FSYNC：

io_uring 中几乎每个 *** 作都有对应的准备和执行函数。比如 fsync *** 作就对应 io_fsync_prep 和 io_fsync函数。

除了 fsync 这种同步（阻塞） *** 作，内核中还支持一些异步（非阻塞）调用的 *** 作，比如 Direct I/O 模式下的文件读写。对于这些 *** 作，io_uring 中还会有一个对应的异步准备函数，以 _async 结尾。比如：

这些函数就是 io_uring 对某个 I/O *** 作的包装。

用户将需要进行的 *** 作写入 io_uring 的 SQ 中。在 CQ 中，用户可以收割任务的完成情况。这里，我们介绍 SQE 和 CQE 的编码。

include/uapi/linux/io_uring.h 4 中定义了 SQE 和 CQE。SQE 是一个 64B 大小的结构体，里面包含了所有 *** 作可能用到的信息。

io_uring_sqe的定义

CQE 是一个 16B 大小的结构体，包含 *** 作的执行结果。

继续以 fsync 为例。要在 io_uring 中完成 fsync *** 作，用户需要将 SQE 中的 opcode 设置为 IORING_OP_FSYNC，将 fd 设置为需要同步的文件，并填充 fsync_flags。其他 *** 作也是类似，设置 opcode 并将 *** 作所需要的参数并写入 SQE 即可。

通常来说，使用 io_uring 的程序都需要用到 64 位的 user_data 来唯一标识一个 *** 作 5。user_data 是 SQE 的一部分。io_uring 执行完某个 *** 作后，会将这个 *** 作的 user_data 和 *** 作的返回值一起写入 CQ 中。

相关视频推荐

io_uring 新起之秀的linux io模式，是如何媲美epoll的

网络原理tcp/udp，网络编程epoll/reactor，面试中正经“八股文”

学习地址：https://ke.qq.com/course/417774?flowToken=1013300

需要C/C++ Linux服务器架构师学习资料加qun812855908获取（资料包括 C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg 等），免费分享

io_uring 通过环形队列和用户交互。

我们的先以用户提交任务为例，介绍 io_uring 的内核用户交互方式。用户提交任务的过程如下：

接下来我们简要介绍内核获取任务、内核完成任务、用户收割任务的过程。

介绍完 io_uring 的用户态接口后，我们就可以详细介绍 io_uring 在内核中是如何实现的了。

io_uring 在创建时有两个选项，对应着 io_uring 处理任务的不同方式：

这些选项的设定会影响之后用户与 io_uring 交互的方式：

每个 io_uring 都由一个轻量级的 io-wq6 线程池支持，从而实现 Buffered I/O 的异步执行。对于 Buffered I/O 来说，文件的内容可能在 page cache 里，也可能需要从盘上读取。如果文件的内容已经在 page cache 中，这些内容可以直接在 io_uring_enter 的时候读取到，并在返回用户态时收割。否则，读写 *** 作会在 workqueue 里执行。

如果没有在创建 io_uring 时指定 IORING_SETUP_IOPOLL 选项，io_uring 的 *** 作就会放进 io-wq 中执行。

上图覆盖了关闭 IOPOLL 模式下，用户通过 io_uring 执行 *** 作的整个调用流程。用户提交的 SQE 经过一系列处理后，会在 io_queue_sqe 中试探着执行一次。

所有的 *** 作都被提交到内核队列后，如果用户设置了 IORING_ENTER_GETEVENTS flag，io_uring_enter 在返回用户态前会等待指定个数的 *** 作完成。

之后，Linux 随时会调度 io-wq 的内核线程执行。此时，io_wq_submit_work 函数会不断用阻塞模式执行用户指定的 *** 作。某个 *** 作完整执行后，它的返回值就会被写入 CQ 中。用户通过 io_uring 上下文中的 CQ 队尾位置就能知道内核处理好了哪些 *** 作，无需再次调用 io_uring_enter。

通过火焰图可以观察到，在关闭 IOPOLL 时，内核会花大量时间处理读取 *** 作。

创建 io_uring 时指定 IORING_SETUP_IOPOLL 选项即可开启 I/O 轮询模式。通常来说，用 O_DIRECT 模式打开的文件支持使用轮询模式读写内容，执行 read / write *** 作。

在轮询模式下，io_uring_enter 只负责把 *** 作提交到内核的文件读写队列中。之后，用户需要多次调用 io_uring_enter 来轮询 *** 作是否完成。

在轮询模式下，io-wq 不会被使用。提交任务时，io_read 直接调用内核的 Direct I/O 接口向设备队列提交任务。

如果用户设置了 IORING_ENTER_GETEVENTS flag，在返回用户态前，io_uring_enter 会通过 io_iopoll_check 调用内核接口轮询任务是否完成。

通过火焰图可以看到，io_uring_enter 在提交任务这一块只花了一小部分时间。大部分时间都在轮询 I/O *** 作是否完成。

在实际生产环境中，我们往往会有这样的需求：往文件中写入 n 次，然后用 fsync 落盘。在使用 io_uring时，SQ 中的任务不一定会按顺序执行。给 *** 作设定 IO_SQE_LINK 选项，就可以建立任务之间的先后关系。IO_SQE_LINK 之后的第一个任务一定在当前任务完成后执行。7

io_uring 内部使用链表来管理任务的依赖关系。每一个 *** 作在经过 io_submit_sqe 的处理后，都会变成一个 io_kiocb 对象。这个对象有可能会被放入链表中。io_submit_sqe 8 会对含有 IO_SQE_LINK 的 SQE 作特殊处理，处理过程如下：

由此看来，SQ 中连续的 IO_SQE_LINK 记录会按先后关系依次处理。在 io_submit_sqes 结束前，所有的任务都会被提交。因此，如果任务有先后关系，它们必须在同一个 io_uring_enter syscall 中批量提交。

其他用于控制 io_uring 任务依赖的选项包括 IOSQE_IO_DRAIN 和 IOSQE_IO_HARDLINK，这里不再展开。

---