13518219792
问题：
创新互联专注为客户提供全方位的互联网综合服务，包含不限于成都做网站、网站设计、红桥网络推广、重庆小程序开发公司、红桥网络营销、红桥企业策划、红桥品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联为所有大学生创业者提供红桥建站搭建服务，24小时服务热线：18980820575，官方网址：www.cdcxhl.com
部分主机宕机后，CDH集群启动成功，但是有某些主机提示“无法找到主机的NTP 服务,或该服务未响应时钟偏差请求”
解决步骤：
1.先同步服务器时钟
执行命令：
service ntpd stop 停止ntp服务
ntpdate 主机ip 同步主机时钟
service ntpd start 启动ntp服务
service ntpd status 查看服务启动情况
ntpq -pn 查看同步的服务器IP
ntpstat 查看同步结果
2.在CDH界面停止主机上的角色
3.进入该主机的CDH安装目录执行 ./cloudera-scm-agent restart (即需要在问题主机上重启cloudera-scm-agent服务)
目录在 etc/init.d下
4.等待CDH界面刷新，问题解决，大概等3 5分钟就看不到时钟偏差问题了。
解决思路：
1.同步服务器时钟是为了确定是否是ntp服务本身的问题。
2.发现服务器时钟没有问题，所以不是ntp服务本身的问题。
其中这句话说，如果该命令失败、NTP 未与服务器同步，或主机的 NTP 后台程序未运行或无法联系，该测试将返回运行状况“不良”。
所以可能是CDH集群本身没有接收到时间同步服务器的结果，于是执行重启agent的命令。至此问题解决！
如果最后你的命令，确实列出了相应的目录文件，那么这种情况确实挺少见的，有两种情况：1、你的"/"的文件太多了。2、你的网络或硬件配置太低，这种情况下的可情性不大我的反应情况挺快的，也有可能是你的配置有问题，实在解决不了的话，建议你重布一下，可参考一下我的百度博客中，写了两篇这个内容。
1.关闭selinux
修改/etc/selinux/config 文件
将SELINUX=enforcing改为SELINUX=disabled
重启机器即可
2.修改bin文件的运行权限，运行bin文件后，进入安装cdh-manager的安装界面
如果直接安装，cdh-manager会去archive.cloudera.com下载安装包，这样会很慢，所以最好在内网搭一个下载源，做个host
echo '192.168.8.XX archive.cloudera.com' /etc/hosts
每一步安装的日志会保存在 /var/log/cloudera-manager-installer/目录
1.配置 Cloudera Manager 仓库(所有节点)
2.安装jdk 1.8（略）
3.安装mysql 5.7（略）
或者yum
这里 不详细说明了
修改集群中各机器的hosts和hostname，并使之永久生效。步骤如下：
输入命令 hostname：查看当前hostname；
输入命令 hostname new.hostname：修改new hostname并立即生效（临时有效，重启系统后失效）
输入命令 vim /etc/hosts：为集群中的各机器添加对应的hosts；
输入命令 vim /etc/sysconfig/network：修改HOSTNAME=new.hostname，使new.hostname永久生效。（如果没有该值则手动添加，并重启确认是否永久生效）
设置集群中的各机器能互相SSH免密登录，并且能够ssh locahost登录本机。步骤如下：
输入命令 ssh-keygen -t rsa，一路回车即可；
输入命令 ssh-copy-id -i .ssh/id_ rsa.pub username@target.machine.ip；
ssh登录各机器进行确认。
可能会有的报错：
/usr/bin/ssh-copy-id: ERROR: Host key verification failed.
因为我输入ssh-copy-id -i .ssh/id_ rsa.pub root@10.1.2.104.master时没有输入yes 直接回车，再次输入yes成功
sudo firewall-cmd --zone=public --add-port=7180/tcp --permanent
sudo firewall-cmd --reload
临时关闭防火墙
systemctl stop firewalld
检查SELinux当前状态：getenforce；
如果输出为Permissive或Disabled，那么就可以不用设置SELinux的模式了。如果输出是enforcing，就接着做下一步；
vim /etc/selinux/config (有些系统里是 /etc/sysconfig/selinux)；
将 SELINUX=enforcing 修改为 SELINUX=permissive，保存并退出；
输入 setenforce 0，使设置立即生效
集群中各机器都要配
解压cloudera-manager-centos7-cm5.11.0_x86_64.tar.gz
cloudera manager的目录默认位置在/opt下
mv cm-5.11.0 /opt/
mv cloudera /opt/
添加mysql 驱动
cd /opt/cloudera/parcel-repo/
复制以下文件到该目录
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名可以自定义，并且可以相同）
运行
登录：
1 启动报错：
启动server/agent失败，报错pstree: command not found
安装 psmisc
2 我重装了HDFS所以报错
对当前 NameNode 的名称目录进行格式化。如果名称目录不为空，此操作将失败。
删除 /dfs下的nn目录重试即可
3 datanode启动失败报错
将/dfs/nn 和 dn的 VERSION中的clusterIDs改为一致即可
出现该问题的原因：在第一次格式化dfs后，启动并使用了hadoop，后来又重新执行了格式化命令，这时namenode的clusterID会重新生成，而datanode的clusterID 保持不变。
两个月前写过一篇文章，HDFS和Yarn经常出现dataNode和NameNode之间, nodeManager与resourceManager之间 连接不良的现象，开始怀疑是service Monitor监控内存失败的问题，于是更换了JDK版本，当时认为问题解决，然而没过多久，假死和连接不良现象又出现了。重新将nameNode日志阈值改成debug，发现依然存在如下异常：
但网上查了一些资料，也有人说这是CDH版HDFS的一个bug。本身并不影响服务。考虑到CDH本身也将该异常认定为debug级别，觉得是有可能的。个人感觉这个问题除了让日志增长比较快，也就这样了。决定先把这个问题放一放。
由于疫情和工作原因，一直没功夫去看这个问题，一气之下把主节点升到16G内存，惊喜发现部署在主节点的DataNode和nodeManager几乎一直是良好状态，而从节点经常出现问题。
比如这个很可怜，除了主节点之外的nodeManager其余都挂了。
所以现在解决问题的思路无非是
1. 升级从节点的资源配置，和主节点配置保持一致。
2. 通过系统优化和调优解决问题。
本着对技术的探(mei)究(qian)之心，我决定采用第二条方案。
先把服务器上的HDFS nameNode/yarn nodeManager堆栈日志dump下来(因为这两个组件内存占用较大)，看看究竟。发现其中70%的都是不可达对象（也就是图中的灰色部分）。
于是到服务器上去一探究竟。
通过jmap 命令，发现两个现象：
1. 新生代内存比较小，并且频繁进行minor gc，几乎每分钟都有。
2. 老年代内存一直在增长并且没有释放的迹象。
感觉新生代内存过小可能会导致：
1. 频繁的minor gc，很多新生对象没有经过充分gc而进入老年代。（比如新生对象存活时间是五分钟，而频繁的minor gc导致3分钟这个对象就被当成老人放入老年代）
2. 频繁的minor gc，可能导致对cpu资源的争夺或其它未知的原因导致nodeManager或者dataNode不良。
而老年代内存回收过慢则导致系统内存一直处于高位。
于是尝试设置两个参数：
-XX:NewRatio=2 -XX:CMSInitiatingOccupancyFraction=45
第一个XX:NewRatio是指扩大新生代内存的比例，降低minor gc的频率，而第二个则是降低触发老年代full gc内存回收的阈值，使得老年代不至于保存大量已不可达的对象。如果但这个值如果设太低，则又会频繁触发full gc和major gc，所以也不敢设置太低，设成45。
通过设置，HDFS的dataNode连接不良的问题得以解决，但yarn的nodeManager还是频繁出现不良。
继续百度+谷歌，发现JDK1.8有更好的垃圾收集器，G1回收器，感兴趣的同学请移步：
深入理解JVM（5）——GC垃圾回收（3）——8大垃圾收集器
G1回收器比之前用的新生代并行垃圾收集器无论是吞吐量优先(让单位时间内，STW 的时间最短)还是对响应时间优先(尽可能让单次 STW 的时间最短)的处理都比并行垃圾处理器(useParNewGC）优雅不少。
我们可以通过以下参数设置，其中XX:MaxGCPauseMillis为单次最大gc停顿时间。这是一个软目标，G1会尽量保证单次停顿低于该值。
-XX:+UseG1GC -XX:MaxGCPauseMillis=200
设置完之后，集群稳定的一批。跑了一些任务，也没有问题。收工。
最后又是安利追剧时间，今天安利的是精英律师，老干部嘴皮子简直6得不行了，栗娜真的超好看。
