云服务器内容精选

  • 回答 当nodeSelectPolicy为SEQUENCE,且第一个连接到RM的NM不可用时,RM会在“yarn.nm.liveness-monitor.expiry-interval-ms”属性中指定的周期内,一直尝试为同一个NM分配任务。 可以通过两种方式来避免上述问题: 使用其他的nodeSelectPolicy,如RANDOM。 参考修改集群服务配置参数,进入Yarn“全部配置”页面。在搜索框搜索以下参数,通过“yarn-site.xml”文件更改以下属性: “yarn.resourcemanager.am-scheduling.node-blacklisting-enabled” = “true”; “yarn.resourcemanager.am-scheduling.node-blacklisting-disable-threshold” = “0.5”。
  • 回答 HDFS_DELEGATION_TOKEN到期的异常是由于token没有更新或者超出了最大生命周期。 在token的最大生命周期内确保下面的参数值大于作业的运行时间。 “dfs.namenode.delegation.token.max-lifetime”=“604800000”(默认是一星期) 参考修改集群服务配置参数,进入HDFS“全部配置”页面,在搜索框搜索该参数。 建议在token的最大生命周期内参数值为多倍小时数。
  • 回答 通过集群将非ViewFS文件系统配置为ViewFS时,ViewFS中的文件夹的用户权限与默认NameService中的非ViewFS不同。因为目录权限不匹配,所以已提交的MR作业运行失败。 在集群中配置ViewFS的用户,需要检查并校验目录权限。在提交作业之前,应按照默认的NameService文件夹权限更改ViewFS文件夹权限。 下表列出了ViewFS中配置的目录的默认权限结构。如果配置的目录权限与下表不匹配,则必须相应地更改目录权限。 表1 ViewFS中配置的目录的默认权限结构 参数 描述 默认值 默认值及其父目录的默认权限 yarn.nodemanager.remote-app-log-dir 在默认文件系统上(通常是HDFS),指定NM应将日志聚合到哪个目录。 logs 777 yarn.nodemanager.remote-app-log-archive-dir 将日志归档的目录。 - 777 yarn.app.mapreduce.am.staging-dir 提交作业时使用的staging目录。 /tmp/hadoop-yarn/staging 777 mapreduce.jobhistory.intermediate-done-dir MapReduce作业记录历史文件的目录。 ${yarn.app.mapreduce.am.staging-dir}/history/done_intermediate 777 mapreduce.jobhistory.done-dir 由MR JobHistory Server管理的历史文件的目录。 ${yarn.app.mapreduce.am.staging-dir}/history/done 777
  • 回答 运行包含Reduce的Mapreduce任务时,通过-Dmapreduce.job.map.output.collector.class=org.apache.hadoop.mapred.nativetask.NativeMapOutputCollectorDelegator命令开启Native Task特性,任务在部分操作系统运行失败,日志中提示错误“version 'GLIBCXX_3.4.20' not found”。该问题原因是操作系统的GLIBCXX版本较低,导致该特性依赖的libnativetask.so.1.0.0库无法加载,进而导致任务失败。 规避手段: 设置配置项mapreduce.job.map.output.collector.class的值为org.apache.hadoop.mapred.MapTask$MapOutputBuffer。
  • 回答 在YARN中,当一个APP的节点被AM(ApplicationMaster)加入黑名单的数量达到一定比例(默认值为节点总数的33%)时,该AM会自动释放黑名单,从而不会出现由于所有可用节点都被加入黑名单而任务无法获取节点资源的现象。 在资源池场景下,假设该集群上有8个节点,通过NodeLabel特性将集群划分为两个资源池,pool A和pool B,其中pool B包含两个节点。用户提交了一个任务App1到pool B,由于HDFS空间不足,App1运行失败,导致pool B的两个节点都被App1的AM加入了黑名单,根据上述原则,2个节点小于8个节点的33%,所以YARN不会释放黑名单,使得App1一直无法得到资源而保持运行状态,后续即使被加入黑名单的节点恢复,App1也无法得到资源。 由于上述原则不适用于资源池场景,所以目前可通过调整客户端参数(路径为“客户端安装路径/Yarn/config/yarn-site.xml”)“yarn.resourcemanager.am-scheduling.node-blacklisting-disable-threshold”为:(nodes number of pool / total nodes )* 33%解决该问题。
  • 回答 这是RM的使用限制,应用程序运行过程中移动到别的队列,此时RM重启,RM并不会在状态存储中存储新队列的信息。 假设用户提交一个MR任务到叶子队列test11上。当任务运行时,删除叶子队列test11,这时提交队列自动变为lost_and_found队列(找不到队列的任务会被放入lost_and_found队列中),任务暂停运行。要启动该任务,用户将任务移动到叶子队列test21上。在将任务移动到叶子队列test21后,任务继续运行,此时RM重启,重启后显示提交队列为lost_and_found队列,而不是test21队列。 发生上述情况的原因是,任务未完成时,RM状态存储中存储的还是应用程序移动前的队列状态。唯一的解决办法就是等RM重启后,再次移动应用程序,将新的队列状态信息写入状态存储中。