hadoop相关问题

2023-11-29 12:29:16

一、mapreduce作业oom
1、任务还没启动,直接oom报错

AM日志：
21/05/10 15:15:13 INFO mapreduce.Job: Task Id : attempt_1617064346277_101596_m_000000_1, Status : FAILEDError: Java heap space21/05/10 15:15:16 INFO mapreduce.Job: Task Id : attempt_1617064346277_101596_m_000000_2, Status : FAILEDError: Java heap space
maptask的日志：
2021-05-10 17:02:41,893 INFO [main] org.apache.hadoop.mapred.MapTask: Processing split: hdfs://emr-cluster/tmp/gc/wordcount.txt:0+52
2021-05-10 17:02:41,988 ERROR [main] org.apache.hadoop.mapred.YarnChild: Error running child : java.lang.OutOfMemoryError: Java heap space
	at org.apache.hadoop.mapred.MapTask$MapOutputBuffer.init(MapTask.java:1000)
	at org.apache.hadoop.mapred.MapTask.createSortingCollector(MapTask.java:408)
	at org.apache.hadoop.mapred.MapTask.access$100(MapTask.java:82)
	at org.apache.hadoop.mapred.MapTask$NewOutputCollector.<init>(MapTask.java:710)
	at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:782)
	at org.apache.hadoop.mapred.MapTask.run(MapTask.java:347)

原因是可能是mapreduce.task.io.sort.mb调整太大

2、任务已经启动，但是map阶段出现oom

[2021-05-21 15:35:41.032]Container [pid=17140,containerID=container_e04_1621582172453_0001_01_000113] is running 17997824B beyond the 'PHYSICAL' memory limit. Current usage: 1.0 GB of 1.0 GB physical memory used; 2.8 GB of 5.0 TB virtual memory used. Killing container.

调大mapreduce.map.memory.mb的内存

二、HDFS注意点
1、HDFS数据写入策略

HDFS在写入时有两种选择卷（磁盘）的策略，一是基于轮询的策略（RoundRobinVolumeChoosingPolicy），二是基于可用空间的策略（AvailableSpaceVolumeChoosingPolicy）。

由hdfs-site.xml中的dfs.datanode.fsdataset.volume.choosing.policy属性来指定。可取的值为org.apache.hadoop.hdfs.server.datanode.fsdataset.RoundRobinVolumeChoosingPolicy或AvailableSpaceVolumeChoosingPolicy。选择基于可用空间的策略，还有两个属性需要注意。

dfs.datanode.available-space-volume-choosing-policy.balanced-space-threshold

默认值10737418240，即10G。它的含义是所有卷中最大可用空间与最小可用空间差值的阈值，如果小于这个阈值，则认为存储是平衡的，直接采用轮询来选择卷。
dfs.datanode.available-space-volume-choosing-policy.balanced-space-preference-fraction
默认值0.75。它的含义是数据块存储到可用空间多的卷上的概率，由此可见，这个值如果取0.5以下，对该策略而言是毫无意义的，一般就采用默认值。

2、数据不均衡调整
前言
做集群运维的同学可能都会遇到这样一个问题:Hadoop集群使用久了,各个节点上的数据会变得不均衡,多的达到70,80%,少的就10,20%.面对这种场景,我们的办法一般就是用HDFS自带的Balancer工具对其进行数据平衡.但有的时候,你会发现尽管节点间数据平衡了,但是节点内各个磁盘块的数据出现了不平衡的现象.这可是Balancer工具所干不了的事情.通过这个场景,我们引入本文的一个话题点:HDFS节点内数据平衡.这个问题很早的时候其实就被提出了,详见issue HDFS-1312(Re-balance disks within a Datanode).我相信大家在使用Hadoop集群的时候或多或少都遇到过这个问题.本文就来好好聊聊这个话题,以及社区目前对此的解决方案.

磁盘间数据不均衡状况的出现
磁盘间数据不均衡的现象源自于长期写操作时数据大小不均衡.因为每次写操作你可以保证写磁盘的顺序性,但是你没法保证每次写入的数据量都是一个大小.比如A,B,C,D四块盘,你用默认的RoundRobin磁盘选择策略去写,最后四块盘都写过了,但是A,B可能写的block块就1M,而C,D可能就是128M.

磁盘间数据不均衡带来的问题
如果磁盘间数据不均衡现象确实出现了,它会给我们造成什么影响呢?有人可能会想,它不就是一个普通磁盘嘛,又不是系统盘,系统盘使用空间过高是会影响系统性能,但是普通盘应该问题不大吧.这个观点听上去是没问题,但是只能说它考虑的太浅了.我们从HDFS的读写层面来对这个现象做一个分析.这里归纳出了以下2点:

第一点,磁盘间数据不均衡间接引发了磁盘IO压力的不同.我们都知道,HDFS上的数据访问频率是很高的,这就会涉及到大量读写磁盘的操作,数据多的盘自然的就会有更高频率的访问操作.如果一块盘的IO操作非常密集的话,势必会对它的读写性能造成影响.
第二点,高使用率磁盘导致节点可选存储目录减少.HDFS在写Block数据的时候,会挑选剩余可用空间满足待写Block的大小的情况下时,才会进行挑选,如果高使用率磁盘目录过多,会导致这样的候选块变少.所以这方面其实偏向的是对HDFS的影响.

磁盘间数据不均衡的传统解决方案
磁盘间数据不均衡现象出现了,目前我们有什么办法解决呢?下面是2种现有解决方案:

方案一:节点下线再上线.将节点内数据不均衡的机器进行Decommision下线操作,下线之后再次上线.上线之后相当于是一个全新的节点了,数据也将会重新存储到各个盘上.这种做法给人感觉会比较暴力,当集群规模比较小的时候,代价太高,此时下线一个节点会对集群服务造成不小的影响.

方案二:人工移动部分数据block存储目录.此方案比方案一更加灵活一些,但是数据目录的移动要保证准确性,否则会造成移动完目录后数据找不到的现象.下面举一个实际的例子,比如我们想将磁盘1上的数据挪到磁盘2上.现有磁盘1的待移动存储目录如下:

/data/1/dfs/dn/ current/BP-1788246909-xx.xx.xx.xx-1412278461680/current/ finalized/subdir0/subdir1/

我移动到目标盘上的路径应该维持这样的路径格式不变,只变化磁盘所在的目录,目标路径如下:

/data/2/dfs/dn/current/BP-1788246909-xx.xx.xx.xx-1412278461680/current/finalized/subdir0/subdir1/

如果上述目录结构出现变化,就会造成HDFS找不到此数据块的情况.

社区解决方案：DiskBalancer
前面铺垫了这么多的内容,就是为了引出本节要重点阐述的内容:DiskBalancer.DiskBalancer从名字上,我们可以看出,它是一个类似于Balancer的数据平衡工具.但是它的作用范围是被限制在了Disk上.首先这里要说明一点,DiskBalancer目前是未发布的功能特性,所以你们在现有发布版中是找不到此工具的.下面我将会全方面的介绍DiskBalancer,让大家认识,了解这个强大的工具.

DiskBalancer的设计核心
首先我们先来了解DiskBalancer的设计核心,这里与Balancer有一点点的区别.Balancer的核心点在于数据的平衡,数据平衡好就OK了.而DiskBalancer在设计的时候提出了2点目标:

第一.Data Spread Report.数据分布式的汇报.这是一个report汇报的功能.也就是说,DiskBalancer工具能支持各个节点汇报磁盘块使用情况的功能,通过这个功能我可以了解到目前集群内使用率TopN的节点磁盘.
第二.Disk Balancing.第二点才是磁盘数据的平衡.但是在磁盘内数据平衡的时候,要考虑到各个磁盘storageType的不同,因为之前提到过HDFS的异构存储,不同盘可能存储介质会不同,目前DiskBalancer不支持跨存储介质的数据转移,所以目前都是要求在一个storageType下的.

以上2点取自于DiskBalancer的设计文档(DiskBalancer相关设计文档可见文章末尾的参考链接).

DiskBalancer的架构设计
此部分来讨论讨论DiskBalancer的架构设计.通过架构设计,我们能更好的了解它的一个整体情况.DiskBalancer的核心架构思想如下图所示:

上面过程经过了3个阶段,Discover(发现)到Plan(计划),再从Plan(计划)到Execute(执行).下面来详细解释这3个阶段:

Discover
发现阶段做的事情实际上就是通过计算各个节点内的磁盘使用情况,然后得出需要数据平衡的磁盘列表.这里会通过Volume Data Density磁盘使用密度的概念作为一个评判的标准,这个标准值将会以节点总使用率作为比较值.举个例子,如果一个节点,总使用率为75%,就是0.75,其中A盘使用率0.5(50%),那么A盘的volumeDataDensity密度值就等于0.75-0.5=0.25.同理,如果超出的话,则密度值将会为负数.于是我们可以用节点内各个盘的volumeDataDensity的绝对值来判断此节点内磁盘间数据的平衡情况,如果总的绝对值的和越大,说明数据越不平衡,这有点类似于方差的概念.Discover阶段将会用到如下的连接器对象:

1.DBNameNodeConnector
2.JsonConnector
3.NullConnector

其中第一个对象会调用到Balancer包下NameNodeConnector对象,以此来读取集群节点,磁盘数据情况

Plan
拿到上一阶段的汇报结果数据之后,将会进行执行计划的生成.Plan并不是一个最小的执行单元,它的内部由各个Step组成.Step中会指定好源,目标磁盘.这里的磁盘对象是一层经过包装的对象:DiskBalancerVolume,并不是原来的FsVolume.这里顺便提一下DiskBalancer中对磁盘节点等概念的转化:

1.DiskBalancerCluster.通过此对象可以,读取到集群中的节点信息,这里的节点信息以DiskBalancerDataNode的方式所呈现.
2.DiskBalancerDataNode.此对象代表的是一个包装好后的DataNode.
3.DiskBalancerVolume和DiskBalancerVolumeSet.DataNode磁盘对象以及磁盘对象集合.DiskBalancerVolumeSet内的磁盘存储目录类型需要是同种StorageType.
Execute
最后一部分是执行阶段,所有的plan计划生成好了之后,就到了执行阶段.这些计划会被提交到各自的DataNode上,然后在DiskBalancer类中进行执行.DiskBalancer类中有专门的类对象来做磁盘间数据平衡的工作,这个类名称叫做DiskBalancerMover.在磁盘间数据平衡的过程中,高使用率的磁盘会移动数据块到相对低使用率的磁盘,等到满足一定阈值关系的情况下时,DiskBalancer会渐渐地退出.在DiskBalancer的执行阶段,有以下几点需要注意:

1.带宽的限制.DiskBalancer中同样可以支持带宽的限制,默认是10M,通过配置项dfs.disk.balancer.max.disk.throughputInMBperSec进行控制.
2.失败次数的限制.DiskBalancer中会存在失败次数的控制.在拷贝block数据块的时候,出现IOException异常,会进行失败次数的累加计数,如果超出最大容忍值,DiskBalancer也会退出.
3.数据平衡阈值控制.DiskBalancer中可以提供一个磁盘间数据的平衡阈值,以此作为是否需要继续平衡数据的标准,配置项为dfs.disk.balancer.block.tolerance.percent.
DiskBalancer的命令执行
DiskBalancer内部提供了许多类别的命令操作,比如下面的查询命令:

hdfs diskbalancer -query nodename.mycluster.com
1
我们也可以执行相应的plan命令来生成plan计划文件.

hdfs diskbalancer -uri hdfs://mycluster.com -plan node1.mycluster.com
1
然后我们可以用生成好后的json文件进行DiskBalancer的执行

hdfs diskbalancer -execute /system/diskbalancer/nodename.plan.json
1
当然,如果我们发现我们执行了错误的plan,我们也可以通过cancel命令进行清除:

hdfs diskbalancer -cancel /system/diskbalancer/nodename.plan.json
1
或

hdfs diskbalancer -cancel -node
1
在DiskBalancer中会涉及到比较多的object-json的关系转换,所以你会看到一些带.json后缀的文件

小结
总而言之,DiskBalancer是一个很实用的功能特性.在Hadoop中,有专门的分支用于开发此功能,就是HDFS-1312,感兴趣的同学可以下载Hadoop的最新代码进行学习.本人非常荣幸地也向此功能提交了一个小patch, issue编号,HDFS-10560.这个new feature很快就要在新版的Hadoop中发布了,相信会对Hadoop集群管理人员非常有帮助.

参考资料
1.https://issues.apache.org/jira/secure/attachment/12755226/disk-balancer-proposal.pdf
2.https://issues.apache.org/jira/secure/attachment/12810720/Architecture_and_test_update.pdf
2.https://issues.apache.org/jira/browse/HDFS-1312
3.https://issues.apache.org/jira/browse/HDFS-10560

3、块丢失处理
There are 2 missing blocks. The following files may be corrupted：

步骤1，检查文件缺失情况
可以看到，
blk_1074785806 /var/log/yarn_hislog/yarn/apps/root/logs/application_1531830253305_4290/master66_38210
blk_1074785807 /var/log/yarn_hislog/yarn/apps/root/logs/application_1531830253305_4289/master66_38210
确实各自都丢失了1个Block，文件已经损坏，不可恢复。

[root@master66 datacollectors]# hdfs fsck /var/log/yarn_hislog/yarn/apps/root/logs/application_1531830253305_4290/master66_38210
Connecting to namenode via http://master66:50070
FSCK started by root (auth:SIMPLE) from /10.3.70.116 for path /var/log/yarn_hislog/yarn/apps/root/logs/application_1531830253305_4290/master66_38210 at Thu Sep 06 09:23:04 CST 2018
可以看到，
blk_1074785806 /var/log/yarn_hislog/yarn/apps/root/logs/application_1531830253305_4290/master66_38210
blk_1074785807 /var/log/yarn_hislog/yarn/apps/root/logs/application_1531830253305_4289/master66_38210
确实各自都丢失了1个Block，文件已经损坏，不可恢复。

步骤2，删除缺失文件
hdfs fsck -delete blk_1074785806 /var/log/yarn_hislog/yarn/apps/root/logs/application_1531830253305_4290/master66_38210
hdfs fsck -delete blk_1074785807 /var/log/yarn_hislog/yarn/apps/root/logs/application_1531830253305_4289/master66_38210
步骤3，检查集群健康状况

三、yarn
1、常用的命令
hdfs haadmin -getServiceState nn1查看active或者是standby状态

2、手动切换主备
dfs.ha.automatic-failover.enabled=true时这个指令不支持
hdfs haadmin -failover -forcefence -forceactive nn2 nn1 主备切换

3、yarn因为磁盘不够导致异常

2020-09-17 13:12:31,660 ERROR org.mortbay.log: /ws/v1/cluster/apps
javax.ws.rs.WebApplicationException: javax.xml.bind.MarshalException
 - with linked exception:
[javax.xml.stream.XMLStreamException: org.mortbay.jetty.EofException]
	at com.sun.jersey.core.provider.jaxb.AbstractRootElementProvider.writeTo(AbstractRootElementProvider.java:159)
	at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:306)
	at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1437)
	at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
	at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
	at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
	at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
	at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:886)
	at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:834)
	at org.apache.hadoop.yarn.server.resourcemanager.webapp.RMWebAppFilter.doFilter(RMWebAppFilter.java:142)
	at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:795)
	at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:163)
	at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
	at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:118)
	at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:113)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
	at org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:109)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
	at org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:595)
	at org.apache.hadoop.security.token.delegation.web.DelegationTokenAuthenticationFilter.doFilter(DelegationTokenAuthenticationFilter.java:294)
	at org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:554)
	at org.apache.hadoop.yarn.server.security.http.RMAuthenticationFilter.doFilter(RMAuthenticationFilter.java:82)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
	at org.apache.hadoop.http.HttpServer2$QuotingInputFilter.doFilter(HttpServer2.java:1243)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
	at org.apache.hadoop.http.NoCacheFilter.doFilter(NoCacheFilter.java:45)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
	at org.apache.hadoop.http.NoCacheFilter.doFilter(NoCacheFilter.java:45)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
	at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
	at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
	at org.mortbay.jetty.Server.handle(Server.java:326)
	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
	at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
	at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Caused by: javax.xml.bind.MarshalException
 - with linked exception:
[javax.xml.stream.XMLStreamException: org.mortbay.jetty.EofException]
	at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:327)
	at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:177)
	at com.sun.jersey.json.impl.BaseJSONMarshaller.marshallToJSON(BaseJSONMarshaller.java:103)
	at com.sun.jersey.json.impl.provider.entity.JSONRootElementProvider.writeTo(JSONRootElementProvider.java:136)
	at com.sun.jersey.core.provider.jaxb.AbstractRootElementProvider.writeTo(AbstractRootElementProvider.java:157)
	... 43 more
Caused by: javax.xml.stream.XMLStreamException: org.mortbay.jetty.EofException
	at com.sun.jersey.json.impl.writer.Stax2JacksonWriter.writeStartElement(Stax2JacksonWriter.java:204)
	at com.sun.xml.bind.v2.runtime.output.XMLStreamWriterOutput.beginStartTag(XMLStreamWriterOutput.java:118)
	at com.sun.xml.bind.v2.runtime.output.XmlOutputAbstractImpl.beginStartTag(XmlOutputAbstractImpl.java:102)
	at com.sun.xml.bind.v2.runtime.output.NamespaceContextImpl$Element.startElement(NamespaceContextImpl.java:496)
	at com.sun.xml.bind.v2.runtime.XMLSerializer.endNamespaceDecls(XMLSerializer.java:291)
	at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:687)
	at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:156)
	at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:344)
	at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:700)
	at com.sun.xml.bind.v2.runtime.property.ArrayElementNodeProperty.serializeItem(ArrayElementNodeProperty.java:69)
	at com.sun.xml.bind.v2.runtime.property.ArrayElementProperty.serializeListBody(ArrayElementProperty.java:172)
	at com.sun.xml.bind.v2.runtime.property.ArrayERProperty.serializeBody(ArrayERProperty.java:159)
	at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:344)
	at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:597)
	at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:328)
	at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:498)
	at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:320)
	... 47 more
Caused by: org.mortbay.jetty.EofException
	at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:791)
	at org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:551)
	at org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:572)
	at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:1012)
	at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:651)
	at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:580)
	at com.sun.jersey.spi.container.servlet.WebComponent$Writer.write(WebComponent.java:307)
	at com.sun.jersey.spi.container.ContainerResponse$CommittingOutputStream.write(ContainerResponse.java:134)
	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
	at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282)
	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
	at java.io.OutputStreamWriter.write(OutputStreamWriter.java:207)
	at org.codehaus.jackson.impl.WriterBasedGenerator._flushBuffer(WriterBasedGenerator.java:1812)
	at org.codehaus.jackson.impl.WriterBasedGenerator._writeString(WriterBasedGenerator.java:987)
	at org.codehaus.jackson.impl.WriterBasedGenerator._writeFieldName(WriterBasedGenerator.java:328)
	at org.codehaus.jackson.impl.WriterBasedGenerator.writeFieldName(WriterBasedGenerator.java:197)
	at com.sun.jersey.json.impl.writer.JacksonStringMergingGenerator.writeFieldName(JacksonStringMergingGenerator.java:140)
	at com.sun.jersey.json.impl.writer.Stax2JacksonWriter.writeStartElement(Stax2JacksonWriter.java:183)
	... 63 more
Caused by: java.io.IOException: Connection reset by peer
	at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)

4、yarn队列提交显示队列不存在
用户有个root.etl.streaming的队列，但是使用使用queue=root.etl.streaming报错没有队列，使用queue=etl.streaming也报错没有队列
解决办法：queue指定队列只需要指定最后的队列名，所以queue=streaming后成功

5、用户提交作业一直ACCEPTED状态
1）发现ACCEPTED作业的描述信息中有如下日志：

yarn.scheduler.capacity.maximum-am-resource-percent默认0.25可以适当调大

6、还有一种是对应的队列满了，比如下面情况：
一共34000，已经使用了32768，用户提交任务一种处于ACCEPTED

调大队列的大小~

7、用户有2个队列，default队列分配75%的资源，但是设置最大资源是100%，当使用到75%时任务处于ACCEPTED

原因时yarn.scheduler.capacity.root.default.user-limit-factor参数默认时1，标识一个用户只能使用队列分配的最大值75%，当yarn.scheduler.capacity.root.default.user-limit-factor设置成2时，就可以继续提交到空闲内存
，或者换一个用户提交作业也可以提交到空闲内存

8、用户设置队列acl的提交权限，但是不生效

必须对root设置权限

9、yarn节点下线后再添加回去
(1)、修改去除已下线节点的地址/etc/ecm/hadoop-conf/yarn.exclude
(2)、header节点执行 yarn rmadmin -refreshNodes
(3)、emr控制台启动nm

10、curl http://emr-header-1:8088/cluster 显示没权限

新版本hadoop.http.authentication.simple.anonymous.allowed这个值为false导致访问yarn页面的时候要加上?user.name=xxxxxx，否则没有权限
或者打开权限hadoop.http.authentication.simple.anonymous.allowed改为true，然后重启yarn

11、emr集群重启后2个rm全都standby
问题描述：用户重启rm后2个rm都是standby状态，

先使用hadoop用户执行命令yarn rmadmin -transitionToActive rm1 --forcemanual强制rm1切换成active，但是不成功
看报错信息是zk出现问题，但是使用zkCli.sh是没有问题的，开源资料查询需要调大
“-Djute.maxbuffer=10000000”
逐个重启zk，先启动follower
还是报错，在yarn的环境也添加上/var/lib/ecm-agent/cache/ecm/service/YARN/x.x.x.x.x/package/templates 里找到yarn-env.sh YARN_OPTS = “-Djute.maxbuffer=10000000”
重启yarn，还是报错

使用命令yarn resourcemanager -format-state-store格式化rm的状态存储，

还是报错，只能手动去zk删除对应的任务znode状态
deleteall /rmstore/ZKRMStateRoot/RMAppRoot/application_ 1595251161356_11443
删除后成功
解决办法：作业触发了 ResourceManager zk的异常，修复zk 问题以后重启RM 卡在了一个异常作业上1595251161356_11443，这个情况下，可以清理zk store快速恢复，但是有个异常，所以手动清理了异常作业的zk信息

12、spark on yarn 显示的vcore数量和参数提交的对不上
yarn.scheduler.capacity.resource-calculator
org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator
改成 org.apache.hadoop.yarn.util.resource.DominantResourceCalculator后显示正常

码农公寓

相关文章