Hadoop 服务SYS CPU过高导致宕机问题

gmdzxx

　　最近某hadoop集群多次出现机器宕机，现象为瞬间机器的sys cpu增长至100%，机器无法登录。只能硬件重启，ganglia cpu信息如下：

　　首先怀疑有用户启动了比较奇葩的job，导致不合理的系统调用出现的问题。随后加了ps及pidstat信息收集job信息（公共集群蛋疼的地方），然后出现问题的时候，各类脚本已经无法工作，
　　一直没有抓到现场。
　　终于在某一次看到一台机器sys 瞬间增长，且机器还能登录。立马查看现场，发现竟然元凶是datanode：datanode一个进程占用cpu 1600%，sys cpu占用超过40%
　　
　　Datanode的进程栈信息，大量dataxceiver线程block，并且都是在发送数据块过程中 getVisibleLength操作：
　　"DataXceiver for client /10.16.136.65:34464 [sending block blk_341818443393496218_612191861]" daemon prio=10 tid=0x00007f7500a33000 nid=0x4135 waiting for monitor entry [0x00007f74ec5a5000]
　　java.lang.Thread.State: BLOCKED (on object monitor)
　　at org.apache.hadoop.hdfs.server.datanode.FSDataset.getVisibleLength(FSDataset.java:1116)
　　- waiting to lock  (a org.apache.hadoop.hdfs.server.datanode.FSDataset)
　　at org.apache.hadoop.hdfs.server.datanode.BlockSender.(BlockSender.java:118)
　　at org.apache.hadoop.hdfs.server.datanode.DataXceiver.readBlock(DataXceiver.java:271)
　　at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:176)
　　Locjava:118)
　　at org.apache.hadoop.hdfs.server.datanode.DataXceiver.writeBlock(DataXceiver.java:394)
　　at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:184)
　　Locked ownable synchronizers:
　　- None
　　从这里看，似乎并没有什么问题，只是大量线程堵塞在文件的操作上。问题依然没有进展。
　　这样大概持续了一段时间，发现出问题的机器有一个共同点，dmesg信息有大量此类log：
　　shrink_slab: xfs_buftarg_shrink+0x0/0x160 [xfs] negative objects to delete nr=-6
　　参考：http://www.ibm.com/developerworks/cn/linux/l-cn-pagerecycle/
　　函数 shrink_slab()
　　函数 shrink_slab() 是用来回收磁盘缓存所占用的页面的。Linux 操作系统并不清楚这类页面是如何使用的，所以如果希望操作系统回收磁盘缓存所占用的页面，那么必须要向操作系统内核注册 shrinker 函数，shrinker 函数会在内存较少的时候主动释放一些该磁盘缓存占用的空间。函数 shrink_slab() 会遍历 shrinker 链表，从而对所有注册了 shrinker 函数的磁盘缓存进行处理。
　　从实现上来看，shrinker 函数和 slab 分配器并没有固定的联系，只是当前主要是 slab 缓存使用 shrinker 函数最多。
　　也就是这些dmesg信息应该是在内存回收磁盘缓存页面阶段出现的。
　　而看到某数字公司的一篇文章，同为hadoop服务sys cpu过高：
　　http://blogs.360.cn/360xitong/2013/03/26/hadoop%E9%9B%86%E7%BE%A4system-cpu%E6%B6%88%E8%80%97%E8%BF%87%E9%AB%98%E9%97%AE%E9%A2%98%E5%88%86%E6%9E%90-by-%E6%9D%82%E8%B4%A7%E5%BA%97%E5%BA%97%E9%95%BF/
　　作者追查的原因为compact_zone，同样为内存管理。
　　并且IBM提到了CFS对java性能的影响：
　　http://www-01.ibm.com/support/docview.wss?uid=swg21372909
　　处理的办法是/proc/sys/kernel/sched_compat_yield置为1，而RHEL6上面貌似这个参数已经不生效。
　　综上，可以基本推断出，这个问题跟RHEL6的内存管理密切相关。我们对RHEL6内存管理相关的的参数调整：
　　（1）   关闭大页内存：echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag && echo never >  /sys/kernel/mm/redhat_transparent_hugepage/enabled
　　（2）   Vfs_cache置为零：/sbin/sysctl vm.vfs_cache_pressure=0
　　于是从内存管理入手，首先调整了vm.vfs_cache_pressure，将其改回默认值100，观察一天，果然dmesg里shrink_slab相关信息消失，并且改过的机器没有出现过宕机。因此问题定位为
　　内存cache回收。此参数在RHEL5上运行时一直置为0并运行平稳，RHEL6真是坑人啊。。
　　我们将vm.vfs_cache_pressure置为0，目的是让系统不要主动回收cache，以使hadoop进程有足够多的内存cache。对datanode和task性能有比较好的提升。如果恢复回默认值，性能会有很大的下降，用户又不干了。于是经过测试，将vm.vfs_cache_pressure调整为5--10，这样系统会倾向于主动回收一部分cache，同时hadoop也有足够的cache供进程用。也再没有出现sys cpu升高导致的宕机问题。