常见问题

集群有状态重启包括哪些内容？

集群有状态重启包括RM Restart和NM Restart两部分，ResourceManager（简称RM）负责维护应用级基础信息与状态，NodeManager（简称NM）负责维护运行时的Container信息与状态，它们持续将相关状态同步至外部存储（Zookeeper、LevelDB和HDFS等），并在重启后重新加载状态自行恢复，保证集群升级或重启后应用自动恢复，通常情况下可以做到应用无感知。

如何启用RM HA？

如何配置热更新？

1. 开启关键配置。

   您可以在EMR控制台YARN服务的配置页签，检查或者配置以下参数。

   参数	描述	参数值（推荐）

   参数	描述	参数值（推荐）
   yarn.scheduler.configuration.store.class	使用的后备存储的类型。例如，设置为fs，表示使用FileSystem类型存储。	fs
   yarn.scheduler.configuration.max.version	保留历史版本的最大数量，超出自动清理。	100
   yarn.scheduler.configuration.fs.path	capacity-scheduler.xml文件存储路径。 不存在存储路径时，则自动创建。不指定前缀时，则默认defaultFs的相对路径。	/yarn/<集群名>/scheduler/conf 重要 将<集群名>替换为集群名称以便区分，可能有多个YARN集群对应同一分布式存储的情况。

2. 查看capacity-scheduler.xml配置。

   • 方式一（REST API）：http://<rm-address>/ws/v1/cluster/scheduler-conf。

   • 方式二（HDFS文件）：${yarn.scheduler.configuration.fs.path}/capacity-scheduler.xml.<timestamp>，其中后缀<timestamp>值最大的文件是最新的配置文件。

3. 更新配置。

   示例：更新一个配置项yarn.scheduler.capacity.maximum-am-resource-percent，并删除配置项yarn.scheduler.capacity.xxx，删除某配置项只需去掉其Value值。

   curl -X PUT -H "Content-type: application/json" 'http://<rm-address>/ws/v1/cluster/scheduler-conf' -d '
   {
     "global-updates": [
       {
         "entry": [{
           "key":"yarn.scheduler.capacity.maximum-am-resource-percent",
           "value":"0.2"
         },{
           "key":"yarn.scheduler.capacity.xxx"
         }]
       }
     ]
   }'

如何处理Queue内应用分配不均？

如何查看队列资源使用情况？

要查看队列资源使用情况，您可以在YARN WebUI页面查看Used Capacity参数。Used Capacity参数表示该队列已使用的资源占该队列整体资源的百分比，分别计算Memory和vCores占总体的比例，并选取最大值作为队列整体资源使用的比例。具体查看操作如下：

1. 访问YARN UI，详情请参见通过控制台访问开源组件Web界面。

2. 在All Applications页面，单击目标作业的ID。

3. 单击Queue行的队列。

   在Application Queues区域，可以查看队列资源使用情况。

   

YARN服务组件.out日志为何会大量堆积且无法自动清理？

• 问题原因：Hadoop组件部分依赖库使用Java Logging APIs来生成日志记录，不支持使用log4j配置的日志轮转。目前这些daemon组件的stderr输出被重定向到.out文件中，没有自动清理机制，长时间积累可能导致数据盘存储空间被占满。

• 处理方法：可以使用head和tail命令结合日志中生成的时间戳信息，来判断是否由于Java Logging APIs生成的日志导致存储空间占用过大。通常情况下，这些依赖库产生的都是INFO级别日志，不影响组件正常功能使用，但为了避免数据盘存储空间被占用，可以采取修改配置的方式禁用此类日志的生成。

  例如，在优化TimelineServer组件以关闭jersey依赖库的日志生成时，操作步骤如下：

  1. 通过以下命令，监控YARN日志路径中与hadoop-timelineserver-相关的.out日志文件。DataLake集群的日志路径为/var/log/emr/yarn/，Hadoop集群日志路径为/mnt/disk1/log/hadoop-yarn。

     tail /var/log/emr/yarn/*-hadoop-timelineserver-*.out

     观察到输出日志中包含由com.sun.jersey组件产生的记录。

     

  2. 为了禁止组件输出Jersey库的INFO级别日志到.out 文件，创建并配置一个文件来关闭其日志生成。在运行有TimelineServer组件的EMR节点上，可以通过执行以下命令以root权限创建并编辑配置文件。

     sudo su root -c "echo 'com.sun.jersey.level = OFF' > $HADOOP_CONF_DIR/off-logging.properties"

  3. 在EMR控制台中YARN服务的配置页面，查找YARN_TIMELINESERVER_OPTS参数（Hadoop集群为yarn_timelineserver_opts），并在此参数值后添加-Djava.util.logging.config.file=off-logging.properties，指定刚刚创建的配置文件位置。

     

  4. 保存上述配置更改后，重启TimelineServer组件使新设置生效。持续观察一段时间，如果TimelineServer组件正常启动，并且.out日志中不再出现任何与com.sun.jersey相关的日志信息，则说明关闭jersey依赖库日志的操作已成功完成。

如何检查ResourceManager服务是否正常？

如何了解应用运行状况？

应用问题排查流程

1. 检查App状态，通过App详情页或App REST API检查App状态。

   • 未找到App状态，可能原因：

     • 客户端向YARN提交之前失败退出：客户端组件问题（检查提交客户端日志：BRS、flowagent等组件）。

     • 客户端无法连接YARN RM：检查连接RM地址是否正确、网络是否存在问题。如有网络问题，客户端可能存在报错：com.aliyun.emr.flow.agent.common.exceptions.EmrFlowException: ###[E40001,RESOURCE_MANAGER]: Failed to access to resource manager, cause: The stream is closed。

   • NEW_SAVING：该状态处于Zookeeper State Store写入应用信息阶段。持续该状态可能原因如下：

     • Zookeeper存在问题，检查Zookeeper服务是否正常。

     • Zookeeper读写数据问题，处理方法请参见RM处于Standby状态，无法自动恢复Active状态，该如何处理？。

   • SUBMITTED：该状态极少遇到，可能原因为Node Update请求太多造成Capacity Scheduler内部抢锁堵塞，通常发生在大规模集群，需优化相关流程。相关案例，请参见YARN-9618。

   • ACCEPTED：检查Diagnostics。请根据提示信息，选择相应的处理方式。

     • 报错提示Queue's AM resource limit exceeded。

       • 可能原因：Queue AM已使用资源和AM资源之和超出了Queue AM资源上限，UI条件为${Used Application Master Resources} + ${AM Resource Request} < ${Max Application Master Resources}。

       • 处理方法：上调该Queue的AM资源上限。例如，设置参数yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent为0.5。

     • 报错提示User's AM resource limit exceeded。

       • 可能原因：Queue user AM已使用资源和AM资源之和超出了Queue user AM资源上限。

       • 处理方法：提高user-limit比例。您可以修改参数yarn.scheduler.capacity.<queue-path>.user-limit-factor和yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent的参数值。

     • 报错提示AM container is launched, waiting for AM container to Register with RM。

       • 可能原因：AM已启动，内部初始化未完成（例如，Zookeeper连接超时等）。

       • 处理方法：需要根据AM日志进一步排查问题。

     • 报错提示Application is Activated, waiting for resources to be assigned for AM。

       执行步骤3，检查AM资源分配为何未满足。

   • RUNNING：执行步骤2，检查Container资源请求是否完成。

   • FAILED：检查diagnostics。请根据提示信息，选择相应的处理方式。

     • 报错提示Maximum system application limit reached,cannot accept submission of application

       • 可能原因：集群内运行中的总应用数超过上限（配置项：yarn.scheduler.capacity.maximum-applications，默认值：10000）。

       • 处理方法：检查JMX Metrics，确认各队列运行的应用数是否符合预期，找出并处理有大量重复提交的问题应用。如果应用都正常，可以根据集群水位情况适当调大上述配置。

     • 报错提示Application XXX submitted by user YYY to unknown queue: ZZZ

       • 可能原因：提交到不存在的queue。

       • 处理方法：提交到已存在的leaf queue。

     • 报错提示Application XXX submitted by user YYY to non-leaf queue: ZZZ

       • 可能原因：提交到parent queue。

       • 处理方法：提交到已存在的leaf queue。

     • 报错提示Queue XXX is STOPPED. Cannot accept submission of application: YYY

       • 可能原因：提交到STOPPED或DRAINING queue（已下线或正在下线的queue）。

       • 处理方法：提交到RUNNING queue（工作状态正常的queue）。

     • 报错提示Queue XXX already has YYY applications, cannot accept submission of application: ZZZ

       • 可能原因：queue应用数达到上限。

       • 处理方法：

         1. 检查queue内是否有大量重复提交的问题应用。

         2. 调整配置：yarn.scheduler.capacity.<queue-path>.maximum-applications。

     • 报错提示Queue XXX already has YYY applications from user ZZZ cannot accept submission of application: AAA

       • 可能原因：user应用数达到上限。

       • 处理方法：

         1. 检查该user是否有大量重复提交的问题应用。

         2. 调整配置：yarn.scheduler.capacity.<queue-path>.maximum-applications、yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent、yarn.scheduler.capacity.<queue-path>.user-limit-factor。

2. 确认YARN资源分配还未完成。

   1. 在apps列表页，单击appID进入AM页面。

   2. 单击下方列表的AM-ID，进入AM-Attempt页面。

   3. 查看Total Outstanding Resource Requests列表中是否有Pending资源（也可以通过PendingRequests REST API查询）：

      • 没有Pending资源：说明YARN已分配完毕，退出该检查流程，检查AM情况。

      • 有Pending资源：说明YARN资源分配未完成，继续下一步检查。

3. 资源限制检查。

   检查集群或Queue资源，查看资源信息，例如，Effective Max Resource和Used Resources。

   1. 检查集群资源或所在Queue资源或其父Queue资源是否已用完。

   2. 检查叶子队列某维度资源是否接近或达到上限。

   3. 当集群资源接近用满时（例如85%以上），应用的分配速度可能会变慢，因为大部分机器都没有资源了，分配的机器没有资源就会reserve，reserve到一定个数后分配就会变慢，另外也可能是由于内存资源和CPU资源不成比例，例如，有的机器上内存资源有空闲但CPU资源已经用满，有的机器上CPU资源有空闲但内存已经用满。

4. 检查是否存在Container资源分配成功但启动失败的情况，YARN UI的App Attempt页面可以看到已分配的Container数（间隔一小段时间观察是否变化），如果有Container启动失败，查看对应的NM日志或Container日志进一步排查失败原因。

5. 动态修改日志级别：在YARN UI的logLevel页面（http://RM_IP:8088/logLevel），将org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity（CapacityScheduler调度逻辑所在的package）参数的日志级别改为DEBUG，如下图所示。

   重要

   您需要在复现问题的同时打开，持续几十秒（由于日志刷新的很快，无需持续太长时间），日志级别改回INFO即可恢复。

单任务/容器（Container）最大可用资源由哪些配置项决定？

YARN配置修改未生效，如何处理？

• 可能原因

  • 非热更新配置，配置关联的组件未重启。

  • 热更新配置，配置生效所需的指定操作未执行。

• 解决方案：请确保相关配置修改的后续操作正确执行。

  配置集	配置类型	更新后续操作

  配置集	配置类型	更新后续操作
  capacity-scheduler.xml fair-scheduler.xml	调度器配置。	热更新配置，需要执行RM组件的refresh_queues操作。
  yarn-env.sh yarn-site.xml mapred-env.sh mapred-site.xml	YARN组件运行配置。	重启配置关联组件。例如： 修改配置yarn-env.sh中的YARN_RESOURCEMANAGER_HEAPSIZE、yarn-site.xml中的yarn.resourcemanager.nodes.exclude-path等配置项后，需重启RM。 修改配置yarn-env.sh中的YARN_NODEMANAGER_HEAPSIZE、yarn-site.xml中的yarn.nodemanager.log-dirs等配置项后，需重启NM。 修改配置mapred-env.sh中的MAPRED_HISTORYSERVER_OPTS、mapred-site.xml中的mapreduce.jobhistory.http.policys等配置项后，需重启MRHistoryServer。

客户端异常，提示Exception while invoking getClusterNodes of class ApplicationClientProtocolPBClientImpl over rm2 after 1 fail over attempts. Trying to fail over immediately

• 问题现象：无法正常访问Active ResourceManager。ResourceManager日志异常，提示信息：WARN org.apache.hadoop.ipc.Server: Incorrect header or version mismatch from 10.33.**.**:53144 got version 6 expected version 9。

• 问题原因：Hadoop版本太旧，导致客户端RPC版本不兼容。

• 处理方法：使用匹配的Hadoop版本。

RM处于Standby状态，无法自动恢复Active状态，该如何处理？

RM组件OOM如何处理？

为什么节点启动任务时Localize失败或任务日志无法采集与删除？

• 问题现象：NM日志异常，提示java.io.IOException: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider。

• 可能原因：HDFS配置异常。

• 处理方法：

  1. 以上是封装后的异常，非根因，需要打开DEBUG级别日志查看：

     • hadoop客户端命令行环境（例如执行hadoop fs -ls /命令），开启DEBUG调试信息。

       export HADOOP_LOGLEVEL=DEBUG

     • 有Log4j配置的运行环境，Log4j末尾增加log4j.logger.org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider=DEBUG。

  2. 以下示例的根因是用户曾修改过NameServices配置，将emr-cluster修改为了hadoop-emr-cluster，但是扩容节点时使用了修改前的配置。

  3. 在EMR控制台HDFS服务的配置页面，检查各项配置是否正确。

资源本地化异常，该如何处理？

• 问题现象：

  • Job AM Container启动失败，异常信息如下。

    Failed job diagnostics信息为：Application application_1412960082388_788293 failed 2 times due to AM Container for appattempt_1412960082388_788293_000002 exited with exitCode: -1000 due to: EPERM: Operation not permitted

  • 在资源本地化过程中（下载后解压时）报错，NodeManager日志信息如下。

    INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Failed to download rsrc { { hdfs://hadoopnnvip.cm6:9000/user/heyuan.lhy/apv/small_apv_20141128.tar.gz, 1417144849604, ARCHIVE, null },pending,[(container_1412960082388_788293_01_000001)],14170282104675332,DOWNLOADING}
    EPERM: Operation not permitted
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmodImpl(Native Method)
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmod(NativeIO.java:226)
            at org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:629)
            at org.apache.hadoop.fs.DelegateToFileSystem.setPermission(DelegateToFileSystem.java:186)
            at org.apache.hadoop.fs.FilterFs.setPermission(FilterFs.java:235)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:949)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:945)
            at org.apache.hadoop.fs.FSLinkResolver.resolve(FSLinkResolver.java:90)
            at org.apache.hadoop.fs.FileContext.setPermission(FileContext.java:945)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:398)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:352)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:57)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)

• 问题原因：压缩包内含有软链接导致资源本地化异常。

• 处理方法：删除该压缩包内包含的软链接。

Container启动失败或运行异常，报错提示No space left on device，该如何处理？

节点NM服务或任务运行时无法正常解析域名，该如何处理？

• 问题现象：报错提示java.net.UnknownHostException: Invalid host name: local host is: (unknown)。

• 问题原因及处理方法：

  • 查看是否正确配置了DNS服务器。

    通过以下命令，检查配置信息。

    cat /etc/resolv.conf

  • 查看防火墙是否设置了53端口的相关规则。

    如果设置了，请关闭防火墙。

  • 查看是否开启了DNS的NSCD缓存服务。

    通过以下命令，检查服务状态。

    systemctl status nscd

    如果开启了DNS的NSCD缓存服务，可以执行以下命令，停止缓存服务。

    systemctl stop nscd

NM组件OOM如何处理？

ECS实例重启后NM启动失败：cgroup目录丢失，如何处理？

• 详细异常信息：ResourceHandlerException: Unexpected: Cannot create yarn cgroup Subsystem:cpu Mount point:/proc/mounts User:hadoop Path:/sys/fs/cgroup/cpu/hadoop-yarn

• 原因：ECS异常重启可能是ECS内核缺陷（已知问题版本：4.19.91 -21.2.al7.x86_64）导致的。重启后CPU cgroup失效问题，原因是重启后cgroup的内存数据会被销毁掉。

• 解决方案：修改存量集群节点执行和扩容节点的引导脚本，在当前环境中创建cgroup目录并且用rc.local在以后ECS启动的时候创建目录。

  # enable cgroups
  mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn
  chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn
  # enable cgroups after reboot
  echo "mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  echo "chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  chmod +x /etc/rc.d/rc.local

修改NM resource配置，保存重启后未生效，如何处理？

• 报错说明：修改yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb参数，保存重启NM后，NM资源数未修改。

• 问题原因：由于机器组可能使用不同CPU内存规格的实例，所以修改yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb参数，需要修改节点组维度的配置才能生效。

• 解决方案：在EMR控制台，选择节点组维度，选择需要配置的NM所在节点组修改资源数的配置，具体操作请参见管理配置项。

节点出现Unhealthy问题，如何处理？

• 原因：

  • 磁盘检查发现异常：当正常目录数或总目录数比率低于磁盘健康比例（yarn-site.xml配置项yarn.nodemanager.disk-health-checker.min-healthy-disks，默认值：0.25）时，将节点标记为UnHealthy。例如NM节点使用4块磁盘，当4块磁盘上的目录均不正常时节点才会标记为UnHealthy，否则只在NM状态报告中显示local-dirs are bad或log-dirs are bad，参见节点磁盘问题：local-dirs are bad/log-dirs are bad，如何处理？。

  • NM健康检查脚本发现异常：该项检查默认未启用，需要主动配置健康检查脚本（yarn-site.xml配置项yarn.nodemanager.health-checker.script.path）才能开启。

• 解决方案

  • 磁盘问题，请参见节点磁盘问题：local-dirs are bad/log-dirs are bad，如何处理？中的解决方案。

  • 健康检查脚本问题，请根据自定义脚本处理。

节点磁盘问题：local-dirs are bad/log-dirs are bad，如何处理？

• 原因：磁盘检查发现异常。该项检查默认开启，周期性检查local-dirs（任务运行缓存目录，包括任务运行依赖的各类文件、中间数据文件等）与log-dirs（任务运行日志目录，包含全部日志运行）是否满足以下条件，只要有一项不满足就会被标记为bad。

  • 可读

  • 可写

  • 可执行

  • 磁盘空间使用率是否低于配置阈值（yarn-site.xml配置项yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage，默认：90%）

    磁盘剩余可用空间是否大于磁盘最小可用空间的配置值（yarn-site.xml配置项yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb，默认：0）

• 解决方案

  • 一般都是磁盘空间不足引起，如果确认存在下述场景之一，建议扩容磁盘：

    • NM节点规格较大，可运行任务数较多。

    • 磁盘空间相对较小。

    • 任务运行所依赖的数据或文件较大。

    • 任务运行产生的中间数据较多。

    • 任务日志相对较大（磁盘空间占比高）。

  • 检查yarn-site.xml配置项yarn.nodemanager.localizer.cache.target-size-mb，如果相对磁盘比例过大会造成历史任务缓存占用磁盘空间过多（超出配置值后才能自动清理）。

  • 坏盘问题，请参见自助坏盘维修流程更换集群损坏的本地盘。

报错提示User [dr.who] is not authorized to view the logs for application ***，该如何处理？

• 问题现象：打开日志页面时，提示信息如下。

• 问题原因：访问NodeManager Log页面时会检查ACL规则。如果启用了ACL规则，远程用户就要符合以下任一个条件：

  • 是admin用户。

  • 是app owner。

  • 满足app自定义ACL规则。

• 处理方法：检查是否满足以上条件中的任一条。

报错提示HTTP ERROR 401 Authentication required或HTTP ERROR 403 Unauthenticated users are not authorized to access this page，该如何处理？

• 问题现象：访问UI或REST API时报错HTTP ERROR 401或HTTP ERROR 403。HTTP ERROR 401详细信息如下图。

  

• 问题原因：YARN启用了Simple认证且不允许匿名访问，详情请参见Authentication for Hadoop HTTP web-consoles。

• 处理方法：

  • 方式一：URL参数中显示指定远程用户，例如，user.name=***。

  • 方式二：您可以在E-MapReduce控制台的HDFS服务的配置页签，在搜索区域搜索参数hadoop.http.authentication.simple.anonymous.allowed，修改其参数值为true允许匿名访问，参数含义请参见Authentication for Hadoop HTTP web-consoles。然后重启服务，请参见重启服务。

为什么TotalVcore显示值不准确？

在YARN UI右上方，Cluster或Metrics REST API结果中，TotalVcore显示值不准确。此问题是由于社区2.9.2之前版本TotalVcore计算逻辑有问题，详情请参见https://issues.apache.org/jira/browse/YARN-8443。

EMR-3.37.x和EMR-5.3.x及后续版本已修复此问题。

TEZ UI展示的应用信息不全，该如何处理？

为什么YARN UI页面有一个正在运行的Spark Thrift JDBC/ODBC Server任务？

如果您在创建集群时选择了Spark服务，集群会自动启动一个默认的Spark Thrift Server服务。该服务会占用一个YARN Driver的资源。在Spark Thrift Server中运行的任务，默认会通过该Driver向YARN申请所需的资源。

yarn.timeline-service.leveldb-timeline-store.path是否支持使用OSS地址？

yarn.timeline-service.leveldb-timeline-store.path参数不支持使用OSS地址。

如果您创建的是Hadoop集群，则yarn.timeline-service.leveldb-timeline-store.path的默认值与hadoop.tmp.dir参数相同。请不要修改HDFS的hadoop.tmp.dir参数，因为这会影响yarn.timeline-service.leveldb-timeline-store.path的配置。

Timeline Server连接超时、CPU或Memory占用异常高问题，该如何处理？

在Tez任务特别多的情况下，写入YARN的Timeline Server时，可能会出现连接超时的问题。这是因为Timeline Server进程占用大量CPU导致节点CPU使用率达到极限，进而影响到了作业开发和其他非核心业务（例如报表生成），所以临时停止TimelineServer进程来减轻节点的CPU负载。您可以通过修改以下配置项来解决此问题。

在EMR控制台修改Tez和YARN服务的相应配置，新增或修改配置的具体操作，请参见管理配置项。

1. 在EMR控制台Tez服务的配置页面的tez-site.xml页签，新增参数为tez.yarn.ats.event.flush.timeout.millis，参数值为60000的配置项，该参数用来设置Tez任务将事件写入YARN的Timeline Server时的超时时间。

2. 在EMR控制台YARN服务的配置页面的yarn-site.xml页签，新增或修改以下配置项。修改完配置项后需要在YARN服务的状态页面重启下TimelineServer。

   参数	参数值	说明

   参数	参数值	说明
   yarn.timeline-service.store-class	org.apache.hadoop.yarn.server.timeline.RollingLevelDBTimelineStore	用于指定YARN Timeline Server的事件存储类。
   yarn.timeline-service.rolling-period	daily	用于设置YARN Timeline Server的事件滚动周期
   yarn.timeline-service.leveldb-timeline-store.read-cache-size	4194304	用于设置YARN Timeline Server LevelDB存储的读取缓存大小。
   yarn.timeline-service.leveldb-timeline-store.write-buffer-size	4194304	用于设置YARN Timeline Server LevelDB存储的写入缓冲区大小。
   yarn.timeline-service.leveldb-timeline-store.max-open-files	500	用于设置YARN Timeline Server LevelDB存储的最大打开文件数。