問題：
創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都做網(wǎng)站、網(wǎng)站設(shè)計(jì)、紅橋網(wǎng)絡(luò)推廣、重慶小程序開發(fā)公司、紅橋網(wǎng)絡(luò)營銷、紅橋企業(yè)策劃、紅橋品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供紅橋建站搭建服務(wù)，24小時(shí)服務(wù)熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com
部分主機(jī)宕機(jī)后，CDH集群?jiǎn)?dòng)成功，但是有某些主機(jī)提示“無法找到主機(jī)的NTP 服務(wù),或該服務(wù)未響應(yīng)時(shí)鐘偏差請(qǐng)求”
解決步驟：
1.先同步服務(wù)器時(shí)鐘
執(zhí)行命令：
service ntpd stop? 停止ntp服務(wù)
ntpdate? 主機(jī)ip? ?同步主機(jī)時(shí)鐘
service ntpd start? 啟動(dòng)ntp服務(wù)
service ntpd status? 查看服務(wù)啟動(dòng)情況
ntpq -pn??查看同步的服務(wù)器IP
ntpstat? 查看同步結(jié)果
2.在CDH界面停止主機(jī)上的角色
3.進(jìn)入該主機(jī)的CDH安裝目錄執(zhí)行 ./cloudera-scm-agent restart (即需要在問題主機(jī)上重啟cloudera-scm-agent服務(wù))
目錄在 etc/init.d下
4.等待CDH界面刷新，問題解決，大概等3? 5分鐘就看不到時(shí)鐘偏差問題了。
解決思路：
1.同步服務(wù)器時(shí)鐘是為了確定是否是ntp服務(wù)本身的問題。
2.發(fā)現(xiàn)服務(wù)器時(shí)鐘沒有問題，所以不是ntp服務(wù)本身的問題。
其中這句話說，如果該命令失敗、NTP 未與服務(wù)器同步，或主機(jī)的 NTP 后臺(tái)程序未運(yùn)行或無法聯(lián)系，該測(cè)試將返回運(yùn)行狀況“不良”。
所以可能是CDH集群本身沒有接收到時(shí)間同步服務(wù)器的結(jié)果，于是執(zhí)行重啟agent的命令。至此問題解決！
如果最后你的命令，確實(shí)列出了相應(yīng)的目錄文件，那么這種情況確實(shí)挺少見的，有兩種情況：1、你的"/"的文件太多了。2、你的網(wǎng)絡(luò)或硬件配置太低，這種情況下的可情性不大我的反應(yīng)情況挺快的，也有可能是你的配置有問題，實(shí)在解決不了的話，建議你重布一下，可參考一下我的百度博客中，寫了兩篇這個(gè)內(nèi)容。
1.關(guān)閉selinux
修改/etc/selinux/config 文件
將SELINUX=enforcing改為SELINUX=disabled
重啟機(jī)器即可
2.修改bin文件的運(yùn)行權(quán)限，運(yùn)行bin文件后，進(jìn)入安裝cdh-manager的安裝界面
如果直接安裝，cdh-manager會(huì)去archive.cloudera.com下載安裝包，這樣會(huì)很慢，所以最好在內(nèi)網(wǎng)搭一個(gè)下載源，做個(gè)host
echo '192.168.8.XX archive.cloudera.com' /etc/hosts
每一步安裝的日志會(huì)保存在 /var/log/cloudera-manager-installer/目錄
1.配置 Cloudera Manager 倉庫(所有節(jié)點(diǎn))
2.安裝jdk 1.8（略）
3.安裝mysql 5.7（略）
或者yum
這里 不詳細(xì)說明了
修改集群中各機(jī)器的hosts和hostname，并使之永久生效。步驟如下：
輸入命令 hostname：查看當(dāng)前hostname；
輸入命令 hostname new.hostname：修改new hostname并立即生效（臨時(shí)有效，重啟系統(tǒng)后失效）
輸入命令 vim /etc/hosts：為集群中的各機(jī)器添加對(duì)應(yīng)的hosts；
輸入命令 vim /etc/sysconfig/network：修改HOSTNAME=new.hostname，使new.hostname永久生效。（如果沒有該值則手動(dòng)添加，并重啟確認(rèn)是否永久生效）
設(shè)置集群中的各機(jī)器能互相SSH免密登錄，并且能夠ssh locahost登錄本機(jī)。步驟如下：
輸入命令 ssh-keygen -t rsa，一路回車即可；
輸入命令 ssh-copy-id -i .ssh/id_ rsa.pub username@target.machine.ip；
ssh登錄各機(jī)器進(jìn)行確認(rèn)。
可能會(huì)有的報(bào)錯(cuò)：
/usr/bin/ssh-copy-id: ERROR: Host key verification failed.
因?yàn)槲逸斎雜sh-copy-id -i .ssh/id_ rsa.pub root@10.1.2.104.master時(shí)沒有輸入yes 直接回車，再次輸入yes成功
sudo firewall-cmd --zone=public --add-port=7180/tcp --permanent
sudo firewall-cmd --reload
臨時(shí)關(guān)閉防火墻
systemctl stop firewalld
檢查SELinux當(dāng)前狀態(tài)：getenforce；
如果輸出為Permissive或Disabled，那么就可以不用設(shè)置SELinux的模式了。如果輸出是enforcing，就接著做下一步；
vim /etc/selinux/config (有些系統(tǒng)里是 /etc/sysconfig/selinux)；
將 SELINUX=enforcing 修改為 SELINUX=permissive，保存并退出；
輸入 setenforce 0，使設(shè)置立即生效
集群中各機(jī)器都要配
解壓cloudera-manager-centos7-cm5.11.0_x86_64.tar.gz
cloudera manager的目錄默認(rèn)位置在/opt下
mv cm-5.11.0 /opt/
mv cloudera /opt/
添加mysql 驅(qū)動(dòng)
cd /opt/cloudera/parcel-repo/
復(fù)制以下文件到該目錄
CDH-5.11.0-1.cdh5.11.0.p0.34-el6.parcel.sha1
CDH-5.11.0-1.cdh5.11.0.p0.34-el6.parcel
manifest.json
修改
CDH-5.11.0-1.cdh5.11.0.p0.34-el6.parcel.sha1為
CDH-5.11.0-1.cdh5.11.0.p0.34-el6.parcel.sha
各Service所需的庫如下圖，其中庫名和user名可以自定義，但自己必須記住。（建議庫名使用圖中所示的，user名可以自定義，并且可以相同）
運(yùn)行
登錄：
1 啟動(dòng)報(bào)錯(cuò)：
啟動(dòng)server/agent失敗，報(bào)錯(cuò)pstree: command not found
安裝 psmisc
2 我重裝了HDFS所以報(bào)錯(cuò)
對(duì)當(dāng)前 NameNode 的名稱目錄進(jìn)行格式化。如果名稱目錄不為空，此操作將失敗。
刪除 /dfs下的nn目錄重試即可
3 datanode啟動(dòng)失敗報(bào)錯(cuò)
將/dfs/nn 和 dn的 VERSION中的clusterIDs改為一致即可
出現(xiàn)該問題的原因：在第一次格式化dfs后，啟動(dòng)并使用了hadoop，后來又重新執(zhí)行了格式化命令，這時(shí)namenode的clusterID會(huì)重新生成，而datanode的clusterID 保持不變。
兩個(gè)月前寫過一篇文章，HDFS和Yarn經(jīng)常出現(xiàn)dataNode和NameNode之間, nodeManager與resourceManager之間 連接不良的現(xiàn)象，開始懷疑是service Monitor監(jiān)控內(nèi)存失敗的問題，于是更換了JDK版本，當(dāng)時(shí)認(rèn)為問題解決，然而沒過多久，假死和連接不良現(xiàn)象又出現(xiàn)了。重新將nameNode日志閾值改成debug，發(fā)現(xiàn)依然存在如下異常：
但網(wǎng)上查了一些資料，也有人說這是CDH版HDFS的一個(gè)bug。本身并不影響服務(wù)?？紤]到CDH本身也將該異常認(rèn)定為debug級(jí)別，覺得是有可能的。個(gè)人感覺這個(gè)問題除了讓日志增長比較快，也就這樣了。決定先把這個(gè)問題放一放。
由于疫情和工作原因，一直沒功夫去看這個(gè)問題，一氣之下把主節(jié)點(diǎn)升到16G內(nèi)存，驚喜發(fā)現(xiàn)部署在主節(jié)點(diǎn)的DataNode和nodeManager幾乎一直是良好狀態(tài)，而從節(jié)點(diǎn)經(jīng)常出現(xiàn)問題。
比如這個(gè)很可憐，除了主節(jié)點(diǎn)之外的nodeManager其余都掛了。
所以現(xiàn)在解決問題的思路無非是
1. 升級(jí)從節(jié)點(diǎn)的資源配置，和主節(jié)點(diǎn)配置保持一致。
2. 通過系統(tǒng)優(yōu)化和調(diào)優(yōu)解決問題。
本著對(duì)技術(shù)的探(mei)究(qian)之心，我決定采用第二條方案。
先把服務(wù)器上的HDFS nameNode/yarn nodeManager堆棧日志dump下來(因?yàn)檫@兩個(gè)組件內(nèi)存占用較大)，看看究竟。發(fā)現(xiàn)其中70%的都是不可達(dá)對(duì)象（也就是圖中的灰色部分）。
于是到服務(wù)器上去一探究竟。
通過jmap 命令，發(fā)現(xiàn)兩個(gè)現(xiàn)象：
1. 新生代內(nèi)存比較小，并且頻繁進(jìn)行minor gc，幾乎每分鐘都有。
2. 老年代內(nèi)存一直在增長并且沒有釋放的跡象。
感覺新生代內(nèi)存過小可能會(huì)導(dǎo)致：
1.? 頻繁的minor gc，很多新生對(duì)象沒有經(jīng)過充分gc而進(jìn)入老年代。（比如新生對(duì)象存活時(shí)間是五分鐘，而頻繁的minor gc導(dǎo)致3分鐘這個(gè)對(duì)象就被當(dāng)成老人放入老年代）
2.? 頻繁的minor gc，可能導(dǎo)致對(duì)cpu資源的爭(zhēng)奪或其它未知的原因?qū)е耼odeManager或者dataNode不良。
而老年代內(nèi)存回收過慢則導(dǎo)致系統(tǒng)內(nèi)存一直處于高位。
于是嘗試設(shè)置兩個(gè)參數(shù)：
-XX:NewRatio=2 -XX:CMSInitiatingOccupancyFraction=45
第一個(gè)XX:NewRatio是指擴(kuò)大新生代內(nèi)存的比例，降低minor gc的頻率，而第二個(gè)則是降低觸發(fā)老年代full gc內(nèi)存回收的閾值，使得老年代不至于保存大量已不可達(dá)的對(duì)象。如果但這個(gè)值如果設(shè)太低，則又會(huì)頻繁觸發(fā)full gc和major gc，所以也不敢設(shè)置太低，設(shè)成45。
通過設(shè)置，HDFS的dataNode連接不良的問題得以解決，但yarn的nodeManager還是頻繁出現(xiàn)不良。
繼續(xù)百度+谷歌，發(fā)現(xiàn)JDK1.8有更好的垃圾收集器，G1回收器，感興趣的同學(xué)請(qǐng)移步：
深入理解JVM（5）——GC垃圾回收（3）——8大垃圾收集器
G1回收器比之前用的新生代并行垃圾收集器無論是吞吐量優(yōu)先(讓單位時(shí)間內(nèi)，STW 的時(shí)間最短)還是對(duì)響應(yīng)時(shí)間優(yōu)先(盡可能讓單次 STW 的時(shí)間最短)的處理都比并行垃圾處理器(useParNewGC）優(yōu)雅不少。
我們可以通過以下參數(shù)設(shè)置，其中XX:MaxGCPauseMillis為單次最大gc停頓時(shí)間。這是一個(gè)軟目標(biāo)，G1會(huì)盡量保證單次停頓低于該值。
-XX:+UseG1GC -XX:MaxGCPauseMillis=200
設(shè)置完之后，集群穩(wěn)定的一批。跑了一些任務(wù)，也沒有問題。收工。
最后又是安利追劇時(shí)間，今天安利的是精英律師，老干部嘴皮子簡(jiǎn)直6得不行了，栗娜真的超好看。
重慶分公司
重慶分公司
