Tableau Server Extract Refresh 工作無限排隊，Backgrounder 因 Java Heap 記憶體限制而停止處理

您好，

根據您的描述，這種情況與 Backgrounder 資源耗盡 的現象一致，也就是 Extract Refresh（擷取重新整理）工作累積的速度超過處理速度，最終導致佇列過長以及排程工作停滯。建議首先使用 TSM 檢查目前的程序拓撲結構，並確認每個節點配置了多少個 Backgrounder 程序，同時比較各節點可用的 CPU 與記憶體資源。

在驗證拓撲結構時，請檢查目前的程序分布情況，並確認 Backgrounder 是否與 VizQL Server、Data Server 或 Repository 等其他服務產生嚴重的資源競爭。如果 Backgrounder 工作負載主要集中在單一節點上，可以考慮將程序重新分配到其他可用節點，這通常可以顯著提升整體處理吞吐量。此外，也建議檢查佇列開始增加時段的 Backgrounder 記錄，以確認是否存在記憶體壓力、Extract 失敗或長時間執行的工作導致待處理工作累積。

關於 Java Heap（Java 堆積）大小，如果工作確實因為記憶體限制而失敗，增加 Heap 配置可能會有所幫助。不過，我建議將此視為整體容量評估的一部分，而不是唯一的解決方案。如果 Extract 檔案較大或數量較多，增加 Backgrounder 容量並將重新整理排程合理分散到一天中的不同時段，通常會比單純增加 Heap 大小更加有效。將重新整理排程分散到多個時間區段，可以大幅降低尖峰時段的資源競爭。

作為最佳實務，建議連續幾個業務週期監控佇列長度、Backgrounder 使用率、記憶體使用量以及 Extract 執行時間。這些資料有助於判斷瓶頸究竟來自程序配置、Heap 限制、硬體資源不足，還是排程模式。在許多環境中，結合拓撲最佳化、工作負載分配以及適度的記憶體調整，通常可以取得更好的長期效果。

希望這些建議能協助您進一步定位問題。如果您覺得這個回答對您有幫助，請點擊 「Accept Answer」，讓我知道這個回答已經解決了您的問題。

Jason

我想跟進確認一下，您的問題是否已經解決。如果您還需要更多資訊，歡迎隨時回覆。 如果上述資訊對您有所幫助，歡迎點擊 「Accept Answer」，幫助社群中的其他使用者找到解決方案。謝謝！