31丨案例：当磁盘参数导致I/O高的时候，应该怎么办？

 

在大部分的性能项目中，当系统调优到一定程度的时候，性能的瓶颈往往会体现在两类计数器上：一个是 CPU，另一个就是磁盘 I/O 了。所以我们也经常会在一些性能优化的文章中看到两个分类，分别是 CPU 密集型和磁盘 I/O 密集型。

有人说为什么不说内存呢？内存是那么重要。不是说内存不会成为瓶颈，只不过内存的瓶颈基本上都可以转嫁给 CPU 和磁盘 I/O。当内存不够的时候，大不了就是清理得快一点。内存能表现出来的，就是满不满，而谁去清理呢？那就是 CPU 了。清理得快就得 CPU 转得快。

我们经常会听到有人说什么性能优化到最后就是“空间转时间、时间转空间的优化”。如此带有禅意的一句话，其实意思就是，CPU 不够用，就扩大内存；内存不够，就让 CPU 计算得更快一些。

举个例子，当我们需要在内存中使用很多变量时，如果内存不够，就会导致 CPU 不断清理内存中没被引用的变量来释放内存，这就导致了释放内存的动作会消耗更多的 CPU。而这时，我们就可以用增加内存的方式，让 CPU 不那么繁忙。

但这个“空间、时间转化”的论点并不会在所有的场景下成立。比如说一个应用并不需要多大内存，就是纯计算型的，那你加内存也没啥用。另外这里提到的“空间”也不是硬盘，因为如果 CPU 不够用，拿再多磁盘补也无济于事。

所以这句话只能是做为高深谒语让初入性能的小白们仰望，实际上适用的场景非常少。

而磁盘 I/O 和内存有很大的区别。只要系统需要保存运行过程中留下的数据，那就必然会用到磁盘 I/O。分析磁盘 I/O 的时候，相对于其他的分析环节还是要复杂一些，因为磁盘 I/O 栈是比较长的。有了 Direct I/O 技术之后，磁盘 I/O 栈短了一段，速度快了，但是同样也没有给性能测试分析人员带来什么福音，因为从分析的角度来说，我们看计数器并没有减少什么。

在性能分析过程中，操作系统是绕不过去的一个环节。在当前的技术栈中，我们仍然要把操作系统当成一个非常重要的环节。

现在对于 I/O 的分析和判断，大部分还停留在磁盘百分比、队列、磁盘延时之类上。可是这样的计数器的值多了，少了，你要干什么呢？怎么解决它呢？是磁盘参数有问题，还是应用有问题？还是磁盘硬件能力就那样了？

这是性能分析人员应该给出的答案, 可是有很多性能测试工程师还真的给不出来这样的答案，甚至有些人连哪个线程导致的 I/O 高都判断不出来。至少现在的状态说明了，性能测试行业还远远不够成熟，我们还有很多的机会。

现在我们所说的 I/O，基本上把 File I/O 和 Disk I/O 都说进去了，所以在分析上，层级更是非常模糊。如下图所示的一个 I/O 栈：

(此图来自于：https://www.thomas-krenn.com/de/wikiDE/images/b/ba/Linux-storage-stack-diagram_v4.0.png)

在这个图中，我们可以明确看到磁盘 I/O 栈有多长。从应用层开始，产生系统调用，再通过 visual FS Layer → FS Layer → Block Layer 这样一层一层地调用下去，最后才写到了硬件存储里。

当然还有一层，我们需要关注的就是从系统的全局状态到具体的线程，这个我在操作系统那一篇的 I/O 部分已经描述过。

下面我们来看一个 I/O 高的分析案例。

案例现象

在这个项目的压力测试过程当中，发现了经典的现象：

TPS 上不去；

硬件资源用不上。

应该说，性能分析要是分类比较宽泛，基本上是两种。

第一种是资源用不上，TPS 上不去，响应时间随压力而增加，如下图所示：

第二种是资源用得上，TPS 上不去，响应时间随压力而增加。如下图所示：

这样的划分方式看似有调侃味道，却是很多人疑惑的起点。为什么这么说呢？

我们在开始做性能分析的时候，经常会面对这种情况，那就是资源用不上去。也就是路不够宽，硬件资源才用不上的。我们要解决的，就是把路扩宽一些。

但是，当我们面对一些客户或领导的时候，如果去汇报某资源使用率达到 100% 这样高的值的时候，有可能得到的一个反馈是，能不能把资源使用率降下来，因为资源使用率高会让人有种不安全感，而 TPS 反而不是关注的重点。这就让我们很疑惑：TPS 上去了，资源必然用得多呀，难道让资源使用率稳定保持在 50%，而 TPS 蹭蹭往上涨吗？这不现实呀。

我的建议是，不用怕资源使用率高，做为专业性能分析人员，更应该怕的是资源使用率不高！

在这个例子中，一开始同事跟我描述的时候，说资源怎么也用不上去，TPS 也上不去。这样的描述很常见。

还是看看压力结果，如下所示：

（场景开始时报了少量的错，不过这不是我们这个案例要分析的部分，请看官忽略。）

像这种描述，基本上没办法让人分析，因为信息太少了。特别是有些人直接给一个固定线程数的压力结果，用来描述资源上不去的情况，这就更得不到有用的信息了，所以问性能问题的人一定要注意收集足够的信息，不然只能让人从头查一遍。

分析过程

因为没有什么具体的信息，所以我只能让同事把压力再压起来。

我登录到服务器上之后，顺手执行了一个 top 命令：

这里给个小提醒，执行 top 的时候一定要习惯性地点一下数字 1，这样可以把所有的 CPU 都列出来，因为我要看到每个 CPU 的各个计数器的使用率。别看这个动作不起眼，就算是这一个小小的操作，也是工作经验的积累。

果不其然，看到了一个问题，那就是上图中 CPU0 的 wa 达到了 72%。像这样的问题，如果不看每个 CPU 的每个计数器，是发现不了的。

看到这样的东西，我们要有个基本的判断，对于一般的 Java 应用来说，I/O 线程数基本上不会是 1 个，除非是特别的理由，所以这种情况还是很少的。

不过既然是 I/O 的问题导致了 wa CPU 使用率高，那么我来看一下 CPU 的热点在哪个层面。这是我在工作中经常执行的一个动作，因为我不想在后面的分析过程中偏离方向，而看 CPU 热点可以让我记得这个方向。

如下图所示：

有人说，即然 wa CPU 使用率已经高了，接下去直接看磁盘 I/O 不就行了，看不看 CPU 热点还重要吗？我要说，当然重要！看到前面的磁盘 I/O 栈了吗？那么长，怎么知道是在哪一层呢？

这是定向细化分析过程中的经验之一。

在 CPU 热点中我们看到了，是内核模块中的 blk_queue_bio 消耗的 CPU 大。blk_queue_bio 是用来做 I/O 调度合并的，可以对 I/O 请求进入后向、前向合并操作，互斥方式就是加锁。

根据它我们就可以知道，这是一个有 queue 的调度过程，再接着看它下面的几个函数也可以看出，都是 kernel 级的调用，并没有 user 级的调用，这几个函数基本上也说明了当前系统忙于 journal 写。

接着执行 iotop，看是哪个进程在做这个动作。这里可以看到 jbd2，和上面 CPU 热点的函数也是对应得上的。

那么 jbd2 是个啥玩意呢？jbd2 英文名是这样的：Journaling Block Device 2。

它是跟着 ext4 格式来的，当然它也可以在其他磁盘格式下工作。这个进程的工作原理是这样的：文件系统写入数据，要提交给驱动程序，而 jbd2 就是在文件系统调用驱动之前工作的。文件系统要先调用 jbd2，然后 jbd2 会根据系统的设置（设置有 writeback、ordered、journal），进行数据的备份，然后再让文件系统提交数据。当文件系统将数据写入了块设备之后，jbd2 就会把备份的数据删除。如果文件系统写块设备时出了问题（比如说可悲的断电），那 jbd2 这里还有一个备份，在进行完整性检查时就会把数据补全，所以数据不会丢。

jbd2 就是这样保证数据的完整性的。

但是！对嘛，我就喜欢说但是。jbd2 保证的数据完整性也只是一个原子操作的完整性，即一个原子操作如果操作了 2M 的数据，它就只能保证这 2M 的数据不会丢失。如果你一下子操作了 1T 的数据，jbd2 也不能保证完整性。

jbd2 有一个参数 barrier，它用来开启磁盘屏障。就是设置一个栅栏，要先把 barrier 之前的数据全都写到磁盘设备之后，才会写 barrier 之后的数据，也就是说它是用来保证原子操作中数据的完整性的。当然了，开启 barrier 的一个后果就是性能下降。

了解了这些内容之后，我们就要判断一下了。这个应用有没有必要用这个功能来保证原子操作的完整性？我考虑了一下之后，觉得这个应用就是写日志而已，也没有其他什么重要的东西是要写日志的，重要的业务数据都写到数据库去了。

所以，没必要保证数据写入的完整性，就算丢了一些日志数据又怎么样呢？如果真的就那么寸，应用出现大 bug，恰好块设备也出问题，或者断电，那真的只有烧香拜佛了。

于是我觉得这个功能不用也罢，把原理说明白之后，和架构组、开发组、运维组以及领导层们沟通了一圈，告诉了他们原理，实在是没有打开的必要。

最后大家一致同意：关掉！

我们再回过头来看下这个参数：

[root@主机A]# cat /proc/mounts

/dev/mapper/data_lvm-data_lv /data ext4 rw,relatime,barrier=1,data=ordered 0 0

上面的这个 barrier=1，就是我们要找的目标。想关了它，就是挂载磁盘的时候使用挂载选项 -o barrier=0 或者 nobarrier。我这里是直接设置为 0 的。

你也可以直接关掉 journal 功能：

tune2fs -o journal_data_writeback /dev/mapper/data_lvm-data_lv tune2fs -O "^has_journal" /dev/mapper/data_lvm-data_lv e2fsck -f /dev/mapper/data_lvm-data_lv

问题解决之后

我们再来看下问题解决后的压力工具结果：

从压力结果来看，同样的压力之下，TPS 增加了一倍，响应时间快了一倍。

top 如下所示：

集中的 wa CPU 也消失不见了，现在使用的也挺均衡的了。

iotop：

在 I/O top 的结果中，也看不到 I/O 非常高的 jbd2 了。

问题得到了完美地解决。

总结

不管是什么样的性能问题，其实从分析思路上仍然逃不开我一直提到的思路——那就是一个分析的完整链路。当你一层一层往下找问题时，只要抓住了重点，思路不断，找到根本原因就可以解决问题。

在这个 I/O 的问题中，难点在于怎么能知道 jbd2 的原理和参数。应该说，不管是谁，都不能保证自己的知识体系是完整的，那怎么办呢？查资料，各种学习，看源码，看逻辑。实在看不懂，那也没办法，接着修炼基础内功呗。

所以说性能测试行业中，经常只测不分析，也是因为做性能分析需要的背景知识量有点大，还要不断分析各种新的知识点。不过也就是因为如此，性能测试和性能分析才真的有价值。只测不调只是做了一半工作，价值完全体现不出来。