最近新采購的一批機器，由于intel cpu體系架構的改變，新機器的系統需要升級，選擇了CentOS 6.2系統。
1 在新機器上將MR業務開啟后，導致整個集群都反應很慢，運行的job幾乎都被卡住；通過ganglia監控發現，機器的system cpu超過30%，機器幾乎是滿負載的情況。
原因分析：
RHEL 6.2和6.3系統中包含了一個新特性，被稱為“transparent hugepage compaction”，它和Hadoop負載不能很好的交互。相比于其他的
操作系統，這導致了嚴重的性能損失。Red Hat會在未來的更新中解決此問題。
解決方法：把如下命令增加到開機啟動中。
echo always > /sys/kernel/mm/redhat_transparent_hugepage/enabled echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag |
2 解決上述問題，把MR業務開啟一段時間后，經常出現某個task卡死的情況，job會一直hang住，查看TT日志
2013-08-2006:12:31,050INFO org.apache.hadoop.mapred.TaskLogsTruncater: Initializing logs' truncater withmapRetainSize=-1and reduceRetainSize=-1 2013-08-2006:12:31,053FATAL org.apache.hadoop.mapred.Child: Error running child : java.lang.OutOfMemoryError: unable to create newnative thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:640) at org.apache.hadoop.mapred.ReduceTask$ReduceCopier.fetchOutputs(ReduceTask.java:1932) at org.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:382) at org.apache.hadoop.mapred.Child$4.run(Child.java:270) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1157) at org.apache.hadoop.mapred.Child.main(Child.java:264) |
從上面的
日志看，是OOM的錯誤，不能創建新的進程。但查看該TT機器，內存充足，應該不是內存導致的問題。
后來又check了環境的配置，發現在以前RHEL 5.4系統中生效的ulimit的nproc限制，在新系統中并沒有生效（可以通過ulimit -u查看）。google后得知，6.2系統中修改了這一配置，新的配置需要在里/etc/security/limits.d/90-nproc.conf設置生效。
[hdfs@hd0447-sw40 ~]$ cat /etc/security/limits.d/90-nproc.conf # Default limit fornumber of user's processes to prevent # accidental fork bombs. # See rhbz #432903for reasoning. * soft nproc 1024 |
在處理hadoop前期環境的時候，發現有些機器在沒有業務的情況下機器負載很高的情況，這里也記錄一下。
1. 通過top命令發現plymouthd進程cpu負載達到近100%
解決方法：打開 /boot/grub/menu.lst , 去掉 “rhgb quiet”這兩個參數 ，然后重啟
2.power_saving死鎖引起的高負載
解決方法：
方法1：rmmod acpi_pad，重啟機器，機器將不支持電源節能；
方法2：在BIOS中開啟ACPI支持，重啟，更新內核至2.6.32-358.2.1.el6.x86_64；
方法3：在BIOS里設置禁用；
方法4：要將驅動程序列入黑名單，編輯 /etc/modprobe.d/blacklist.conf，然后添加blacklist acpi_pad。
開始使用方法1，解決了大多數機器power_saving死鎖的問題，有些機器的整體負載還是會保持在10%以上，查看后發現還有部分power_saving進程，采用方法4，問題得以解決