問題現(xiàn)象

在zabbix系統(tǒng)中，對(duì)Hadoop集群的歷史監(jiān)控?cái)?shù)據(jù)分析時(shí)，發(fā)現(xiàn)在執(zhí)行大Job任務(wù)時(shí)，某些服務(wù)節(jié)點(diǎn)的cpu sys態(tài)很高；

具體以hadoop_A服務(wù)節(jié)點(diǎn)為例，在10:15-10:40這個(gè)時(shí)間段，cpu user態(tài)為60%，而sys態(tài)則高達(dá)35%；

對(duì)于整個(gè)Hadoop集群，并不是所有的節(jié)點(diǎn)都會(huì)出現(xiàn)sys過高的問題，產(chǎn)生此類問題的都是部署CentOS6系統(tǒng)的節(jié)點(diǎn)。

定位分析

1. 根據(jù)zabbix系統(tǒng)中cpu sys很高的問題發(fā)生時(shí)間，找到觸發(fā)問題的大Job，以便于后面的問題重現(xiàn)和問題驗(yàn)證；

2. 對(duì)問題節(jié)點(diǎn)hadoop_A的硬件信息和OS系統(tǒng)日志/var/log/messages進(jìn)行初步檢查，并未發(fā)現(xiàn)異常；

3. 重啟Job，重現(xiàn)問題。并使用nmon工具對(duì)問題節(jié)點(diǎn)hadoop_A的資源負(fù)載進(jìn)行粗粒度的實(shí)時(shí)監(jiān)測(cè)；

4. 通過上圖，注意到網(wǎng)絡(luò)流量達(dá)到了119.7MB/s，接收和發(fā)送的峰值都超過了120MB/s，初步懷疑網(wǎng)口在某一時(shí)間成為瓶頸，導(dǎo)致內(nèi)核的sys過高。對(duì)hadoop_A的網(wǎng)口計(jì)數(shù)器細(xì)化分析，系統(tǒng)在uptime了83天的狀態(tài)下，網(wǎng)口計(jì)數(shù)器中除overruns指標(biāo)達(dá)22萬之外，其他的網(wǎng)絡(luò)指標(biāo)正常。 這說明網(wǎng)絡(luò)確實(shí)曾達(dá)到過峰值，也丟過包，但頻率非常低，sys過高的問題應(yīng)該不是網(wǎng)絡(luò)負(fù)載過高觸發(fā)。

5. 需要對(duì)系統(tǒng)進(jìn)行更細(xì)粒度的分析，找出系統(tǒng)sys態(tài)消耗在什么地方。在hadoop_A節(jié)點(diǎn)上部署perf工具，通過perf top對(duì)kernel事件采樣，實(shí)時(shí)分析內(nèi)核事件。

通過perf top監(jiān)控可以斷定：kernel中存在頻繁的spin_lock_irqsave內(nèi)核系統(tǒng)調(diào)用, sys態(tài)消耗過高應(yīng)該與此有關(guān)。

6. 重啟Job，再次重現(xiàn)問題，并利用perf工具對(duì)內(nèi)核函數(shù)的調(diào)用關(guān)系采樣：

perf record -a -g -F 1000 sleep 30

采樣結(jié)束后，在當(dāng)前目錄上會(huì)生成一個(gè)perf.data文件，使用perf工具查看函數(shù)調(diào)用關(guān)系：

perf report -g

7. 通過調(diào)用依賴關(guān)系分析，spin_lock_irqsave主要called by compaction_alloc，初步推測(cè)問題由kernel的內(nèi)存管理部分觸發(fā)。聯(lián)想到centos 6相對(duì)于centos 5在kernel內(nèi)存管理模塊的一些改進(jìn)點(diǎn)（如transparent huge page, 基于numa的內(nèi)存分配等），有沒有可能是CentOS6新增的THP特性導(dǎo)致cpu sys過高？再在google上搜一把相關(guān)函數(shù)名的關(guān)鍵字，印證這個(gè)猜測(cè)。

問題驗(yàn)證

1. 選擇在節(jié)點(diǎn)hadoop_A上面做驗(yàn)證測(cè)試，通過以下內(nèi)核參數(shù)優(yōu)化關(guān)閉系統(tǒng)THP特性:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

2. 重啟觸發(fā)問題的大Job，在hadoop_A節(jié)點(diǎn)未出現(xiàn)cpu sys 狀態(tài)過高的現(xiàn)象。

3. 在生產(chǎn)系統(tǒng)上運(yùn)行24小時(shí)后，通過zabbix系統(tǒng)觀察，其他內(nèi)核未優(yōu)化節(jié)點(diǎn)如hadoop_B,hadoop_C等節(jié)點(diǎn)依然存在cpu sys態(tài)過高的問題，而關(guān)閉了THP特性的hadoop_A節(jié)點(diǎn)沒有出現(xiàn)cpu sys態(tài)過高的問題，驗(yàn)證了之前的分析。

結(jié)論

將 Hadoop 集群中所有 CentOS6 類型節(jié)點(diǎn)的 THP 特性關(guān)閉掉 (在 CentOS6 中，THP特性默認(rèn)都是打開的)，關(guān)閉方法如下：

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

值得注意的是，需要在 puppet 系統(tǒng)中部署該項(xiàng)優(yōu)化，以免節(jié)點(diǎn)重啟導(dǎo)致修改丟失。

參考

事后，在redhat官網(wǎng)和cloudera官網(wǎng)也搜到了相關(guān)的內(nèi)容，附錄下來，供參考。

在 RedHat 的官網(wǎng)上，有對(duì) THP 特性的細(xì)化說明：

• https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-transhuge.html

在 Cloudera 的 CDH4 部署說明中，也建議將系統(tǒng)的 THP的 compaction 特性關(guān)閉：

• http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/4.2.2/CDH4-Installation-Guide/cdh4ig_topic_11_6.html

總結(jié)

以上是生活随笔為你收集整理的CentOS6上Hadoop集群中服务器cpu sys态异常的定位与解决的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。