诊断失败的 Cloud Dataflow 流水线

【问题标题】：Diagnosing failed Cloud Dataflow pipeline诊断失败的 Cloud Dataflow 流水线
【发布时间】：2016-03-30 13:06:10
【问题描述】：

在大约 14 个工作小时后，我的 Cloud Dataflow 管道出现故障，并显示以下神秘的日志消息：

2016 年 3 月 29 日晚上 8:18:16 (3253bcfbb8c9c2a7)：工作流失败。原因：(2bfe8449fe3ba464)：S745 (STAGE REDACTED) 原因：(1a6d5387c382ba3a)：一个工作项被尝试了 4 次但没有成功。每次工人最终失去与服务的联系。工作项已尝试：（工人已编辑）

我快速浏览了工作日志，也不是很明显发生了什么。这些原因代码应该有什么东西吗？

troubleshooting guide 在这里也没有特别说明。我最好的猜测是它属于“shuffle-bound”类别（这项工作非常密集），但日志中没有列出的错误。

谢谢！

【问题讨论】：

标签： google-cloud-dataflow

【解决方案1】：

我通过错误 ID 查找了您的工作，似乎工作项由于内存不足错误而反复失败（Java 进程被 OOM 杀手杀死，不幸的是没有机会编写堆转储 - 搜索在云日志中查找“oom-killer”以查找相关条目）。

不幸的是，我只能对这些信息提出建议，考虑使用更大的实例类型或优化转换的内存使用（例如，确保它们不会在内存中缓冲大量数据）。

【讨论】：

跟进：我将机器类型撞到n1-highmem-2 并完成了工作。您对分析内存使用情况有什么建议吗？在我尝试这项工作的更大变体之前，看看发生了什么可能会很好。
我现在能想到的就是，通过 ssh 连接到虚拟机并执行“jmap”以获取堆转储（可能您需要先进入 docker 容器 - 使用“docker ps " 找到它并 "docker attach" 在其中运行 shell)，然后将其复制到 GCS 上的某个位置并在您的计算机上读回它并使用内存分析器打开。