診斷失敗的雲數據流管道

我有大約14工時後，雲數據流管道因以下神祕的日誌消息：診斷失敗的雲數據流管道

2016年3月29日，下午八時18分16秒（3253bcfbb8c9c2a7）：工作流失敗。原因：（2bfe8449fe3ba464）：S745（STAGE REDACTED）原因：（1a6d5387c382ba3a）：一個工作項目嘗試了4次，但未成功。每次工作人員最終與服務失去聯繫。該工作項目試圖：（工人削減）

我快速瀏覽了工人日誌，它並不是立即明顯發生了什麼事情。是否應該有這些原因代碼的東西？

troubleshooting guide也沒有特別說明。我最好的猜測是，它屬於「洗牌」類別（作業非常順暢），但是沒有列出的錯誤出現在日誌中。

謝謝！

來源

2016-03-30 Zach Loafman

我按錯誤ID查找了你的工作，似乎由於內存不足錯誤導致工作項目反覆失敗（Java進程被OOM殺手所殺，遺憾的是沒有得到寫入堆轉儲的機會 - 在雲日誌中搜索「oom-killer」以查找相關條目）。

不幸的是，我可以用這些信息來建議，考慮使用更大的實例類型或優化轉換的內存使用（例如，確保它們不會緩衝內存中的大量數據）。

來源

2016-03-30 17:34:25 jkff

跟進：我碰到機器類型爲'n1-highmem-2'，工作完成。你有建議分析內存使用情況？在嘗試這個工作的更大變體之前，看看發生了什麼可能會很好。 –

我現在所能想到的是，ssh到VM並執行一個「jmap」來獲取堆轉儲（可能需要首先將shell放入docker容器 - 使用「docker ps」找到它並「docker附加「在其中運行一個shell），然後將其複製到GCS的某個位置，然後在您的機器上讀取並用內存分析器打開。 – jkff

診斷失敗的雲數據流管道

回答

相關問題