懂得了Android I/O调优对你的应用帮助很大(中篇)
I/O是一个非常大的话题,很难一次性将每个细节都讲清楚。对于服务器开发者来说,可以根据需要选择合适的文件系统和磁盘类型,也可以根据需要调整内核参数。但对于移动开发者来说,我们看起来好像做不了什么I/O方面的优化?
事实上并不是这样的,启动优化中“数据重排”就是一个例子。如果我们非常清楚文件系统和磁盘的工作机制,就能少走一些弯路,减少应用程序I/O引发的问题。
在上一期中,我不止一次的提到Page Cache机制,它很大程度上提升了磁盘I/O的性能,但是也有可能导致写入数据的丢失。那究竟有哪些I/O方式可以选择,又应该如何应用在我们的实际工作中呢?今天我们一起来看看不同I/O方式的使用场景。
I/O的三种方式
请你先在脑海里回想一下上一期提到的Linux通用I/O架构模型,里面会包括应用程序、文件系统、Page Cache和磁盘几个部分。细心的同学可能还会发现,在图中的最左侧跟右上方还有Direct I/O和mmap的这两种I/O方式。
那张图似乎有那么一点复杂,下面我为你重新画了一张简图。从图中可以看到标准I/O、mmap、直接I/O这三种I/O方式在流程上的差异,接下来我详细讲一下不同I/O方式的关键点以及在实际应用中需要注意的地方。
1. 标准I/O
我们应用程序平时用到read/write操作都属于标准I/O,也就是缓存I/O(Buffered I/O)。它的关键特性有:
● 对于读操作来说,当应用程序读取某块数据的时候,如果这块数据已经存放在页缓存中,那么这块数据就可以立即返回给应用程序,而不需要经过实际的物理读盘操作。
● 对于写操作来说,应用程序也会将数据先写到页缓存中去,数据是否被立即写到磁盘上去取决于应用程序所采用写操作的机制。默认系统采用的是延迟写机制,应用程序只需要将数据写到页缓存中去就可以了,完全不需要等数据全部被写回到磁盘,系统会负责定期地将放在页缓存中的数据刷到磁盘上。
从中可以看出来,缓存I/O可以很大程度减少真正读写磁盘的次数,从而提升性能。但是上一期我说过延迟写机制可能会导致数据丢失,那系统究竟会在什么时机真正把页缓存的数据写入磁盘呢?
Page Cache中被修改的内存称为“脏页”,内核通过flush线程定期将数据写入磁盘。具体写入的条件我们可以通过/proc/sys/vm文件或者sysctl -a | grep vm命令得到。
// flush每隔5秒执行一次
vm.dirty_writeback_centisecs = 500
// 内存中驻留30秒以上的脏数据将由flush在下一次执行时写入磁盘
vm.dirty_expire_centisecs = 3000
// 指示若脏页占总物理内存10%以上,则触发flush把脏数据写回磁盘
vm.dirty_background_ratio = 10
// 系统所能拥有的最大脏页缓存的总大小
vm.dirty_ratio = 20
在实际应用中,如果某些数据我们觉得非常重要,是完全不允许有丢失风险的,这个时候我们应该采用同步写机制。在应用程序中使用sync、fsync、msync等系统调用时,内核都会立刻将相应的数据写回到磁盘。
上图中我以read()操作为例,它会导致数据先从磁盘拷贝到Page Cache中,然后再从Page Cache拷贝到应用程序的用户空间,这样就会多一次内存拷贝。系统这样设计主要是因为内存相对磁盘是高速设备,即使多拷贝100次,内存也比真正读一次硬盘要快。
2. 直接I/O
很多数据库自己已经做了数据和索引的缓存管理,对页缓存的依赖反而没那么强烈。它们希望可以绕开页缓存机制,这样可以减少一次数据拷贝,这些数据也不会污染页缓存。
从图中你可以看到,直接I/O访问文件方式减少了一次数据拷贝和一些系统调用的耗时,很大程度降低了CPU的使用率以及内存的占用。
不过,直接I/O有时候也会对性能产生负面影响。
- 对于读操作来说,读数据操作会造成磁盘的同步读,导致进程需要较长的时间才能执行完。
- 对于写操作来说,使用直接I/O也需要同步执行,也会导致应用程序等待。
Android并没有提供Java的DirectByteBuffer,直接I/O需要在open()文件的时候需要指定O_DIRECT参数,更多的资料可以参考《Linux 中直接 I/O 机制的介绍》。在使用直接I/O之前,一定要对应用程序有一个很清醒的认识,只有在确定缓冲I/O的开销非常巨大的情况以后,才可以考虑使用直接I/O。
3. mmap
Android系统启动加载Dex的时候,不会把整个文件一次性读到内存中,而是采用mmap的方式。微信的高性能日志xlog也是使用mmap来保证性能和可靠性。
mmap究竟是何方神圣,它是不是真的可以做到不丢失数据、性能还非常好?其实,它是通过把文件映射到进程的地址空间,而网上很多文章都说mmap完全绕开了页缓存机制,其实这并不正确。我们最终映射的物理内存依然在页缓存中,它可以带来的好处有:
- 减少系统调用。我们只需要一次mmap() 系统调用,后续所有的调用像操作内存一样,而不会出现大量的read/write系统调用。
- 减少数据拷贝。普通的read()调用,数据需要经过两次拷贝;而mmap只需要从磁盘拷贝一次就可以了,并且由于做过内存映射,也不需要再拷贝回用户空间。
- 可靠性高。mmap把数据写入页缓存后,跟缓存I/O的延迟写机制一样,可以依靠内核线程定期写回磁盘。但是需要提的是,mmap在内核崩溃、突然断电的情况下也一样有可能引起内容丢失,当然我们也可以使用msync来强制同步写。
从上面的图看来,我们使用mmap仅仅只需要一次数据拷贝。看起来mmap的确可以秒杀普通的文件读写,那我们为什么不全都使用mmap呢?事实上,它也存在一些缺点:
- 虚拟内存增大。mmap会导致虚拟内存增大,我们的APK、Dex、so都是通过mmap读取。而目前大部分的应用还没支持64位,除去内核使用的地址空间,一般我们可以使用的虚拟内存空间只有3GB左右。如果mmap一个1GB的文件,应用很容易会出现虚拟内存不足所导致的OOM。
- 磁盘延迟。mmap通过缺页中断向磁盘发起真正的磁盘I/O,所以如果我们当前的问题是在于磁盘I/O的高延迟,那么用mmap()消除小小的系统调用开销是杯水车薪的。启动优化中讲到的类重排技术,就是将Dex中的类按照启动顺序重新排列,主要为了减少缺页中断造成的磁盘I/O延迟。
在Android中可以将文件通过MemoryFile或者MappedByteBuffer映射到内存,然后进行读写,使用这种方式对于小文件和频繁读写操作的文件还是有一定优势的。我通过简单代码测试,测试结果如下。
从上面的数据看起来mmap好像的确跟写内存的性能差不多,但是这并不正确,因为我们并没有计算文件系统异步落盘的耗时。在低端机或者系统资源严重不足的时候,mmap也一样会出现频繁写入磁盘,这个时候性能就会出现快速下降。
mmap比较适合于对同一块区域频繁读写的情况,推荐也使用线程来操作。用户日志、数据上报都满足这种场景,另外需要跨进程同步的时候,mmap也是一个不错的选择。Android跨进程通信有自己独有的Binder机制,它内部也是使用mmap实现。
利用mmap,Binder在跨进程通信只需要一次数据拷贝,比传统的Socket、管道等跨进程通信方式会少一次数据拷贝过程。
多线程阻塞I/O和NIO
我在上一期说过,由于写入放大的现象,特别是在低端机中,有时候I/O操作可能会非常慢。
所以I/O操作应该尽量放到线程中,不过很多同学可能都有这样一个疑问:如果同时读10个文件,我们应该用单线程还是10个线程并发读?
- 多线程阻塞I/O
我们来做一个实验,使用Nexus 6P读取30个大小为40MB的文件,分别使用不同的线程数量做测试。
你可以发现多线程在I/O操作上收益并没有那么大,总时间从3.6秒减少到1.1秒。因为CPU的性能相比磁盘来说就是火箭,I/O操作主要瓶颈在于磁盘带宽,30条线程并不会有30倍的收益。而线程数太多甚至会导致耗时更长,表格中我们就发现30个线程所需要的时间比10个线程更长。但是在CPU繁忙的时候,更多的线程会让我们更有机会抢到时间片,这个时候多线程会比单线程有更大的收益。
总的来说文件读写受到I/O性能瓶颈的影响,在到达一定速度后整体性能就会受到明显的影响,过多的线程反而会导致应用整体性能的明显下降。
案例一:
CPU: 0.3% user, 3.1% kernel, 60.2% iowait, 36% idle\.\.\.
案例二:
CPU: 60.3% user, 20.1% kernel, 14.2% iowait, 4.6% idle\.\.\.
你可以再来看上面这两个案例。
案例一:当系统空闲(36% idle)时,如果没有其他线程需要调度,这个时候才会出现I/O等待(60.2% iowait)。
案例二:如果我们的系统繁忙起来,这个时候CPU不会“无所事事”,它会去看有没有其他线程需要调度,这个时候I/O等待会降低(14.2% iowait)。但是太多的线程阻塞会导致线程切换频繁,增大系统上下文切换的开销。
简单来说,iowait高,I/O一定有问题。但iowait低,I/O不一定没有问题。这个时候我们还要看CPU的idle比例。从下图我们可以看到同步I/O的工作模式:
对应用程序来说,磁盘I/O阻塞线程的总时间会更加合理,它并不关心CPU是否真的在等待,还是去执行其他工作了。在实际开发工作中,大部分时候都是读一些比较小的文件,使用单独的I/O线程还是专门新开一个线程,其实差别不大。
2. NIO
多线程阻塞式I/O会增加系统开销,那我们是否可以使用异步I/O呢?当我们线程遇到I/O操作的时候,不再以阻塞的方式等待I/O操作的完成,而是将I/O请求发送给系统后,继续往下执行。这个过程你可以参考下面的图。
非阻塞的NIO将I/O以事件的方式通知,的确可以减少线程切换的开销。Chrome网络库是一个使用NIO提升性能很好的例子,特别是在系统非常繁忙的时候。但是NIO的缺点也非常明显,应用程序的实现会变得更复杂,有的时候异步改造并不容易。
下面我们来看利用NIO的FileChannel来读写文件。FileChannel需要使用ByteBuffer来读写文件,可以使用ByteBuffer.allocate(int size)分配空间,或者通过ByteBuffer.wrap(byte[])包装byte数组直接生成。上面的示例使用NIO方式在CPU闲和CPU忙时耗时如下。
通过上面的数据你可以看到,我们发现使用NIO整体性能跟非NIO差别并不大。这其实也是可以理解的,在CPU闲的时候,无论我们的线程是否继续做其他的工作,当前瓶颈依然在磁盘,整体耗时不会太大。在CPU忙的时候,无论是否使用NIO,单线程可以抢到的CPU时间片依然有限。
那NIO是不是完全没有作用呢?其实使用NIO的最大作用不是减少读取文件的耗时,而是最大化提升应用整体的CPU利用率。在CPU繁忙的时候,我们可以将线程等待磁盘I/O的时间来做部分CPU操作。非常推荐Square的Okio,它支持同步和异步I/O,也做了比较多优化,你可以尝试使用。
小文件系统
对于文件系统来说,目录查找的性能是非常重要的。比如微信朋友圈图片可能有几万张,如果我们每张图片都是一个单独的文件,那目录下就会有几万个小文件,你想想这对I/O的性能会造成什么影响?
文件的读取需要先找到存储的位置,在文件系统上面我们使用inode来存储目录。读取一个文件的耗时可以拆分成下面两个部分。
文件读取的时间 = 找到文件的 inode 的时间 + 根据 inode 读取文件数据的时间
如果我们需要频繁读写几万个小文件,查找inode的时间会变得非常可观。这个时间跟文件系统的实现有关。
- 对于FAT32系统来说,FAT32系统是历史久远的产物,在一些低端机的外置SD卡会使用这个系统。当目录文件数比较多的时候,需要线性去查找,一个exist()都非常容易出现ANR。
- 对于ext4系统来说,ext4系统使用目录Hash索引的方式查找,目录查找时间会大大缩短。但是如果需要频繁操作大量的小文件,查找和打开文件的耗时也不能忽视。
大量的小文件合并为大文件后,我们还可以将能连续访问的小文件合并存储,将原本小文件间的随机访问变为了顺序访问,可以大大提高性能。同时合并存储能够有效减少小文件存储时所产生的磁盘碎片问题,提高磁盘的利用率。
业界中Google的GFS、淘宝开源的TFS、Facebook的Haystack都是专门为海量小文件的存储和检索设计的文件系统。微信也开发了一套叫SFS的小文件管理系统,主要用在朋友圈图片的管理,用于解决当时外置SD卡使用FAT32的性能问题。
当然设计一个小文件系统也不是那么简单,需要支持VFS接口,这样上层的I/O操作代码并不需要改动。另外需要考虑文件的索引和校验机制,例如如何快速从一个大文件中找到对应的部分。还要考虑文件的分片,比如之前我们发现如果一个文件太大,非常容易被手机管家这些软件删除。
总结
在性能优化的过程中,我们通常关注最多的是CPU和内存,但其实I/O也是性能优化中比较重要的一部分。
今天我们首先学习了I/O整个流程,它包括应用程序、文件系统和磁盘三部分。接着我介绍了多线程同步I/O、异步I/O和mmap这几种I/O方式的差异,以及它们在实际工作中适用的场景。
无论是文件系统还是磁盘,涉及的细节都非常多。而且随着技术的发展,有些设计就变得过时了,比如FAT32在设计的时候,当时认为单个文件不太可能超过4GB。如果未来某一天,磁盘的性能可以追上内存,那时文件系统就真的不再需要各种缓存了。