基于ext3文件系统的mysql服务器,通过iotop发现,有个jbd2进程占用大量的IO资源,而非mysql进程自身消耗的IO导致。如图所示:
进程jbd2占用了部分IO,导致数据盘IO异常繁忙。网络上的解决方法如下:
先给出解决方案,处理此问题的优先级为:
1、yum update kernel 用yum升级系统内核,重启之后查看是否有效;
2、缓解方法:修改commit值,降低文件系统提交次数或者禁用barrier特性;
建议文件系统参数为:defaults,noatime,nodiratime,barrier=0,data=writeback,commit=60
(可以通过修改fstab表或者remount重新挂载)
3、慎用方法:关闭文件系统日志功能 tune2fs -O "^has_journal"
例如: tune2fs -O "^has_journal" /dev/mapper/VolGroup-lv_home
通过查资料,整理相关信息,解释如下;
1、jbd的全拼是journaling block driver 文件系统的日志功能,jbd2是ext4文件系统版本;可以肯定的是对文件系统的操作太频繁,导致IO压力过大。
常用的文件系统使用日志功能来保证文件系统的完整性,在写入新的数据到磁盘之前,会先将元数据写入日志;这样做可以保证在写入真实数据前后,一旦发生错误,日志功能将很容易回滚到之前的状态,确保不会发生文件系统崩溃的情况。而现在的磁盘上一般都配有内部缓存,以便重新调整批量数据的写入顺序,优化写入性能,因此文件系统必须在日志数据写入磁盘之后才能写commit(commit=xx 每xx秒同步所有的数据和元数据。默认是每5秒)记录;若commit记录写入在先,而日志有可能损坏,就会影响数据完整性;EXT4文件系统默认启用barrier功能,只有当barrier之前的数据全部写入磁盘,才能写barrier之后的数据;barrier的存在保证了数据完整性;
3、使用barrier特性的不利之处在于,需要付出降低性能的代价;可以通过挂载项 mount -o barrier=0来禁用此特性;
可通过查看/proc/mounts里的barrier值 为1代表启用
4、文件的写和请求会导致其中一个int型的值不断增大,最后超出了自身范围---变成负值,就会触发该bug;
具体原理参考下链接:
5、所以我们可以通过降低文件系统的提交次数来缓解IO压力(相关参数commit);或者禁用barrier特性(相关参数barrier=0 );
尝试了升级内核的方式,并没有效果。后来通过一个数据盘扩容的工程,替换了一块xfs格式的磁盘后,效果如下:
不过还是建议在原先的环境中采用xfs的文件系统,避免由于采用ext4文件系统触发这个bug.