长时间运行的 Dataflow 作业失败，用户代码中没有错误答案

【问题标题】：Long-running Dataflow job fails with no errors in user code长时间运行的 Dataflow 作业失败，用户代码中没有错误
【发布时间】：2019-10-07 17:17:15
【问题描述】：

运行 17 小时后，我的 Dataflow 作业失败并显示以下消息：

The job failed because a work item has failed 4 times. Look in previous log entries for the cause of each one of the 4 failures.

4 次失败包括 3 名工作人员与服务失去联系，一名工作人员报告死亡：

****-q15f Root cause: The worker lost contact with the service.
****-pq33 Root cause: The worker lost contact with the service.
****-fzdp Root cause: The worker ****-fzdp has been reported dead. Aborting lease 4624388267005979538.
****-nd4r Root cause: The worker lost contact with the service.

我在 Stackdriver 中的作业的工作人员日志中看不到任何错误。这只是运气不好？我不知道工作项需要重试的频率，所以我不知道单个工作项在 24 小时工作过程中失败 4 次的概率是多少。但是对于这个长时间运行的工作来说，这种相同类型的工作失败经常发生，所以我们似乎需要一些方法来降低工作项的失败率，或者增加允许的重试次数。有可能吗？这似乎与我的管道代码无关，但如果相关，我将 Python SDK 与apache-beam==2.15.0 一起使用。如有任何关于如何调试的建议，我将不胜感激。

更新：控制台中的“堆栈跟踪”部分完全为空。

【问题讨论】：

我遇到了同样的问题。工作人员的堆栈驱动程序上似乎也没有任何错误。
很抱歉您遇到了这个问题。您应该为此类问题提交支持票，因为没有足够的信息来弄清楚发生了什么。可能发生的情况是工作人员内存不足（ooming），并且没有正确向服务发送更新 - 您的操作是否占用大量内存？

标签： google-cloud-platform google-cloud-dataflow apache-beam

【解决方案1】：

我遇到了同样的问题，通过扩大我的工人资源得到了解决。具体来说，我在管道配置中设置了--machine_type=n1-highcpu-96。有关机器类型选项的更广泛列表，请参阅 this。

编辑：根据管道流程的要求将其设置为highcpu 或highmem

【讨论】：

谢谢，我会试试看！我知道这项工作非常耗费内存。