java - 了解 Spark 容器故障

Question

我有一个在 AWS EMR 上运行的 Spark 作业。它通常会在几个步骤后失败并给出如下错误消息:

2016-08-18 23:29:50,167 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl (Container Monitor): Memory usage of ProcessTree 7031 for container-id container_: 48.6 GB of 52 GB physical memory used; 52.6 GB of 260 GB virtual memory used  
2016-08-18 23:29:53,191 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl (Container Monitor): Memory usage of ProcessTree 7031 for container-id container_: 1.2 MB of 52 GB physical memory used; 110.4 MB of 260 GB virtual memory used   
2016-08-18 23:29:56,208 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl (Container Monitor): Memory usage of ProcessTree 7031 for container-id container_: 1.2 MB of 52 GB physical memory used; 110.4 MB of 260 GB virtual memory used    
2016-08-18 23:29:56,385 WARN org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor (ContainersLauncher #0): Exit code from container container_ is : 52   
2016-08-18 23:29:56,387 WARN org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor (ContainersLauncher #0): Exception from container-launch with container ID: container_ and exit code: 52   
org.apache.hadoop.util.Shell$ExitCodeException: 
  at org.apache.hadoop.util.Shell.runCommand(Shell.java:505)
  at org.apache.hadoop.util.Shell.run(Shell.java:418)
  at org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:650)
  at org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor.launchContainer(DefaultContainerExecutor.java:200)
  at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:300)
  at org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch.call(ContainerLaunch.java:81)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  at java.lang.Thread.run(Thread.java:745)
2016-08-18 23:29:56,393 INFO org.apache.hadoop.yarn.server.nodemanager.ContainerExecutor (ContainersLauncher #0): 
2016-08-18 23:29:56,455 WARN org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch (ContainersLauncher #0): Container exited with a non-zero exit code 52

据我所知，这似乎是一个 OOM 错误。在日志中查看前面我可以看到:

2016-08-18 23:19:00,462 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl (Container Monitor): Memory usage of ProcessTree 7031 for container-id container_: 53.6 GB of 52 GB physical memory used; 104.4 GB of 260 GB virtual memory used   
2016-08-18 23:19:03,480 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl (Container Monitor): Memory usage of ProcessTree 7031 for container-id container_: 53.9 GB of 52 GB physical memory used; 104.4 GB of 260 GB virtual memory used    
2016-08-18 23:19:06,498 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl (Container Monitor): Memory usage of ProcessTree 7031 for container-id container_: 53.9 GB of 52 GB physical memory used; 104.4 GB of 260 GB virtual memory used
2016-08-18 23:19:09,516 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl (Container Monitor): Memory usage of ProcessTree 7031 for container-id container_: 53.8 GB of 52 GB physical memory used; 104.4 GB of 260 GB virtual memory used

我的问题:

1. 这是 OOM 吗？
2. 为什么超额分配(？)和退出之间有 10 分钟的间隔？
3. 我的工作中是否需要更多的执行者，或者我在某处有不正确的参数？

Answer 1

您的第一个问题的答案几乎肯定是"is"。我猜如果你查看 yarn nodemanager 日志，你会看到许多“running beyond physical memory”错误，这基本上是 OOM 的 YARN 语言。

关于问题2，executor遇到OOM当然会挂掉，但一般不会直接挂掉你的job。 YARN 必须对执行器突然死亡具有弹性，因此它只会尝试在其他执行器上再次从失败的执行器重新执行任务。只有当几个执行者死亡时，它才会关闭你的工作。

最后，OOM 的发生可能有多种原因，解决方案取决于原因，因此您必须进行一些挖掘 :) 以下是您可能需要研究的几个典型原因:

1) 如果您还没有这样做，您可能需要增加 spark.memoryOverhead。默认设置取决于可用内存，但我发现它经常太低，所以增加它通常会有帮助。但是，如果您发现需要将 memoryOverhead 增加到可用内存的 1/3 以上，您可能应该寻找其他解决方案。

2) 您可能处于数据非常倾斜的情况，在这种情况下，您可以通过重新分区数据或重新考虑数据的分区方式来解决问题。

3) 您的集群可能根本不够大，无法满足您的需求，或者您运行的实例类型可能不适合您的工作。更改为具有更多内存的实例类型可能会解决您的问题。

通常，我会建议您查看集群在 Ganglia 中的使用情况。如果 Ganglia 只显示几个工作人员在做任何事情，那么您很可能处于场景 2。如果所有工作人员都在使用并且您只是用完了所有可用内存，那么应该考虑场景 3。

希望对您有所帮助。