CDH错误排查

来源：互联网发布：软件购买合同编辑：程序博客网时间：2024/06/05 03:29

hadoop基础----hadoop实战(九)-----hadoop管理工具---CDH的错误排查(持续更新)

2016-11-29 18:17 2077人阅读评论(1)收藏举报

分类：

java（249）

作者同类文章X

hadoop（20）

作者同类文章X

目录(?)[+]

解决红色警报
1. 时钟偏差
2. 进程状态
3. 群集连接
4. HDFS-副本不足的块
5. root运行hadoop命令还是很多Permission denied
  1. 修复root使用
  2. cm0中hdfs用户运行

在CDH安装完成后或者CDH使用过程中经常会有错误或者警报，需要我们去解决，积累如下:

解决红色警报

时钟偏差

这是因为我们的NTP服务不起作用导致的，几台机子之间有几秒钟的时间偏差。

这种情况下一是把NTP重新整理配置一下。

一种是在操作里调整报警误差范围。

因为NTP的时间同步是平滑同步，不是跳跃式同步，如果设置得不好的话，很难校验出它同步成功了没，总感觉会缺少几秒钟的感觉。

有一种解决方法是我们这里不用NTP的自动同步，而是使用crond每分钟ntpdate 跳跃式同步一次。

这种方法不建议在生产环境使用，但是一般生成环境都有外网，所以就能正确设置NTP。

所以下面我们在局域网无外网的情况下可以用以下方法(偏方)确保时间同步:

为了确保能同步时间，我们这里再加上定时同步步骤。

首先保证cm0的NTP服务是开启的。

然后停止cm1和cm2的NTP服务。

在cm0中运行

service ntpd start

在cm1和cm2中运行

service ntpd stop

cm1上的配置：修改crond自动运行程序的配置文件：vi /var/spool/cron/root (此处是以root用户为例，如果是其他用户，替换为对应的用户文件名，即可)，在该配置文件中，添加一行：*/1 * * * * ntpdate cm0(每隔一分钟，从cm0同步一次时间）保存，重新启动crond服务:service crond restart一分钟以后，cm1的时间就同步为cm0的时间了。cm2的配置：同cm1一样。局域网内还有其他机器，设置方法也同cm1一样。

然后CM中的NTP验证需要抑制。

变绿了。

进程状态

Hbase--RegionServer--cm1---不良 : 该角色的进程已退出。该角色的预期状态为已启动。

这种情况是cm1的hbase服务好像挂了。

点击在执行运行状况测试时查看此角色实例的日志找一下原因慢慢排查。

org.apache.Hadoop.hbase.YouAreDeadException: org.apache.hadoop.hbase.YouAreDeadException: Server REPORT rejected; currently processing cm1,60020,1480324093445 as dead serverat org.apache.hadoop.hbase.master.ServerManager.checkIsDead(ServerManager.Java:426)at org.apache.hadoop.hbase.master.ServerManager.regionServerReport(ServerManager.java:331)at org.apache.hadoop.hbase.master.MasterRpcServices.regionServerReport(MasterRpcServices.java:344)at org.apache.hadoop.hbase.protobuf.generated.RegionServerStatusProtos$RegionServerStatusService$2.callBlockingMethod(RegionServerStatusProtos.java:8617)at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2170)at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:109)at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)at java.lang.Thread.run(Thread.java:745)

Failed deleting my ephemeral nodeorg.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /hbase/rs/cm1,60020,1480324093445at org.apache.zookeeper.KeeperException.create(KeeperException.java:127)at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:873)at org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.delete(RecoverableZooKeeper.java:178)at org.apache.hadoop.hbase.zookeeper.ZKUtil.deleteNode(ZKUtil.java:1236)at org.apache.hadoop.hbase.zookeeper.ZKUtil.deleteNode(ZKUtil.java:1225)at org.apache.hadoop.hbase.regionserver.HRegionServer.deleteMyEphemeralNode(HRegionServer.java:1431)at org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:1100)at java.lang.Thread.run(Thread.java:745)

查了下资料发现这个问题还比较常见。我们这日志中也能看见

org.apache.hadoop.hbase.util.JvmPauseMonitorDetected pause in JVM or host machine (eg GC): pause of approximately 2489msNo GCs detected

这种情况是FULL GC，就是内存不够用了。

JVM垃圾回收异常的错误。

界面中也能看到大概原因

发现有2种解决方法，或者同时使用:

方法一设置达到70%时清理GC

方法二增加超时时长

方法一设置达到70%时清理GC(推荐)

hbase中和GC相关的参数：

修改前（默认）：

export HBASE_OPTS="$HBASE_OPTS -ea -verbose:gc -Xloggc:$HBASE_LOG_DIR/hbase.gc.log -XX:ErrorFile=$HBASE_LOG_DIR/hs_err_pid.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode"

咨询开发修改后：

export HBASE_OPTS="$HBASE_OPTS -verbose:gc -Xloggc:$HBASE_LOG_DIR/hbase.gc.log -XX:ErrorFile=$HBASE_LOG_DIR/hs_err_pid.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=70"

-XX UseConcMarkSweepGC ：设置年老代为并发收集。（新老都有）
老：-XX:+CMSIncrementalMode :设置为增量模式。适用于单CPU情况。
新：-XX:+UseParNewGC：设置年轻代为并行收集。可与 CMS 收集同时使用。
-XX:CMSInitiatingOccupancyFraction=70:这个参数是我觉得产生最大作用的。因为最终的目的是减少FULL GC，因为full gc是会block其他线程的。
默认触发GC的时机是当年老代内存达到90%的时候，这个百分比由 -XX:CMSInitiatingOccupancyFraction=N 这个参数来设置。concurrent mode failed发生在这样一个场景：
当年老代内存达到90%的时候，CMS开始进行并发垃圾收集，于此同时，新生代还在迅速不断地晋升对象到年老代。当年老代CMS还未完成并发标记时，年老代满了，悲剧就发生了。CMS因为没内存可用不得不暂停mark，并触发一次全jvm的stop the world（挂起所有线程），然后采用单线程拷贝方式清理所有垃圾对象，也就是full gc。而我们的bulk的最开始的操作就是各种删表,建表频繁的操作，就会使用掉大量master的年轻代的内存，就会发生上面发生的场景，发生full gc。

方法二增加超时时长

加大zookeeper会话超时时间，编辑hbase-site.xml文件，添加下面的属性
<property>
<name>zookeeper.session.timeout</name>
<value>120000</value>
</property>
<property>
<name>hbase.regionserver.lease.period</name>
<value>240000</value>
</property>
<property>
<name>hbase.rpc.timeout</name>
<value>280000</value>
</property>
加大zookeeper会话最大超时时间编辑zoo.cfg 提高MaxSessionTimeout=120000，修改后重启zookeeper。
zookeeper的超时时间不要设置太大，在服务挂掉的情况下，会反映很慢。

我们这里在CM管理界面中更改，找到RegionServer ( Cluster 1 HBase cm1 )界面，点击配置。看到如下图:

我们找参数修改保存即可。

然后在右上角操作中重启RegionServer 。

群集连接

群集连接 ( Cluster 1 HBase RegionServer cm1 ) 2016年11月29日, 下午3点48 CST
测试 HBase Master 是否将 RegionServer 视为已连接。
不良 : 该 RegionServer 当前未连接至其 cluster。

这种情况就是RegionServer 服务挂了。但是一般都是伴随着其他原因的。

解决完其他原因之后尝试重启RegionServer 即可。

如图点击 RegionServer

右上角重启

启动成功。

好了，HBase绿了。

HDFS-副本不足的块

副本不足的块 ( Cluster 1 HDFS ) 2016年11月29日, 下午4点02 CST
测试 HDFS 是否具有过多副本不足块。
不良 : 群集中有 707 个副本不足的块块。群集中共有 710 个块。百分比副本不足的块: 99.58%。临界阈值：40.00%。
操作
为此服务更改“副本不足的块监控阈值”。
建议
这是 HDFS 服务级运行状况测试，用于检查副本不足的块数是否未超过群集块总数的某一百分比。
该运行状况测试失败可能表示 DataNode 丢失。使用 HDFS fsck 命令可确定哪些文件含有副本不足的块。
可使用副本不足的块监控阈值 HDFS 服务范围内的监控设置配置该测试。

原因

原因是设置的副本备份数与DataNode的个数不匹配。

我们在之前理论篇中已经说明了dfs. replication属性默认是3，也就是说副本数---块的备份数默认为3份。

hadoop基础----hadoop理论(三)-----hadoop分布式文件系统HDFS详解

但是我们这里集群只有两个DataNode。

所以导致了达不到目标---副本备份不足。

解决方法

这种情况下的修复有2个步骤，1是设置目标备份数为2，2是通过命令更改当前备份数。

副本不足和副本过多都可以用这2个步骤解决，主要是跟DataNode的个数对应。

设置目标备份数为2

点击集群-HDFS-配置

搜索dfs. replication，设置为2后保存更改。

dfs.replication这个参数其实只在文件被写入dfs时起作用，虽然更改了配置文件，但是不会改变之前写入的文件的备份数。

所以我们还需要步骤2

在cm0中通过命令更改备份数：

su hdfs

hadoop fs -setrep -R 2 /

这里的-R 2的数字2就对应我们的DataNode个数。

好了，HDFS也绿了。

root运行hadoop命令还是很多Permission denied

修复root使用

permissions of '/user': Permission denied. user=root is not the owner of inode=user

这是因为这些文件不是本地文件，而是集群上的文件。

所以root用户对他们没有操作执行权限。

而CDH安装hadoop时默认设立了hdfs用户是对集群文件的最高权限用户。

所以需要给root用户集群文件的权限。

2个步骤

1.在mater机器也就是cm0中运行一下命令给权限即可。

sudo -u hdfs hadoop fs -mkdir /user/root
sudo -u hdfs hadoop fs -chown root:root /user/root

sudo -u hdfs hadoop fs -ls /user

sudo -u hdfs hadoop fs -chmod 777 /user

2.在hdfs的配置文件中，将dfs.permissions修改为False

两个步骤都需要执行。

重启HDFS服务。

cm0中hdfs用户运行

如果以上设置后root运行还是会报权限错误，那我们还是使用hdfs用户运行即可。

su hdfs

然后执行命令hadoop fs -setrep -R 2 /等命令。注意是在master机器cm0中su hdfs才行。

如果是在slave机器cm1或者cm2会报sudo: unable to execute /usr/bin/hadoop: Permission denied。

顶: 0

踩: 0

上一篇遇到问题---java---myeclipse中maven项目引用另一个导致的resource文件混乱的问题
下一篇hadoop基础----hadoop实战(七)-----hadoop管理工具---使用Cloudera Manager安装Hadoop---Cloudera Manager和CDH5.8离线安装