java - 如何检查为什么作业在 Google Dataflow 上被杀死(可能 OOM)

Question

我有一个简单的任务。我有一堆文件 (总共 ~100GB)，每一行代表一个实体。我必须将此实体发送到 JanusGraph 服务器。

2018-07-07_05_10_46-8497016571919684639 <- job id

一段时间后，我遇到 OOM，日志显示 Java 被终止。

从数据流 View ，我可以看到以下日志:

工作流程失败。原因:S01:TextIO.Read/Read+ParDo(Anonymous)+ParDo(JanusVertexConsumer) failed., 一个work item尝试了4次都没有成功。每次工作人员最终与服务失去联系。尝试了工作项:

从 stackdriver View ，我可以看到:https://www.dropbox.com/s/zvny7qwhl7hbwyw/Screenshot%202018-07-08%2010.05.33.png?dl=0

日志说:
E Out of memory: Kill process 1180 (java) 分数 1100 or sacrific child
E 终止进程 1180 (java) total-vm:4838044kB, anon-rss:383132kB, file-rss:0kB
更多信息:https://pastebin.com/raw/MftBwUxs

我如何调试正在发生的事情？

Answer 1

目前调试问题的信息太少，因此我提供有关 Dataflow 的一般信息。

1. 我找到日志的最直观方法是转到 Google Cloud Console -> Dataflow -> 选择 name感兴趣的 -> 右上角(错误 + 日志)。
2. 描述了有关监控的更多详细信息here (处于测试阶段)。
3. 描述了对管道进行故障排除的一些基本线索，以及最常见的错误消息 here .

如果您无法解决问题，请使用错误信息更新帖子。

更新

根据超出截止日期错误和您分享的信息，我认为您的工作因内存耗尽而“洗牌”。根据this guide :

Consider one of, or a combination of, the following courses of action:

1. Add more workers. Try setting --numWorkers with a higher value when you run your pipeline.
2. Increase the size of the attached disk for workers. Try setting --diskSizeGb with a higher value when you run your pipeline.
3. Use an SSD-backed persistent disk. Try setting --workerDiskType="compute.googleapis.com/projects//zones//diskTypes/pd-ssd" when you run your pipeline.

更新 2

对于特定的 OOM 错误，您可以使用:

• --dumpHeapOnOOM当 JVM 因 OOM 而崩溃时，将导致在本地保存堆转储。
• --saveHeapDumpsToGcsPath=gs://<path_to_a_gcs_bucket>将导致堆转储在下次 worker 重启时上传到配置的 GCS 路径。这使得下载转储文件以供检查变得容易。确保运行该作业的帐户对存储桶具有写入权限。

请注意，堆转储支持会产生一些开销成本，并且转储可能非常大。这些标志应仅用于调试目的，并且始终在生产作业中禁用。

在 DataflowPipelineDebugOptions methods 上查找其他引用资料.

更新 3

我没有找到关于此的公共(public)文档，但我测试了 Dataflow 缩放 heap JVM size使用机器类型( workerMachineType )，这也可以解决您的问题。我在 GCP 支持部门工作，因此我提交了两个文档请求(一个用于描述页面，另一个用于数据流故障排除页面)以更新文档以介绍此信息。

另一方面，有this related feature request你可能会觉得有用。为其加注星标以使其更显眼。