云数据流作业在启动前陷入无尽循环

在运行任何应用程序逻辑之前，我有一个在启动阶段卡住的Cloud Dataflow作业。我通过在processElement步骤内部添加了一条日志输出语句来测试此操作，但它没有出现在日志中，因此看起来没有达到。云数据流作业在启动前陷入无尽循环

我可以在日志中看到的是下面的消息，这里面似乎每一分钟：

logger: Starting supervisor: /etc/supervisor/supervisord_watcher.sh: line 36: /proc//oom_score_adj: Permission denied

而且这些每隔几秒钟，其循环：

VM is healthy? true.

http: TLS handshake error from 172.17.0.1:38335: EOF

Job is in state JOB_STATE_RUNNING, will check again in 30 seconds.

工作ID是2015-09-14_06_30_22-15275884222662398973，虽然我有两个额外的工作（2015-09-14_05_59_30-11021392791304643671,2015-09-14_06_08_41-3621035073455045662），我开始上午，并有同样的问题。

关于可能会导致此问题的任何想法？

来源

2015-09-14 Darren Olivier

预期所有工作人员日志消息并与正常操作一致。所以他们没有解释你的工作为什么停滞不前。 –

谢谢杰里米。我怀疑问题在于构建工作本身，它通过一堆数据循环并调用ProcessContext.output（）。可能不是编写它的理想方式。 –

你可以详细说明你的意思吗？“通过一堆数据循环并调用output（）'？如果数据从输入到DoFn中，这应该不是问题（因为它发生在工作人员，在工作完成后）;或者数据来自DoFn中的某个字段或以某种方式被序列化到工作人员那里？ –

这听起来像你的管道有一个BigQuery源，然后是DoFn。在运行DoFn（并因此到达您的打印语句）之前，管道将运行BigQuery导出作业以创建GCS中数据的快照。这可确保管道获取BigQuery表中包含的数据的一致视图。

看起来您的表的BigQuery导出作业似乎需要很长时间。遗憾的是，出口过程没有进展指标。如果您再次运行管道并让其运行更长时间，则应完成导出过程，然后您的DoFn将开始运行。

我们正在研究改进出口工作的用户体验，以及弄清为什么花费的时间比我们预期的要长。

来源

2015-09-15 16:39:44

感谢Ben，这很有道理。其中一次运行花费了两个多小时，没有出现任何明显的表现活动虽然，这看ms对于这个大小的表有点长。 –

您可以通过转到BigQuery，选择表格并选择“导出表格”，选择“JSON（换行符分隔）”作为格式，并为其指定一个云存储目录路径来测试实现到GCS所需的时间。这应该模仿Dataflow执行的导出作业。该表是否来自查询结果？我们已经看到这样的工作需要花费大约2小时在您描述的大小的桌子上。我们正在研究如何改善表现和发生某些事情的迹象。 –

啊，好的。我今天早些时候在桌上做的一项出口似乎运行了这么长时间。再次感谢。 –

云数据流作业在启动前陷入无尽循环

回答

相关问题