ext4文件系统的delalloc选项造成单次写延迟增加的分析

最近我们的服务进程遇到kill -15后处于Z的状态,变为了僵尸进程,经过/proc/{thread_id}/stack查看其上线程的栈,发现是卡在了fwrite的过程中,而我们的系统中所有文件系统挂载参数都使用了delalloc参数,怀疑是这个原因:ext4挂载的时候打开了delalloc选项,然后系统在没有分配磁盘块的情况下写写写,到page cache被回写到磁盘时,发现磁盘已经满了,没办法分配新的磁盘块了,就Hang住了。

这篇文章是淘宝内核组的刘峥同学在内部技术论坛上发表的一篇文章,但是由于刘峥同学目前没有blog,征得本人同意,贴在我的blog上,如果大家喜欢,请去新浪微博关注他。:)

日前线上在升级到Ext4文件系统后出现应用写操作延迟开销增大的问题。造成这一问题的根源目前已经查明,是由于Ext4文件系统的一个新特性——Delay Allocation造成的。(后面简称delalloc)

在详细分析这一问题之前,先来介绍一下Ext4文件系统的delalloc特性。这一特性简要概括起来就是将以前在buffer IO中每次写操作都会涉及的磁盘块分配过程推迟到数据回写时再进行。我们知道,在进行Buffer Write时,系统的实际操作仅仅是为这些数据在操作系统内分配内存页(page cache)并保存这些数据,等待用户调用fsync等操作强制刷新或者等待系统触发定时回写过程。在数据拷贝到page cache这一过程中,系统会为这些数据在磁盘上分配对应的磁盘块。

而在使用delalloc后,上面的流程会略有不同,在每次Buffer Write时,数据会被保存到page cache中,但是系统并不会为这些数据分配相应的磁盘块,仅仅会查询是否有已经为这些数据分配过磁盘块,以便决定后面是否需要为这些数据分配磁盘块。在用户调用fsync或者系统触发回写过程时,系统会尝试为标记需要分配磁盘块的这些数据分配磁盘块。这样,文件系统可以为这些属于同一个文件的数据分配尽量连续的磁盘空间,从而优化后续文件的访问性能(因为传统机械硬盘顺序读写的性能要比随机读写好很多)。

了解完delalloc特性的工作过程后,我们开始分析线上遇到的问题。线上应用的I/O模式可以简化为一个单线程追加写操作的程序,每秒写入2、3M数据,写操作后等待系统自动将数据回写到磁盘。在使用delalloc后,每次Buffer Write操作,系统都会去查询数据是否分配了磁盘块,这一过程需要获得一把读锁 (i_data_sem)。由于这时还没有触发回写操作,因此可以顺利获取i_data_sem,系统完成数据拷贝工作,并返回。由于仅仅是内存拷贝的过程,所以这一操作速度相当快。当系统开始进行回写操作时,系统会成批为数据分配磁盘块,这一过程同样需要获取i_data_sem,并且需要加写锁?以保证数据的一致性。由于使用delalloc后,需要分配的磁盘块比nodelalloc情况下多很多(nodelalloc情况下每5秒文件系统会提交日志触发回写;delalloc情况下,系统会在约每30秒左右触发一次回写),因此这一延迟时间较长。如果这时应用程序进行一次Buffer Write,则该操作在尝试获得i_data_sem时会等待上述磁盘块分配完成。由此造成写操作等待很长时间,从而影响应用程序的响应延迟。

在上面的分析中已经提到,delalloc是将多次磁盘块分配的过程合并到一次中来进行,那么是否真如预想的那样,delalloc的平均延迟会小于nodelalloc的情况呢?我们使用fio来做如下测试:设置bs=4k,单线程每秒追加写入5M,程序运行3分钟,我们来看一下最后fio对延迟的统计结果:

delalloc:
lat (usec): min=2 , max=193466 , avg= 5.86, stdev=227.91

nodelalloc:
lat (usec): min=3 , max=16388 , avg= 7.00, stdev=28.92

从上面的统计结果看,写操作的平均延迟:打开delalloc后为5.86us,关闭delalloc后为7.00us;最小延迟delalloc为2us,nodelalloc为3us;但是最大延迟delalloc为193.466ms,nodelalloc下仅为16.388ms。可见delalloc确实将多个写操作请求集中到了一起来进行。因此在提供较低平均延迟的情况下,会造成某次写操作的延迟较大。

通过上面的分析可以看到,目前会受到Ext4的delalloc特性影响的应用必须具备如下条件:
0. Buffer IO
1. 写操作过程中会涉及磁盘块的分配,主要是记录日志这类追加写操作;
2. 每次写操作后没有刷新数据,而是等待系统自动进行回写;
3. 对延迟有较高要求。

解决方法:关闭delalloc
1. mount -t ext4 -o remount,nodelalloc /${dev} /${mnt};
2. 编辑/etc/fstab中相关mount项,添加nodelalloc挂载参数

时间: 2024-10-27 05:28:28

ext4文件系统的delalloc选项造成单次写延迟增加的分析的相关文章

Ext4文件系统架构分析(二)

接着上一篇博文,继续分析Ext4磁盘布局中的元数据. 1.7 超级块 超级块记录整个文件系统的大量信息,如数据块个数.inode个数.支持的特性.管理信息,等待. 如果设置sparse_super特性标志,超级块和块组描述符表的冗余备份仅存放在编号为0或3.5.7的幂次方的块组中.如果未设置sparse_super特性标志,冗余备份存在与所有的块组中.以下是2.6.32.18内核中对Ext4超级块的描述: 3.0的内核中,Ext4的超级块加入了以下相关元数据:快照.文件系统错误处理相关.挂载选项

linux操作系统故障处理-ext4文件系统超级块损坏修复

背景 前天外面出差大数据测试环境平台有7台服务器挂了,同事重启好了五台服务器,但是还有两台服务器启动不起来,第二天回来后我和同事再次去机房检查,发现两台服务器都显示superblock的报错,经过一番处理后两台服务器都正常进系统了,现决定重现superblock故障并将此类问题故障处理思路写下来方便后面新同事参考. 硬盘的结构 硬盘的物理结构侧视图和俯视图,这两张图传递出来的比较重要的信息如下: 磁盘划分为磁头(Head),柱面(Cylinder),扇区(Sector) 磁头:每个磁片正反两面各

EXT4文件系统禁用日志功能

ext4提供有很多特性,当然有一些是前一代文件系统ext3本身就具有的,比如日志功能,但有时候我们却并不需要这些特性,则我们可以禁用它们.ext4文件系统的日志功能就是在牺牲一定性能的情况下增强稳定性的一种手段,但在一些情况,比如Web Server上存在的大量小文件所在的文件系统就是一个典型示例,此时可以禁用ext4的日志功能. 关闭EXT4日志功能: [[email protected] ext4]# tune2fs -O ^has_journal /dev/sdd1 tune2fs 1.4

在CentOS6或RHEL6恢复上ext4文件系统误删除的文件

首先说明: [[email protected] ~]# rm -rf / //这条命令不可以执行 [[email protected] ~]# rm -rf /* //这条命令可以执行,别去试 ext4文件系统上误删除文件,可以用extundelete恢复.ext3恢复使用ext3grep.Windows恢复使用final data v2.0汉化版和easyrecovery等. 误删除文件后,第一件事是避免误删除的文件内容被覆盖,这时可以卸载需要恢复文件的分区或以只读的方式挂载. (1).下载

刨根问底:ext3/ext4文件系统最大空间及单个文件大小演算法则

从ext3和ext4文件系统来窥探空间和文件大小的演算法则 学习操作系统就不得不研究磁盘以及磁盘文件系统,磁盘是底层物理设备,而文件系统则是管理磁盘的上层工具,文件系统规划了磁盘存放数据的格式,确定了一个操作系统能够支持多大的磁盘空间,每个分区能够支持多大的数据空间,以及每个文件所能支持的大小.通常对系统管理员而言,最需要的知道的就是最大磁盘空间,最大分区空间以及最大文件的大小.本论题只讨论这三种大小到底是怎么算出来的,而不是死记硬背.知道了原理,以后不管遇到什么文件系统,都会有章可循,至少知道

[深入理解文件系统之十二] ext3文件系统的挂载选项和journal

作为ext2的改进版本,ext3和ext2文件系统相比,最大的改进就是引入了journal功能,这在既提高了文件系统数据和元数据的一致性,又大大缩短了数据一致性检查和恢复的时间. ext3文件系统的mount 选项 只读模式:ro journal选项: journal=update/inum journal_dev=devmum norecovery/noload:不挂载日志分区,可能会挂载上inconsistent file-system. 数据模式:data=journal/ordered/

多选项表单

多选项表单 语法 此时,永远只能接受多选项中的最后一个选项! 因为该选项的属性名只有一个,在接收的时候后面的会覆盖前面的! 解决方案: 在多选项表单中的name属性名字的后面加上一对中括号[] 多选项入库 在user_info表中增加一个字段: 如何将一个数据存储到数据库中呢? 解决方案: 由于mysql没有数组类型,所以,php中的数组需要先转换为字符串才能存入数据库! 使用implode函数!

Ext4文件系统架构分析(一)

本文描述Ext4文件系统磁盘布局和元数据的一些分析,同样适用于Ext3和Ext2文件系统,除了它们不支持的Ext4的特性外.整个分析分两篇博文,分别概述布局和详细介绍各个布局的数据结构及组织寻址方式等.感兴趣的看官敬请留意和指导! 1. Ext4文件系统布局综述 一个Ext4文件系统被分成一系列块组.为减少磁盘碎片产生的性能瓶颈,块分配器尽量保持每个文件的数据块都在同一个块组中,从而减少寻道时间.以4KB的数据块为例,一个块组可以包含32768个数据块,也就是128MB. 1.1 磁盘布局 Ex

Ext4文件系统的特性

与Ext3文件系统兼容:原有的Ext3数据结构仍然照样保留,Ext4作用于新数据,整个系统因此也就获得了Ext4所支持的更大的容量 更大额文件系统和更大的文件:Ext3目前所支持的最大16TB文件系统和最大2TB文件,Ext4分别支持1EB的文件系统,16TB的文件(1EB=1024PB,1PB=1024TB). 无限数量的子目录.Ext3支持32000个子目录,Ext4不限制 Extents:Ext3采用间接块映射,当操作大文件时,效率极其低下.比如一个100M的文件.在Ext3中要建立256