Question

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

如果没有有用的日志，我唯一的潜在客户就是

一些工人似乎有一个java进程卡在100％CPU

查看/ var / log / dataflow / windmill /对这些工作人员显示警告和错误日志在凌晨2: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。

Answer 1

我们发现问题源于我们自己的代码......

我们的管道中的一个阶段试图从PubSub解压缩其输入。出了点问题，解压缩陷入了CPU限制循环。

为了确定这一点，我们做了以下事情：

使用Google Compute Engine网络界面，我们查看了过去几个小时内每位员工的CPU历史记录。自Apache Beam管道启动以来一直在运行的那些，在凌晨2:35左右，少数人显示CPU使用量急剧增加（！）
我们使用ssh连接到其中一个实例，运行top，并在100％CPU上找到了一个Java进程。
我们无法使用jstack获得堆栈跟踪 - 它报告该进程“似乎不是一个Hotspot VM”。我们可以向pid发出SIGQUIT进行线程转储，但描述符1连接到管道。所以我们用strace -f -s 256 -o strace.out附加到pid，发出SIGQUIT，然后从strace.out重构线程转储。

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

我很想听听是否有人有更好的方式： - ）

Apache Beam上的Apache Beam工作停滞不前 - CPU很高

1 个答案: