Apache Beam作业在Google Cloud上停滞 - CPU处于高速运行状态

我们正试图调试在Google Cloud上运行的看似部分停顿的Apache Beam作业。我们的工作从PubSub读取消息，以各种方式转换它们，并将结果流式传输到几个BigQuery表格。部分工作仍然活跃 - 我们的几个表正在更新。但其他部分似乎停滞不前，数小时前的最后一次数据库表更新（上午2:35）。不幸的是，我们在日志中看不到有用的例外。我们只有一小部分用户生成的日志消息，每分钟发一次，并且这些消息已经停止，最后一个在上午2:35。大约一个小时后，Beam增加了每个自动扩展管道的工作人员数量，可能会在我们的部分管道中减少积压。Apache Beam作业在Google Cloud上停滞 - CPU处于高速运行状态

没有有用的日志，我唯一的线索是

一些工人似乎都停留在100％的CPU

Java进程看的/ var /日志/数据流/风车/对这些工人显示一个警告和错误日志在上午02点36分更新了的消息像

W0811 02:35:43.005868 19 work_service_client.cc:958] flowingestion-gcla-081020-08101355-256d-harness-jmb 
5 Unable to update setup work item 5076700766800503996 error: DEADLINE_EXCEEDED: Http(504) Gateway Timeout 
E0811 02:36:12.814573 208 work_service_client.cc:689] flowingestion-gcla-081020-08101355-256d-harness-jmb 
5 Lost lease for work with id 1911643509568450683

和

E0811 02:36:12.821274 208 work_service_client.cc:689] flowingestion-gcla-081020-08101355-256d-harness-jmb 
    5 Lost lease for work with id 8994368075509118540 
    E0811 02:36:12.821322 208 work_service_client.cc:689] flowingestion-gcla-081020-08101355-256d-harness-jmb 
    5 Lost lease for work with id 8994368075509118575

有没有人有什么建议去哪里从这里？

如果Google云团队的任何人都可以看一看，我们的工作ID是2017-08-10_13_55_26-6781083469468673800。

来源

2017-08-11 gcla

我们想通了，这个问题从我们自己的代码梗...

一个在我们的流水线阶段的尝试解压缩从PubSub的它的输入。出了点问题，解压缩停留在CPU限制的循环中。

为了确定这一点，我们做了以下内容：使用谷歌Compute Engine的Web界面

，我们彼此看着工人在过去的几个小时的CPU历史。从Apache Beam流水线开始运行以来，少数用户在上午2:35左右显示CPU使用率急剧增加（！）
我们使用ssh连接到其中一个实例，运行最高，并找到了一个100％CPU的Java进程。
我们无法用jstack获取堆栈跟踪 - 它报告过程没有“似乎是一个热点VM”。我们可以向线程转储的pid发出SIGQUIT，但描述符1已连接到管道。所以我们用strace -f -s 256 -o strace.out连接到pid，发出SIGQUIT，然后从strace.out重建线程转储。

输出结果显示在我们自己的代码中运行一个有趣的线程（超过300个）。这揭示了这个问题。

我很想听听有没有人有这样做的更加优美的方式:-)

来源

2017-08-12 01:55:08 gcla

Apache Beam作业在Google Cloud上停滞 - CPU处于高速运行状态

回答

相关问题