系统hung住排查解决

@系统hung住解决

message下报错：
kernel: INFO: task jbd2/sdb1-8:966 blocked for more than 120 seconds.
kernel: “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message.

背景：
服务器响应突然变得非常迟钝。
收集日志信息来看了一下cpu 和内存的使用率不高

http://blog.ronnyegner-consulting.de/2011/10/13/info-task-blocked-for-more-than-120-seconds/comment-page-1/
原因：这个是IO问题导致的
由上面的日志可以看到是由jbd2/sdb1-9:996 引发的问题，cd /proc/996/线程目录下，

这个是EXT4文件系统的日志进程
sdb1分区发生日志启用功能
jbd2的，全称是journaling block driver 。这个进程实现的是文件系统的日志功能，磁盘使用日志功能来保证数据的完整性

这是一个众所周知的错误。默认情况下，Linux使用高达40%的可用内存来进行文件系统缓存。达到此标记后，文件系统将所有未完成的数据刷新到磁盘，导致所有后续IOs同步。对于将该数据刷新到磁盘，默认有120秒的时间限制。在这种情况下，IO子系统的速度不足以在120秒内刷新数据。这尤其发生在具有大量内存的系统上

通过设置将缓存刷新的标记从40%降低到10%来解决这个问题。在/etc/sysctl.conf 中设置vm.dirty_ratio = 10”。此设置不影响总体数据库性能，因为您希望使用直接IO并完全绕过文件系统缓存。

解决：
sysctl -a | grep dirty

在/etc/sysctl.conf 中设置vm.dirty_ratio = 10” vm.dirty_background_ratio=5

立即生效：

sysctl -p

永久修改（需要reboot生效）：

vi /etc/sysctl.conf //在此文件的最后添加两行

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

reboot

或者关闭日志功能
#检查文件系统是否带有系统日志功能
#dumpe2fs /dev/vda | grep ‘Filesystem features’ | grep ‘has_journal’
关闭功能
#tune2fs -O ^has_journal /dev/vda

或者修改磁盘挂载时的参数commit 默认为5s
可以修改/etc/fstab 来增加mount时的参数 或者禁用barrier特性（还是不要禁用的好）

现在的磁盘上一般都配有内部缓存，以便重新调整批量数据的写入顺序，优化写入性能，因此文件系统必须在日志数据写入磁盘之后才能写commit（commit=xx 每xx秒同步所有的数据和元数据。默认是每5秒）记录；若commit记录写入在先，而日志有可能损坏，就会影响数据完整性；EXT4文件系统默认启用barrier功能，只有当barrier之前的数据全部写入磁盘，才能写barrier之后的数据；barrier的存在保证了数据完整性；

附：
网上有人发现：
用iotop查看发现[jbd2/dm-2-8]几乎占用了99%的io使用率，但是却没有输入输出
使用
#dstat --aio --io --disk --tcp --top-io-adv --top-bio-adv 和#iostat 2个命令进行排查
他的原因是MySQL开启了sync_binlog参数导致事务提交后，刷新到磁盘时IO太高了

注：
vm.dirty_background_ratio:这个参数指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如5%）就会触发pdflush/flush/kdmflush等后台回写进程运行，将一定缓存的脏页异步地刷入外存；

vm.dirty_ratio:而这个参数则指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如10%），系统不得不开始处理缓存脏页（因为此时脏页数量已经比较多，为了避免数据丢失需要将一定脏页刷入外存）；在此过程中很多应用进程可能会因为系统转而处理文件IO而阻塞

之前一直错误的一位dirty_ratio的触发条件不可能达到，因为每次肯定会先达到vm.dirty_background_ratio的条件，后来才知道自己理解错了。确实是先达到vm.dirty_background_ratio的条件然后触发flush进程进行异步的回写操作，但是这一过程中应用进程仍然可以进行写操作，如果多个应用进程写入的量大于flush进程刷出的量那自然会达到vm.dirty_ratio这个参数所设定的坎，此时操作系统会转入同步地处理脏页的过程，阻塞应用进程