问题在很多MySQL实践中，或者在压力测试中，尤其是直接从centos官方DVD下载安装的linux，可能会遇到这样的问题，为什么有些机器硬件性能很好，数据库存储的速度比那些性能不好的机器要快。从MySQLWorkbench的工具可以看出，实时入库记录的数量可能只有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命令查看硬盘的性能。可以输入小写的“o”过滤不操作硬盘的进程，然后使用方向键移动按“IO”排序。这个排序是按百分比排序的，如下图，也可以看出是哪个命令导致的。说明问题虽然上图不是99%，但我只是举个例子。如果你在有问题的linux上操作数据库，即使你没有操作数据库，操作硬盘也只是一个很简单的命令，而且会显示99%。%IO命令，即jbd2/sda6-8（我只是举个例子，你看到的命令可能和我的不完全一样，但是一定要以jbd2开头，反斜杠后面是哪个分区，这个分区很important，后面关闭jbd2时需要指定分区）。于是我百度了一下jbd2到底是什么东西。原来jbd2的全称是journalingblockdriver。这个过程实现了文件系统的日志功能，磁盘使用日志功能来保证数据的完整性。这就需要评估哪个更重要，安全性还是性能。对于应用服务器来说，它并不保存重要的用户数据，只是实现业务逻辑。如果是数据库，需要考虑启动盘写入的完整性检查。但是现在大多数系统已经在业务和架构层面考虑了业务完整性。所以从性能上来说，这里开启日志功能的必要性不是很大。解决办法是关掉jdb2。关闭的步骤是：先使用dumpe2fs/dev/sda6|more检查FilesystemFeature下是否有has_journal。没有的话就别看了-_-tune2fs-ojournal_data_writeback/dev/sda6tune2fs-O"^has_journal"/dev/sda6e2fsck-f/dev/sda6同时在fstab下reset一下，添加defaults,data=afterdefaults重启writeback、noatime、nodiratime后，使用dumpe2fs查看，如果没有，说明jbd已经关闭。经过Linux的上述处理，数据库可以将插入速度从原来的20~200速度提高到2000~3000速度左右。如果Troubleshoot使用tune2fs，会提示正在挂载磁盘。如果是非系统分区，可以使用fuser-km/home#kill所有使用/home的进程umount/dev/sda6#umount如果是系统分区，也就是/目录下，比较麻烦.我还没有操作过，不过我在谷歌上找到的方法大概是放入安装光盘，进入命令界面进行操作。希望这篇文章对你有所帮助。朱春琪
