[英]How to check why job gets killed on Google Dataflow ( possible OOM )
我有一個簡單的任務。 我有一堆文件( ~100GB in total )
,每行代表一個實體。 我必須將此實體發送到JanusGraph服務器。
2018-07-07_05_10_46-8497016571919684639 <- job id
過了一會兒,我得到了OOM,日志說Java被殺了。
從數據流視圖,我可以看到以下日志:
Workflow failed. Causes: S01:TextIO.Read/Read+ParDo(Anonymous)+ParDo(JanusVertexConsumer) failed., A work item was attempted 4 times without success. Each time the worker eventually lost contact with the service. The work item was attempted on:
從stackdriver視圖,我可以看到: https ://www.dropbox.com/s/zvny7qwhl7hbwyw/Screenshot%202018-07-08%2010.05.33.png?dl =0
日志說: E Out of memory: Kill process 1180 (java) score 1100 or sacrifice child E Killed process 1180 (java) total-vm:4838044kB, anon-rss:383132kB, file-rss:0kB
更多信息: https:/ /pastebin.com/raw/MftBwUxs
我該如何調試正在進行的操作?
現在調試問題的信息太少,所以我提供了有關Dataflow的一般信息。
name
- >右上角(錯誤+日志)。 如果您無法解決問題,請更新包含錯誤信息的帖子。
UPDATE
根據截止日期超出錯誤和您分享的信息,我認為您的工作是因為內存耗盡而“洗牌”。 根據本指南 :
考慮以下行為之一或其組合:
- 添加更多工人。 在運行管道時嘗試設置具有更高值的--numWorkers。
- 增加工人附加磁盤的大小。 在運行管道時,嘗試使用更高的值設置--diskSizeGb。
- 使用SSD支持的永久磁盤。 運行管道時,請嘗試設置--workerDiskType =“compute.googleapis.com/projects//zones//diskTypes/pd-ssd”。
更新2
對於特定的OOM錯誤,您可以使用:
--saveHeapDumpsToGcsPath=gs://<path_to_a_gcs_bucket>
將導致堆轉儲在下次工作重啟時上載到配置的GCS路徑。 這樣可以輕松下載轉儲文件以供檢查。 確保運行作業的帳戶對存儲桶具有寫入權限。 請注意,堆轉儲支持有一些開銷成本,轉儲可能非常大。 這些標志只應用於調試目的,並始終禁用生產作業。
查找有關DataflowPipelineDebugOptions方法的其他參考資料。
更新3
我沒有找到關於此的公開文檔,但我測試了Dataflow使用機器類型( workerMachineType
)擴展heap JVM size
,這也可以解決您的問題。 我使用GCP支持,因此我提交了兩個文檔請求(一個用於描述頁面,另一個用於數據流故障排除頁面)以更新文檔以引入此信息。
另一方面,您可能會發現此相關功能請求很有用。 選擇它以使其更加明顯。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.