网易视频云DirectIO时的IO放大探究.docxVIP

网易视频云：DirectIO时的IO放大探究网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的PASS服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。现在，网易视频云与大家分享一下DirectIO时的IO放大探究。前段时间在对我们自己开发的文件系统测试过程中发现一个有趣的现象：IO放大。测试现象描述如下：现象1：iostat –x /dev/sdh1，观察发现每秒完成的读请求次数100+，而测试程序统计的实际IOPS为50，约为iostat统计数据的一半；现象2：cat /sys/block/sdh1/stat发现测试程序运行过程中，该设备被读的数据量为77292KB，而测试程序实际读数据量为40000KB。我们会在下面的两个测试以及原理分析中揭示这些额外IO来自何方。测试1：不同offset读文件测试测试目的测试ext3文件系统元数据（索引块）对文件读性能影响测试方法顺序读数据目录(500个1GB大小文件)所有文件，每个文件读一次，每轮测试中读文件offset一致，一共执行五轮，offset分别为32KB，48KB，64KB，1GB-40KB，每轮测试之前清空缓存（echo 3 /proc/sys/vm/drop_caches）,使用O_DIRECT方式读，每次读4KB。测试结果结论上面的测试较为有力地解释了ext3文件系统元数据(主要指索引块)对杜性能影响。在元数据缓存未命中情况下，读文件offset越大，产生额外IO越多，IOPS越低。测试2：元数据缓存性能测试测试目的测试ext3文件系统元数据(主要指索引块)缓存与否对文件读性能影响测试方法顺序读数据目录下所有文件(500个，每个大小为1GB)，每个文件只读一次，offset为1GB-40KB(根据计算，ext3此时使用二级间接索引)。测试共执行两轮，第一轮测试之前清cache，第二轮测试之前不清理cache，使用O_DIRECT方式读，读大小4KB。测试结果结论该测试对比了ext3文件系统元数据缓存与否对读性能影响，元数据未缓存情况下，产生的额外IO越多，IOPS越低。而且，因为每次读偏移位于二级索引，需要两次额外的元数据IO，每个索引块大小为4KB，所以实际读出数据量应该为期望读数据量的三倍，与测试结果较吻合。原理分析为了进一步弄清楚这个问题，我们本着打破砂锅问到底的精神，翻阅了Linux内核代码，看看文件系统direct方式读的实现，需要说明的是我们使用的内核代码版本为3.12。在代码分析之前，先来普及一个概念：文件系统和底层块设备都有自己的块大小设置，而且，这两者可以不相同。块设备的默认块大小为512字节，有兴趣的可以自己查看下hd_init()这个函数。文件系统，如ext3，默认块大小是1024字节（可以自己挂载文件系统的时候设置，但最小1024字节，最大为PAGE_SIZE），有兴趣的同学可以自己查看下ext3_fill_super()这个函数。因此一般说来，文件系统块大小是块设备默认大小的整数倍，明白这个对理解后面的实现比较重要。另外，我们看看direct方式读接口参数需要注意的几点，read接口形式为：read(fd, buffer, size)注意:buffer需要对齐，对齐的单位是块大小，按照文件块大小或者设备块大小对齐均可，可通过函数posix_memalign()来分配按照一定粒度对齐的缓冲区；读偏移offset必须以文件或者设备块大小对齐；读大小size必须以文件或者设备块大小对齐；上述只要有一点不满足，调用失败，返回错误信息为”Invalid argument”。同样，我们通过情境分析的方式来分析实现，要不显得实在是枯燥，假如我们读的调用形式为?read(fd, buffer, 4096)其中，buffer以1024字节对齐，分配的buffer地址为0X804a400，offset从0开始。跟着代码深入，文件系统的read最终会进入函数generic_file_aio_read()。因为本文只讨论direct IO方式的读，因此我们只关注以下部分代码(mm/filemap.c)：if (filp-f_flags O_DIRECT) {……if (!retval) {retval =?mapping-a_ops-direct_IO(READ, iocb,? iov, pos, nr_segs);}……}看看代码，发现核心是调用了具体文件系统的directIO实现，对于ext3文件系统来说，是ext3_direct_IO()。接下来，以此为起点，我们一路向西，跟踪调用流程：ext3