1：解决与空间相关的问题
2：解决内存问题
3：处理不同类型的故障
4：对Spark作业执行进行故障排除
我要继续讲这本书的最后一章，简短而有趣。故障排除是一个广阔的领域，我想让您了解一下您可能在hadoop集群中遇到的一些更有趣的问题。hadoop有很多 配置属性，并且掌握这些属性对于充分利用hadoop集群的投资至关重要。 但是，通过重新配置hadoop的各种组件，只能解决您每天遇到的一些错误。
我不认为对群集中运行的Hive，Spark或其他作业运行不佳的性能进行分析是故障排除。 “挂起”或长期运行的原因可能是由于代码不正确或操作员选择不当，连接策略效率低下或其他原因所致。 同样，我也不会尝试讨论进程（例如Hive或Hue）无法启动或崩溃的原因，这些原因通常又是由于主机服务器或组件上的配置错误/更改而引起的， 造成此类故障的原因很多，它们都属于任何类型的常规系统管理，并且并不是Hadoop管理真正的专用。
有空间有关的问题
hadoop使用几种类型的存储。除了hdfs本身之外，hadoop还将日志存储在主机的/ var目录以及本地目录中，这些区域中任何一个与空间相关的问题都可能导致作业失败，因此最好在本地目录上进行操作。
正如您在第17章“监视，指标和Hadoop日志记录”中所了解的那样，NodeManager始终将应用程序日志文件存储在本地目录中。 即使在启用日志聚合（Hadoop将作业日志存储在HDFS中）的情况下，也是如此，因为所有日志都首先存储在本地存储中。 如果日志目录所在的挂载点已满，则NodeManager将无法在该节点上写入其日志文件。 如果Hadoop守护程序正在记录的目录已满，情况也是如此。
为避免任务和潜在的作业失败，您必须主动检查这些安装点下的可用空间，并清除所有不必要的文件。 如果无法删除足够的空间，则可能需要扩展安装点本身的大小。
您可以通过在存在问题空间的节点上运行以下命令来确定要从这些目录中删除哪些文件：
find ./ -size +100000 –type f –ls |sort -n //查询文件大于25MB的文件
du -a /var |sort –n –r |head –n 10 //查询一个目录里面10大的文件
如果将NodeManager使用的Hadoop守护程序日志和应用程序本地目录的位置设置为/ var目录，请理解该目录与tmp等其他目录共享根文件系统（“ /”分区）。 除了Hadoop守护进程和NodeManager应用程序日志之外，您可能还使用/ var目录记录来自多个与Hadoop相关的组件（例如ZooKeeper，Hive和Hue）的输出。 因此，需要编写一个简单的shell脚本，该脚本会在此安装点警告您空间不足的情况。
如果用yarn.nodemanager.local-dirs参数指定的NodeManager本地目录在某个节点上填满，则应用程序可能会失败，因为它尝试在该节点上启动的任务数量超过配置的尝试次数。 在应用程序的日志文件中，您将收到与以下内容类似的错误：
Application application_1437683566204_0394 failed 2 times due to AM Container for
appattempt_1437683566204_0394_000002 exited with exitCode: -1000 due to:No space available in any of the local directories. .Failing this attempt.. Failing the application.
处理100％完整的linux文件系统
有时，文件系统可能会报告它已100％充满。 如果这恰好是根文件系统之类的挂载点，则将立即引发麻烦，因为这是大多数文件存储其Hadoop相关本地日志（在/ var / log下）的地方。 显然，某些用户生成了一个大的转储文件，或者一个巨大的临时文件存储在已满的目录中。 请按照以下步骤释放已用完的目录中的空间.
使用find命令确定安装点下最大的文件。 这是一个这样的命令：
du –a /var |sort –n –r |head –n 10
确定最大的文件后，请删除对集群操作不重要的所有文件。
Hdfs 空间问题
HDFS空间问题可能有两种类型：第一种是群集中的HDFS可用空间不足时。 第二种情况是个别用户违反了您分配给他们的HDFS配额。 这些用户也可以称为功能帐户，即您用来提交作业的通用用户名，例如名为produser的HDFS用户。
如果群集中HDFS的可用空间越来越少，有两种基本的解决方案可用于增加空间：添加更多节点或向现有节点添加更多磁盘。
可以增加可用HDFS空间的另一种方法是删除不再需要的数据，并减少历史数据的复制因子，这些历史数据被认为与新数据没有那么重要。
如果用户发布的作业由于达到其最大配置的HDFS空间配额而失败，则需要使用dfsadmin setSpaceQuota命令增加用户的空间配额，如第9章“ HDFS命令，HDFS权限和HDFS存储”中所述。 ”
要保持与HDFS配额相关的问题的领先地位，一种方法是定期运行以下命令，该命令显示我所有用户当前对HDFS空间的使用情况以及每个用户仍在使用的HDFS空间配额的范围 有：
hdfs dfs -count -q -h /user/* 查看某个空间配额
hdfs dfs –count q –h命令的部分输出显示，用户alapati已使用了该用户分配的30GB空间配额中的10GB。 因此，该用户的空间配额还剩下20GB。 如果用户不满分配的空间配额，请使用dfsadmin -setSpaceQuota命令增加空间配额。
本地和日志目录的可用空间不足
在本章的前面，您了解了可以使用yarn.nodemanager.local-dirs参数指定NodeManager的本地目录，并使用yarn.nodemanager.log-dirs参数指定NodeManager的日志目录。 Hadoop会定期执行磁盘运行状况检查。 如果可用空间低于阈值，则NodeManager将在其运行的节点上不启动任何新容器。
两个关键参数（yarn.nodemanager.disk-health-checker.min-healthydisks和yarn.nodemanager.disk-health-checker.max-disk-utilization-perdisk-percentage）在NodeManager的行为方式中起着至关重要的作用。 本地目录或日志目录空间不足的问题。 这是两个参数如何确定Hadoop在每个存储磁盘上使用的空间百分比，以及它如何认为节点具有足够数量的正常存储驱动器：
yarn.nodemanager.disk-health-checker.max-disk-utilization-per diskpercentage：一旦磁盘达到此参数设置的空间利用阈值，它就会被标记为不良（或不正常）。 您可以为此参数设置一个介于0.0和100.0之间的值，默认值为90.0。 一旦磁盘使用率超过90％，仍可以使用，但内部标记为不良或运行不正常。 请记住，这适用于您指定为yarn-nodemanager.local-dirs和yarn.nodemanager.log-dirs参数值的目录。
yarn.nodemanager.disk-health-checker.min-healthy-disks：此参数确定节点上必须健康的磁盘总数的最小比例。 如果节点上的正常驱动器（本地目录或日志目录）的数量低于此阈值，则NodeManager不会在该节点上启动新容器。 实际上，只要进行处理，该节点就会从群集中移出。 此参数的默认值为0.25。 如果节点上有十二个磁盘，这意味着它们中至少有四分之一（即三个驱动器）必须处于正常状态才能使NodeManager在该节点上启动新容器。
假设您正在使用yarn.nodemanager.disk-healthchecker.max-disk-utilization-per-disk-percentage和yarn.nodemanager的默认值
.disk-health-checker.min-healthy-disks参数。 如果空间有限，并且12个驱动器节点上的10个以上驱动器达到90％的阈值，则NodeManager
不能在这些节点上启动容器，这意味着该节点上作业的新任务将失败，并且您会看到类似以下的错误：
假设您同时使用yarn.nodemanager.disk-healthchecker.max-disk-utilization-per-disk-percentage和yarn.nodemanager.disk-health-checker.min-healthy-disks参数的默认值。 如果空间有限，并且12个驱动器节点上的10个以上驱动器达到90％的阈值，则NodeManager将阻止在这些节点上启动容器-这意味着作业在该节点上的新任务将失败，您将 看到如下错误：
Application Type: MAPREDUCE
Application Tags:
State: FAILED
FinalStatus: FAILED
Started: Sat Jul 16 04:01:10 -0500 2016
Elapsed: 13sec
Tracking URL: History
Diagnostics:
Application application_1437683566204_0350 failed 2 times due to AM Container for
appattempt_1437683566204_0350_000002 exited with exitCode: -1000 due to: No space
available in any of the local directories.
.Failing this attempt.. Failing the application.
该错误表明NodeManager拒绝启动ID为000002的任务，因为超过了“最小数量”的最小磁盘“不健康”。在3TB驱动器上，90％的已用空间意味着仍有300GB的可用空间，并且很可能可以继续使用 驱动器。 在这种情况下，您可以执行以下两项操作之一（或同时执行两项操作）：
通过为yarn.nodemanager.disk-health-checker.max-disk-utilization-per-diskpercentage参数设置较低的值，降低将磁盘标记为不良的阈值。
通过设置yarn.nodemanager.disk-health-checker.min-healthy-disks参数来降低健康驱动器的最小数量。
显然，最好的长期解决方案是为群集获取更多节点。 参数yarn.nodemanager.disk-health-checker.min-free-spaceper-disk-mb确定NodeManager要使用的目录的本地目录和日志目录中应该有多少可用空间。 默认值为0。
磁盘卷容错
如果集群中很小一部分的DataNode都已失效，则无需担心，尝试建立这些节点-Hadoop集群中需要处理的更好，更关键的事情！ 但是，请务必跟踪死节点的数量，并且当死节点的数量达到可观数量时，请努力使这些节点恢复原状。 与传统的数据库不同，在传统的数据库中丢失磁盘可能会造成灾难性的影响，即使发生存储故障，Hadoop也会轻松应对。 您的群集将以相同的方式运行，但总存储容量较小。 与传统RAID系统不同，您可以在方便时修复故障磁盘。 您可以通过设置以下参数来配置节点可以容忍多少磁盘故障：
<property>
<name>dfs.datanode.failed.volumes.tolerated</name>
<value>4</value>
</property>
在这种情况下，Hadoop可以在将DataNode列入黑名单之前容忍四个磁盘卷出现故障。 重要的是要了解，默认情况下，单个卷（磁盘驱动器）发生故障后，DataNode将关闭。 因此，dfs.datanode.failed.volumes.tolerated参数的默认值为零。 确保将其设置为2、3或4之类的正数，以确保在单个卷出现故障后DataNodes不会关闭。 一旦失败次数达到您设置的次数，DataNode将被标记为“死节点”。
找出Hadoop集群中是否有任何失败的卷的最简单方法是查看NameNode UI的Datanode Volume Failures页面，如图21.1所示。
图21.1 NameNode UI的DataNode Volume Failures页面，显示失败的卷数
热替换盘
您可以添加或替换磁盘驱动器而无需关闭DataNode，因为Hadoop支持DataNodes的热插拔驱动器。 您需要使用新命令dfsadmin –reconfig datanode来执行热交换。 以下是磁盘驱动器热交换过程的高级说明。
1，格式化并安装新的磁盘驱动器。
2，更新hdfs-site.xml文件中的dfs.datanode.data.dir配置属性。 删除要替换的故障数据卷，然后添加新数据卷
3，执行dfsadmin -reconfig datanode HOST：PORT start命令开始重新配置。
4.卸载已删除的数据卷目录，并在重新配置任务完成后从服务器中删除磁盘。
设置dfs.datanode.du.reserved参数
在第3章“创建和配置简单的Hadoop 2集群”中，您了解了hdfs-site.xml文件中的dfs.datanode.du.reserved参数如何让您设置保留空间的数量（每卷字节数） 用于非HDFS。 尽管存储HDFS文件的目录主要是供HDFS使用的，但它们并不完全供HDFS使用。 该目录还保存Hadoop作业的临时数据。 确保留出足够的空间来容纳您希望运行的最大Hadoop作业的临时数据。
很好地使用复制英子
Hadoop使用默认复制级别3，如第3章所述，并在其他位置重复说明。 当然，更高的复制因子意味着更高的磁盘空间使用率，但是更高级别的复制也有其优势。 高复制级别具有两个明显的好处：
更快的性能，尤其是在处理多个应用程序所需的“热”数据时。
可靠性更高-复制级别越高，从存储角度来看，数据越可靠。
一直处理accepted State 的yarn job 问题
有时，您可能会遇到在YARN中启动Spark（或MapReduce）应用程序但从未使其进入RUNNING状态的情况。 作业只是停留在“接受”状态。 当Oozie启动作业或您手动运行它时，可能会发生同样的事情。 作业将停留在“接受”状态，并且不会转换为“正在运行”状态。 如果您查看ResourceManager的网络用户界面，您还将看到作业状态为“已接受”。 如果您查看应用程序日志，则会看到类似以下的消息：
2016-09-01 00:48:14,121 INFO org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler:Added Application Attempt appattempt_1420073214126_0002_000001 to scheduler from user: admin
2015-09-01 00:48:14,121 INFO org.apache.hadoop.yarn.server.resourcemanager.rmapp.attempt.RMAppAttemptImpl:
appattempt_1420073214126_0002_000001 State change from SUBMITTED to SCHEDULED
您别无选择，只能在大多数情况下杀死这些作业（yarn application –kill <appid>），然后手动或通过使下一个预定的Oozie作业开始新的作业来重新运行它们。 诊断和解决停滞的工作问题通常很容易。 我将说明如何在两种常见情况下解决此问题。
造成工作停滞不前（可能永远消失）的主要原因是缺乏足够的资源来启动工作。 如果一项工作要求为一个容器（例如64GB）请求大量的RAM，但是群集中没有节点具有64GB的可用内存，则YARN将不会启动该工作。 在这种情况下，您无能为力，但要等到一段时间后释放出足够的内存来启动作业。 您需要重新启动该作业，因为它不会自行过渡到“已接受”状态。 从长远来看，您可能希望探索增加群集节点的RAM。
作业可能永远处于“挂起”状态的另一个原因是，您通过“公平调度程序”或“容量调度程序”限制了最大的作业数量。 为确保您没有将可同时运行的最大作业数设置得太低，如果您正在使用Fair Scheduler在集群中分配资源，请检查maxRunningApps队列元素的值（这将限制 队列中立即运行的队列）。 maxRunningApps属性设置了用户可以随时运行的最大应用程序数的限制。 如果您使用的是Capacity Scheduler，请检查Capacity-scheduler.xml文件中以下属性的值（这些属性设置在运行和挂起状态下可以同时活动的最大应用程序数）：
yarn.scheduler.capacity.maximumapplications/ yarn.scheduler.capacity.<queuepath>.maximum-applications
当然，如果您使用的是Cloudera Manager之类的工具，则需要通过该工具进行更改。 例如，如果您使用的是Cloudera Manager，则可以通过转到集群>动态资源池>配置来实现。 此时，您可以先单击“默认设置”，然后检查“每个资源池的最大正在运行的应用程序”属性的值。 接下来，您需要编辑从中启动该应用程序的特定资源池的配置，并增加Max Running Apps配置属性的值。
JVM内存分配和垃圾回收策略
一切都在Hadoop的Java虚拟机（JVM）中运行。 要进行良好的故障排除，您必须了解JVM如何分配内存以及它们如何执行垃圾回收，这是JVM如何回收较旧和未使用的内存，以便可以将其分配给其他用途。 不同的垃圾收集策略对集群中应用程序的性能有不同的影响。
第17章“监视，指标和Hadoop日志记录”介绍了如何通过Ganglia或通过查看各种Hadoop日志来监视群集。 如果一切都失败了，该是回顾Java堆转储以找出YARN容器中问题的根本原因了！
了解jvm垃圾回收
Java堆是存储Java程序对象的位置。 如第3章和第18章“调整群集资源，优化MapReduce作业和基准测试”所述，当您为映射分配内存或减少容器的JVM时，正是这些参数确定了YARN容器的Java堆大小。 堆可以包含活动对象，无效对象和空闲的未分配内存。 如果没有正在运行的程序可以到达堆中的特定对象，则将其视为“垃圾”，并且JVM准备将其从堆中删除。 垃圾回收是JVM释放Java堆中未使用的Java对象的方式。
每个JVM的堆都包括三个独立的部分，称为世代。 这三代人分别是年轻的（新一代），老的和永久的。 JVM使用–Xms选项为年轻人和老年人分配初始大小，而段的最大大小由–Xmx选项设置。 您还可以使用–XX：NewSize选项初始化年轻代的大小，并使用–XX：Newratio选项指定老一代的大小。 如果将–XX：NewRatio参数设置为3，则表示旧一代的大小是新一代的三倍。
图21.2显示了Java堆中的世代
