Question

我的数据流作业失败，并显示一些神秘消息：java.lang.NullPointerException: nextReportIndex should be non-null when sending an update

有人对这有什么想法吗？

Apache Beam 2.5.0，Java SDK。

{
 insertId:  "5262797621023523329:315192:0:1849696"  
 jsonPayload: {
  exception:  "java.lang.NullPointerException: nextReportIndex should be non-null when sending an update
    at com.google.cloud.dataflow.worker.repackaged.com.google.common.base.Preconditions.checkNotNull(Preconditions.java:787)
    at com.google.cloud.dataflow.worker.WorkItemStatusClient.createStatusUpdate(WorkItemStatusClient.java:236)
    at com.google.cloud.dataflow.worker.WorkItemStatusClient.reportUpdate(WorkItemStatusClient.java:148)
    at com.google.cloud.dataflow.worker.DataflowWorkProgressUpdater.reportProgressHelper(DataflowWorkProgressUpdater.java:90)
    at com.google.cloud.dataflow.worker.util.common.worker.WorkProgressUpdater.reportProgress(WorkProgressUpdater.java:299)
    at com.google.cloud.dataflow.worker.util.common.worker.WorkProgressUpdater.doNextUpdate(WorkProgressUpdater.java:252)
    at com.google.cloud.dataflow.worker.util.common.worker.WorkProgressUpdater.access$000(WorkProgressUpdater.java:41)
    at com.google.cloud.dataflow.worker.util.common.worker.WorkProgressUpdater$1.run(WorkProgressUpdater.java:231)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
"   
  job:  "2018-07-16_22_21_32-17936956005198631499"   
  logger:  "com.google.cloud.dataflow.worker.util.common.worker.WorkProgressUpdater"   
  message:  "Error reporting workitem progress update to Dataflow service: "   
  stage:  "s09"   
  thread:  "56"   
  work:  "2152469729993445222"

更新：只是在Stackdriver上方随机滚动日志（如20页），我看到了此错误：An OutOfMemoryException occurred. Consider specifying higher memory instances in PipelineOptions.可能它们是相关的，尽管尚未在Dataflow UI上报告。

Answer 1

“数据流监视界面”仅显示管道中产生的错误汇总。可以通过Stackdriver查找该表面下的一些错误，例如在工作程序中而不是在管道本身中产生的OOM错误。

但是，我想考虑以Feature Request的形式从Dataflow Monitoring Interface提高OOM可见性。您可以在监控界面或Stackdriver中看到here和here的两个功能请求，以使混洗器错误更明显。

Answer 2

此错误的措辞令人困惑，但是当Dataflow工作程序长时间不响应并且Dataflow服务取消了委派给该工作程序的工作时，通常会发生此错误。稍后，Dataflow工作器再次变得响应，并尝试发送进度更新，但是Dataflow服务已将同一工作项委派给其他工作器，并拒绝进度更新。尽管有这些错误，管道仍然可以成功。

发生这种情况时，您应该尝试确定为什么工作人员变得无响应。典型的情况可能是长时间的垃圾回收，从而垄断了CPU资源。通常，即使清除大量内存，垃圾收集器也非常快，但是当可以释放的内存很少时，垃圾收集器的性能就会很差。

GC操作在jvm-gc记录器中可视化。 GC运行缓慢可能看起来像：

[Full GC (Ergonomics)  
[PSYoungGen: 4142045K->104507K(92054528K)] [ParOldGen: 97348766K->98843177K(109598208K)] 101490811K->98947684K(201652736K), [Metaspace: 70094K->70094K(81920K)], 206.1452492 secs] [Times: user=8260.91 sys=41.22, real=206.15 secs]

请注意，此GC运行时间超过3分钟，太长了。

如果遇到缓慢的GC问题，请尝试使用具有更高mem / vcpu比的工作机类型。如果失败，则后续操作应确保管道没有已知的反模式（例如，使用不会减小输入大小的合并器，例如串联将整个可迭代对象从GBK加载到内存中），以及排除内存泄漏。可以通过分析堆转储来进行后续调查。

发送更新时，nextReportIndex应该为非空

2 个答案: