2018年第九周-解决因jbd2导致Linux性能过低问题

问题

在很多MySQL实践中，或者压测中，特别是从centos官方下载DVD直接安装的linux，可能会遇到这样一个问题，为什么有些机子硬件性能很好的，数据库入库的速度比那些不好的机子还快。从MySQL Workbench的工具能够看出实时的入库记录数，可能才20~200多条，这速度太慢了。于是怀疑是不是数据库配置问题，等把InnoDB缓存等MySQL配置一模一样之后，这样的问题还是存在。于是就用top、iotop等工具查看到底是为什么。

定位问题过程

当运行在Linux系统下的进程出现性能问题时，一般可以从以下几个方面定位问题：
1.CPU，这里可以使用top命令，top命令详解传送门。

使用top命令，查看下CPU是不是到达性能瓶颈，在top命令运行中，输入大写"P"根据CPU使用大小进行排序进程。

2.内存，在这个问题中，我们可以从top命令就可以看到其实内存还是有余的，也可以使用free -m查看内存情况

3.在top命令后，发现cpu和内存都毫无性能压力的情况下，于是检查下硬盘io，这里使用iotop命令

使用iotop命令，查看硬盘性能，可输入小写“o”过滤没有操作硬盘的进程，再使用方向键盘挪动到按“IO”排序，这个排序是按百分比排序，如下图所示，还可以看到是哪个命令所导致的。

解释问题

上面那张图虽然没有99%，我只是简单举个例子而已，如果你在一个有问题的Linux操作数据库，哪怕你不是操作数据库，只是个很简单的操作硬盘的命令，都会展示出99%的IO的命令，那就是jbd2/sda6-8（我这举个例子而已，你的看到的命令可能不是跟我一模一样，但一定是jbd2开头的，反斜杠后面指的是哪个分区，这个分区很重要，后面关闭jbd2时需要指定分区）。于是我百度下jbd2是什么鬼东西。

原来jbd2的全称是journaling block driver 。这个进程实现的是文件系统的日志功能，磁盘使用日志功能来保证数据的完整性。这个需要评估一下安全和性能哪个更重要，对于一个应用服务器来说，并不保存重要的用户数据，只是实现业务逻辑。如果是数据库的话，就需要考虑启动磁盘写入的完整性检查。但是现在大部分系统在业务和架构层面已经考虑了业务完整性。所以为性能计，这里并不是非常有必须启动日志功能。

解决方法

于是我就把jdb2给关掉，关掉步骤是：
首先用 dumpe2fs /dev/sda6 | more 查看Filesystem Feature下有木有has_journal。如果没有就不用看了 -_-

tune2fs -o journal_data_writeback /dev/sda6

tune2fs -O "^has_journal" /dev/sda6

e2fsck -f /dev/sda6

同时在fstab下重新设定一下，在defaults之后增加

defaults,data=writeback,noatime,nodiratime

重启之后，在使用dumpe2fs查看，若没有了，那说明已经把jbd关闭了。

经过上述处理后的Linux，数据库可以从原本的20~200速率的插入速度，提高到2000~3000左右的速度。

Troubleshoot

如果使用tune2fs时候，提示disk正在mount，如果是非系统分区下，你可以使用

fuser -km /home #杀死所有使用/home下的进程

umount /dev/sda6 #umount

如果是系统分区，也就是/目录下的，那就麻烦了，我还没操作过，但谷歌到的方法大概是，放入安装光盘，进入命令界面来操作的。

希望这篇文章对您有帮助。
祝春祺