在没有解决bug之前，你永远不知道bug到底是怎么产生的。
问题缘起: 当我习惯性地用top查看任务运行状态时，发现我运行的100个任务，只有3个在运行，其他都在摸鱼状态。同时发现我的任务进程都是"D"状态(未截图)，而不是R(运行)状态。
这个时候，我直觉上感觉这是硬盘读写除了问题，于是我开始检索查找相关工具去验证我的猜想
先用的是iostat -x 2 10，如果%util 接近100%说明产生的I/O请求太多，I/O系统满负荷，%idle小于70%，IO压力就很大。
从上图明显发现我的IO压力过大。当然作为科研人员，我们都知道我们需要多个证据才能证实自己的猜想，于是进一步用iotop, 发现有许多进程的IO居然是99%.
既然确定服务器性能下降的原因是IO。那么下一步就是找到导致磁盘压力过大的真凶。用dstat --top-bio-adv找到那个进程占用IO最多， 此处发现是jdb2/sda1-8 的写出数据超多
利用关键字"jdb2/sda1-8"经过搜索，发现很多人都遇到这种情况，
- 有些认为是RAID磁盘矩阵导致的问题
- 有人认为是MySQL的问题。
刚好，我的服务器是RAID，又刚好我今天改动了MySQL。但是直觉告诉我，应该不是这两个问题，因为我虽然改了MySQL的配置文件，但是我基本不用MySQL, 所以排除这个可能。
但是，目前我已经顺利确认就是"jdb2/sdax-y"的问题(x表示是分区)，于是我就主要检索了jdb2
jbd2的全称是journaling block driver 。这个进程实现的是文件系统的日志功能，磁盘使用日志功能来保证数据的完整性。这个需要评估一下安全和性能哪个更重要，对于一个应用服务器来说，并不保存重要的用户数据，只是实现业务逻辑。如果是数据库的话，就需要考虑启动磁盘写入的完整性检查。但是现在大部分系统在业务和架构层面已经考虑了业务完整性。所以为性能计，这里并不是非常有必须启动日志功能。
网络上的人提供了如下三种解决方案:
- 升级内核
- 更改commit的次数， "mount -o remount,commit=60 /dev/sda1"
- 关闭文件系统日志功能: 操作类似于
dumpe2fs获取文件系统属性信息,tune2fs调整文件系统属性, 之后e2fsck检查文件系统(几乎大部分都不推荐这样做)
当然这些方案，我一个都没有采纳，因为我突然想到今天服务器上似乎运行了许多IO操作很频繁的程序，jdb2的特点就是牺牲了性能保证了数据完整性，也就是说是我运行的程序太多让jdb2忙不过来了。
因此我的最终解决方案就是，用kill把所有当前运行的高IO程序都干掉。最后解决了问题。
