分享一下我们这边实际碰到的问题；物理机centos7，vm 5.8不定时crash；vm6.3没有问题（相对较少6.3的vm)；不限定特定主机；
看看有无同行碰到过同样的问题；
如果有同行碰到过类似问题，希望可以分享；
后续也会更新我们这边的进展；分享具体结论；
1.问题
现在看到centos 7 + local disk下面的vm 发生不定时crash；
2.排查
由于出现问题的VM与宿主机都不固定，也没有找到有用的日志。暂时无法定位原因。
参考过往对CentOS 5.8 的处理方法，打开sysrsq：
[root@lfk-test-bftn9 ~]#vim /etc/sysctl.conf kernel.sysrq = 1
关闭ACPI 和APIC：
[root@lfk-test-bftn9 ~]#cat /boot/grub/menu.lst default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-308.el5) root (hd0,0) kernel /vmlinuz-2.6.18-308.el5 ro root=LABEL=/ console=tty0console=ttyS0,115200 acpi=off noapic initrd /initrd-2.6.18-308.el5.img
重启系统后，暂时正常，继续观察。
2015-05-18 更新
从目前收集的信息来看，怀疑两方面的问题：
CentOS 7.0 kernel 与 5.8 kernel 存在兼容性问题；
Centos5.8_2.9.5 (c6ce9208-70d4-4b67-ad0a-a82927dcd5b7)这个镜像有问题。
宿主机上看不到报错的信息，而且随机性很强，暂时排除硬件的原因。（新和旧的机器都出现过）
出现问题时，从实例vm 的sar 来看，负载很低，而且并不是只有allinone环境的实例报错，暂时排除allinone的应用导致的。
大多报错与文件系统、tail、syslog 等磁盘读写有关。
后续工作：
在相同硬件的CentOS 7.0+local disk 的环境下，扫描一下Centos5.8_2.9.5(c6ce9208-70d4-4b67-ad0a-a82927dcd5b7) 镜像的文件系统；
创建几台测试实例，分别对CPU、内存、磁盘进行压力测试，看看是否可重现问题；
查看其它使用相同镜像的实例，flume 和puppet agent ，以及tail 等进程的使用情况；（5.14的发生flume故障时，曾发现出问题的实例java 占用100% 的情况）
2015-05-19 更新
1.工作一
再次发生几台实例crash，日志都是类同的：
xxxx.com login: INFO: task pdflush:672 blocked for more than 120seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables thismessage. pdflush Dffff81000102e4a0 0 672 327 673 671 (L-TLB) ffff81081eab3700 00000000000000460000000000000000 ffff81081d48edf8 0000000000000001 000000000000000affff81081e8e7080 ffff81081fd13100 0006cab7fd263194 0000000000009ecbffff81081e8e7268 0000000500000000 Call Trace:
怀疑与下面的问题相关：
This is a know bug. By default Linux uses up to 40% of theavailable memory for file system caching. After this mark has beenreached the file system flushes all outstanding data to diskcausing all following IOs going synchronous. For flushing out thisdata to disk this there is a time limit of 120 seconds by default.In the case here the IO subsystem is not fast enough to flush thedata withing 120 seconds. This especially happens on systems with alof of memory.
The problem is solved in later kernels and there is not “fix” fromOracle. I fixed this by lowering the mark for flushing the cachefrom 40% to 10% by setting “vm.dirty_ratio=10″ in /etc/sysctl.conf.This setting does not influence overall database performance sinceyou hopefully use Direct IO and bypass the file system cachecompletely.
出问题的实例内存很大，使用率很高：
[root@xxxx~]# sar -r 13时10分01秒 169168 32796884 99.49 863736 23244036 2097144 0 0.00 0 13时20分01秒 154224 32811828 99.53 811532 23053024 2097144 0 0.00 0 13时30分01秒 257356 32708696 99.22 635740 22885924 2097144 0 0.00 0 13时40分01秒 155792 32810260 99.53 635592 22731708 2097144 0 0.00 0 13时50分01秒 156572 32809480 99.53 635388 22503648 2097144 0 0.00 0 14时00分01秒 156200 32809852 99.53 635356 22271256 2097144 0 0.00 0 14时10分01秒 157112 32808940 99.52 635360 22060060 2097144 0 0.00 0 14时20分01秒 158316 32807736 99.52 635308 21869940 2097144 0 0.00 0 14时30分01秒 262296 32703756 99.20 634600 21554044 2097144 0 0.00 0 Average: 2401241 30564811 92.72 843758 23101230 2097144 0 0.00 0
在CentOS 5.8 下，vm.dirty_ratio 默认值为 40.参考上文，把参数值修改为10，加快内存回收的速度，减少cache 占用内存的比例。
已经通过Puppet 推送到所有CentOS 5.8 及通过SaltStack 推送到QA 的VM，待反馈。
2.工作二
在130191 上创建使用使用相同CentOS 5.8 的镜像，不间断运行 bonnie++ 进行IO 测试，尝试重现问题；
3.工作三
检查文件系统，出现问题的实例，文件系统都有少部分的日志损坏，但原镜像创建的实例没有问题。暂时不确定损坏是由于crash还是其他服务导致的；
4.工作四
由Puppet 管理的VM ，Flume 都已经更新到最新的版本。使用sudo tail 方式运行。
5. 升级一部分VM的kernel 到5.11的更新版本；
email Thread:
发生的时间记录如下：
查看宿主机和VM 都没有记录错误日志，也没有硬件错误日志。
已知的情况是，出现问题的宿主机都是CentOS 7 + local disk。
从VM 的console-log 本地终端上查看到的日志都是类同的（见福康上午的邮件），但日志不完整。
完整的日志可能是类似下面的：
Sep 19 02:08:10 xxx kernel: INFO:task kjournald:2296 blockedfor more than 120 seconds. Sep 19 02:08:10 xxx kernel: "echo 0 >/proc/sys/kernel/hung_task_timeout_secs" disables thismessage. Sep 19 02:08:10 xxx kernel: kjournald D ffff810001025e20 0 2296 972557 2287 (L-TLB) Sep 19 02:08:10 xxx kernel: ffff81022f071cf0 00000000000000460000000000000086 ffffffff8003da83 Sep 19 02:08:10 xxx kernel: 0000000000000000 000000000000000affff81022aa3a100 ffff81022fe2a080 Sep 19 02:08:10 xxx kernel: 0001c465c04872e3 000000000000202dffff81022aa3a2e8 000000042fa7a478 Sep 19 02:08:10 xxx kernel: Call Trace: Sep 19 02:08:10 xxx kernel: [] lock_timer_base+0x1b/0x3c Sep 19 02:08:10 xxx kernel: [] do_gettimeofday+0x40/0x90 Sep 19 02:08:10 xxx kernel: [] sync_buffer+0x0/0x3f Sep 19 02:08:10 xxx kernel: [] io_schedule+0x3f/0x67 Sep 19 02:08:10 xxx kernel: [] sync_buffer+0x3b/0x3f Sep 19 02:08:10 xxx kernel: [] __wait_on_bit+0x40/0x6e Sep 19 02:08:10 xxx kernel: [] sync_buffer+0x0/0x3f Sep 19 02:08:10 xxx kernel: []out_of_line_wait_on_bit+0x6c/0x78 Sep 19 02:08:10 xxx kernel: [] wake_bit_function+0x0/0x23 Sep 19 02:08:10 xxx kernel: [] :jbd:journal_commit_transaction+0x543/0x1066 Sep 19 02:08:10 xxx kernel: [] lock_timer_base+0x1b/0x3c Sep 19 02:08:10 xxx kernel: []try_to_del_timer_sync+0x7f/0x88 Sep 19 02:08:10 xxx kernel: [] :jbd:kjournald+0xc1/0x213 Sep 19 02:08:10 xxx kernel: []autoremove_wake_function+0x0/0x2e Sep 19 02:08:11 xxx kernel: []keventd_create_kthread+0x0/0xc4 Sep 19 02:08:11 xxx kernel: [] :jbd:kjournald+0x0/0x213 Sep 19 02:08:11 xxx kernel: []keventd_create_kthread+0x0/0xc4 Sep 19 02:08:11 xxx kernel: [] kthread+0xfe/0x132 Sep 19 02:08:11 xxx kernel: [] child_rip+0xa/0x11 Sep 19 02:08:11 xxx kernel: []keventd_create_kthread+0x0/0xc4 Sep 19 02:08:11 xxx kernel: [] kthread+0x0/0x132 Sep 19 02:08:11 xxx kernel: [] child_rip+0x0/0x11 Sep 19 02:08:11 xxx kernel: