CentOS6上Hadoop集群中服务器cpu sys态异常的定位与解决
問題現象
定位分析
1. 根據zabbix系統中cpu sys很高的問題發生時間,找到觸發問題的大Job,以便于后面的問題重現和問題驗證;
2. 對問題節點hadoop_A的硬件信息和OS系統日志/var/log/messages進行初步檢查,并未發現異常;
3. 重啟Job,重現問題。并使用nmon工具對問題節點hadoop_A的資源負載進行粗粒度的實時監測;
4. 通過上圖,注意到網絡流量達到了119.7MB/s,接收和發送的峰值都超過了120MB/s,初步懷疑網口在某一時間成為瓶頸,導致內核的sys過高。對hadoop_A的網口計數器細化分析,系統在uptime了83天的狀態下,網口計數器中除overruns指標達22萬之外,其他的網絡指標正常。 這說明網絡確實曾達到過峰值,也丟過包,但頻率非常低,sys過高的問題應該不是網絡負載過高觸發。
5. 需要對系統進行更細粒度的分析,找出系統sys態消耗在什么地方。在hadoop_A節點上部署perf工具,通過perf top對kernel事件采樣,實時分析內核事件。
通過perf top監控可以斷定:kernel中存在頻繁的spin_lock_irqsave內核系統調用, sys態消耗過高應該與此有關。
6. 重啟Job,再次重現問題,并利用perf工具對內核函數的調用關系采樣:
perf record -a -g -F 1000 sleep 30
采樣結束后,在當前目錄上會生成一個perf.data文件,使用perf工具查看函數調用關系:
perf report -g
7. 通過調用依賴關系分析,spin_lock_irqsave主要called by compaction_alloc,初步推測問題由kernel的內存管理部分觸發。聯想到centos 6相對于centos 5在kernel內存管理模塊的一些改進點(如transparent huge page, 基于numa的內存分配等),有沒有可能是CentOS6新增的THP特性導致cpu sys過高?再在google上搜一把相關函數名的關鍵字,印證這個猜測。
問題驗證
1. 選擇在節點hadoop_A上面做驗證測試,通過以下內核參數優化關閉系統THP特性:
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag2. 重啟觸發問題的大Job,在hadoop_A節點未出現cpu sys 狀態過高的現象。
3. 在生產系統上運行24小時后,通過zabbix系統觀察,其他內核未優化節點如hadoop_B,hadoop_C等節點依然存在cpu sys態過高的問題,而關閉了THP特性的hadoop_A節點沒有出現cpu sys態過高的問題,驗證了之前的分析。
結論
將 Hadoop 集群中所有 CentOS6 類型節點的 THP 特性關閉掉 (在 CentOS6 中,THP特性默認都是打開的),關閉方法如下:
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag值得注意的是,需要在 puppet 系統中部署該項優化,以免節點重啟導致修改丟失。
參考
事后,在redhat官網和cloudera官網也搜到了相關的內容,附錄下來,供參考。
- https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-transhuge.html
- http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/4.2.2/CDH4-Installation-Guide/cdh4ig_topic_11_6.html
總結
以上是生活随笔為你收集整理的CentOS6上Hadoop集群中服务器cpu sys态异常的定位与解决的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: YUI事件体系之Y.Do
- 下一篇: Toast与Snackbar的那点事