那些年解的疑难性能问题 --- ext4碎片整理

引子

年轻时候的我们，觉得疑难问题大都是技术方面的问题。觉得自己解个疑难高深技术问题，就很了不起似的。

但是随着工作经历的不断丰富，我们会发现国内IT企业搞法，光拼技术，很容易被年轻人赶上的。因为国内知名的IT公司，无不是高强度加班。

因此我们得扩大自己的视野，拓宽自己的思维，从理解和把握公司的开发业务入手，在更好地吃透公司的开发业务，更好地最大化自己团队的业务价值这方面入手，才能拉开与年轻人的差距，

显示大龄工程师跟年轻人相比的独特优势。

所以更大地疑难，更大地挑战在于如何更好，更快地让自己的技术为公司的业务服务，最大化自己的业务价值。

问题爆出

最近发现用户手机，特别是使用时间长的老手机，经常会出现性能卡顿的问题，比如用户在操作手机桌面的时候，会感觉比较卡顿。

经过对这类手机的统一定位和分析，结果发现普遍存在的一类共同特征：文件系统碎片化特别严重。

用户在使用手机时，由于碎片化严重，会产生大量地IO请求，这样和磁盘交互的IO性能就会变差，于是反映在用户体验上，就是手机操作性能差，会变卡顿。

优化工作开展

紧跟业务

如果眼光只瞄准技术，只对技术感兴趣的，你会发现IT技术，特别是软件技术，更新换代是很快的，是永远学不完的，并且好不容易花时间把某方面的技术掌握透彻了，但是之前搞的其他技术又遗忘了些。

所以为了不使得自己的美好时光白白流逝，必须得首先从自己项目组的业务特点入手，时刻让自己的技术能够紧跟业务特色，为业务服务，这样才能使工作得到健康发展。

而我们项目组的业务特色：就是制定各种性能优化方案，让操作系统性能变得更快一点。

碎片整理调研

前面讲了文件系统碎片化严重时，会使得操作系统的性能变差。那么重点在于如何减少文件系统的碎片数目，于是自然就想起来碎片整理方案，恰巧ext4文件系统自身就带了一个碎片整理工具。

但是该工具有一些缺陷

1：只能对文件内的碎片进行整理，文件外的碎片无法整理。

文件内的碎片会影响到文件的顺序读性能，但是文件外的碎片会影响到文件的append写性能。

而手机中文件的append写是很频繁的，文件外碎片得不到整理时，是会影响到手机的IO性能的。

2：当磁盘free空间变碎片化严重时，文件内的碎片整理是大概率会失败的。

前面说了用户报的因碎片化严重导致的性能卡顿，基本上是自身手机的free 存储空间已经碎片化了。

这个时候，必须对ext4自身的碎片整理工具做些改进，才能解决用户那边的性能卡顿问题。

于是我开始着手研究碎片整理优化方案了。

碎片整理推出

我的碎片整理方案分为两个部分：一个是compact碎片整理, 整理文件外碎片。另外一个就是文件内碎片整理，当文件外碎片得到及时整理后，自然地也会解决上面的工具缺陷2问题。

仔细梳理了下，为了成功做好碎片整理方案，自己做了如下的工作：

1：在做碎片整理方案时，对部署该方案后对系统的稳定性风险影响方面进行了充分地评估和考量，还针对有些文件系统稳定性问题，修改了自己的方案。

2：并且在如何减少因为碎片整理产生的flash数据写入量方面，并智能寻找和整理最影响手机系统性能卡顿的ext4 group方面，也花了不少时间和精力。

3：解决碎片整理过程中的受selinux权限阻挡，而整理报错问题。该问题不解决，碎片整理就会大大受限，在操作系统性能提升方面，就不能发挥作用了。

性能优化效果验证

性能组的主要工作就是优化和提升操作系统性能。所以为了展现自己的业务价值，我下来的必做工作就是测试手机部署碎片整理方案后，会在哪方面手机使用场景中，会体现到碎片整理带来的性能提升好处。

文件外碎片整理性能提升测试验证

文件外碎片整理影响的是文件的写性能。

下来模拟了一个用户手机的存储碎片化状态，然后做我们的性能测试验证工作。

最后发现在应用安装，文件拷贝等很多手机操作场景中（这些场景赶好对应的是文件写数据比较多），碎片整理都能提升用户手机的IO性能。

文件内碎片整理性能提升测试验证

1：一点弯路

前面说了，文件内碎片整理是会影响到文件的顺序读性能的。

在对文件内碎片整理进行性能测试验证时，发现得首先构建个碎片化严重的文件，分析文件碎片化程度跟文件顺序读性能的关系，这样才能准确得出该如何调整碎片整理参数，使得文件读性能得到最大化提升，同时flash数据写入量最小。

自己好不容易做了个工具（期间还修改了内核文件系统模块），可以自动把某文件碎片化，并且用户想生成多少个碎片数目的文件，就能生成这样的文件。

下来有个工具再做完测试验证后，发现了一些问题：

问题1:

必须对文件碎片化很严重时，文件的顺序读性能才能得到提升的，但是这么严重的文件碎片化，在用户手机场景中是很少会出现的，几乎没有。

问题2：

文件碎片化不是很严重时，其实文件顺序读性能也是可以得到提升的。但必须是后台起多进程并发进行读文件操作时，然后碎片化严重的那个文件顺序读性能才会得到一点提升，性能提升并不大。

其实这个问题不难看出，是因为我们的操作系统用的是cfq io调度器。读进程的数目越多，单个进程分配的IO时间就短，这样碎片化严重的那个文件产生的IO请求数目多，顺序读完该文件花的时间就长点了。

2：又有惊奇地发现

好不容易做了碎片整理工具，结果发现文件内碎片整理没有发挥多大的性能优化作用，很是郁闷。于是对文件IO读模式又做了一些调研。发现之前的读性能提升不大时，对应读的文件都是buffer 写 + 最后一个fsync产生的文件。

但是手机里面很多sqlite数据库文件，都是不断地buffer 写 + 紧跟一个fsync这样产生的，就是每一笔用户的buffer 数据写完后，都会下发一个fsync。

于是乎想到了一个主意，把碎片化文件的产生方式改改，改成每做一次buffer 写，就fsync一下，靠这样的写数据来产生个碎片化文件。所以下来再进行性能测试时，发现文件的读耗时性能在碎片整理后比整理前要提升很大，

具体反映在每一笔128k, 256k, 512K,1024k的顺序读耗时性能都提升了2到3倍，这样虽然sqlite数据库里面都是随机读为主，但是具体到每一笔小数据的读（128k-1024k）时，还是顺序读了。这样碎片整理后，数据库的读性能是会得到提升的。

哇，终于挖掘到了一个碎片整理提升文件顺序读性能的用户场景了。

方便部署

1：碎片整理工作耗时优化

碎片整理方案虽然大部分工作都做完了，但是还是发现一个问题，实际进行碎片整理时，耗时比较长。

领导不满意了，毕竟我们性能组的工作思路是要让操作系统里面的每个程序都运行地飞快些。所以下来还是优化这个问题。

于是下来定位了耗时问题的根源，对ext4 jbd2做了优化。

2：加密文件系统适配

有些系统里面文件是加密的，对于加密文件，无法进行碎片整理。所以下来开始做这方面的碎片整理适配工作了。

解决思路很简单，中国人的模仿能力是很强的，Linux内核为什么受欢迎，因为它里面的代码都开源了，我们可以借鉴里面文件系统成功代码的思路，来解决我们的问题。

性能提升根本原因调研

大厂做事风格

大公司的工作思路风格和小公司还是有很大不同的。大厂做事讲究严谨科学，并且要有深入调查问题根本原因，穷追问题的气概。因为产品出货量是很大的，所以要做好充分地开发测试验证工作。

这一点跟小公司不同，很多小公司由于缺乏人力和时间投入，所以很多时候都是在做demo, 而非做产品的。

所以为了准确地挖掘量化碎片整理在用户场景那边的性能提升效果，又对碎片整理性能提升的根本原因做了详细调研。

文件写性能

搜到一篇国外发的论文：Aging what you see and what you don’t see. A file system aging approach for modern storage systems。

该论文提到了碎片整理确实可以提升flash的写性能，但是没有涉及提升的根本原因。

自己下来又做了深入挖掘，发现提升的根本原因在于如下几个方面：

1：

sqlite文件顺序读性能

(未完待续)