Domino DBMT 多線程 Updall 造成服務器崩潰

在 Domino 14.0 及以往版本，DBMT（Database Maintenance Tool）可配置多個 Updall 執行緒，以加速資料庫維護，尤其是全文索引（Full‑Text Indexing）。然而，設定此功能時，服務器在某些情況下會發生失敗或持續占用 CPU，進而導致崩潰。本文將針對此問題進行技術說明，整理可行的暫時解決方案並探討長期改善方向。

觀察到的行為

• 啟用 DBMT 的 多線程 Updall（-ut 或 -updallThreads）參數時，服務器在建立、更新資料庫全文索引時劇烈飆升 CPU 負載。
• CPU 使用率往往在 90% 以上持續數分鐘，導致其他重要進程（例如 IRM、協記整合）效能下降，甚至最終使服務器不可用。
• 根據 HCL 官方支援文檔，這種情況被描述為「spike」，但實際上系統 CPU 會被某一執行緒長時間佔用，不能正常釋放（HCL Software, 2023）。

技術根源

Domino DBMT 在複數 Updall 執行緒間共用資料庫視圖索引，進行部分懶惰更新（lazy update）時，會產生以下問題：

• 每條執行緒皆需要鎖定資料庫索引文件，若多個執行緒競爭相同的索引，會造成死鎖或長時間等待。
• 新增文件後，多線程 Updall 依序分配待更新文件，若同時多個執行緒寫入同一索引節點，Write‑Ahead Logging 及 reclamation 會頻繁觸發，導致螺旋式負載（HCL Ideas, 2024）。
• 此現象不僅限於 Updall，其他重量級進程（如離線備份、Restore、甚至 TotalsWrapper）亦會在多執行緒環境下出現類似 CPU 泄漏。

當下可行的緩解措施

1. 限制執行緒數量：將 -updallThreads 設為 1 或 2，可避免過度競爭。
2. 分散資料庫：將大量文件拆分到多個資料庫，以減少單一資料庫的索引大小。此做法在大型企業已相當經典（Toni Feric, 2024）。
3. 使用 Faster Storage： SSD 或 NVMe 儲存可大幅降低磁碟 I/O 延遲，減少 CPU 占用。
4. 利用 Dedicated View Thread（從 9.0.1 FP3 版本起）：將特定視圖交由獨立執行緒更新（最大 25 個），可讓其他流程不必等待視圖更新完畢（HCL Software, 2022）。
5. ——暫存層級的手動歸檔：將不常變更的資料置於「不可丟棄」索引，避免系統在每次 Updall 時必須重新建立索引（Toni Feric, 2024）。

長期改進方向

若要真正突破 Domino 資料庫無法橫向擴縮的根本限制，建議考慮下列技術視角：

• 多執行緒視圖索引模式：為單一視圖設計可並行寫入的資料結構，允許多執行緒同時更新同一視圖節點。這需要在 Domino 核心中再引入 Lock‑free 或讀寫鎖分離的設計。
• 分布式資料庫管理：將資料庫拆分為「日誌」「事實」「系統」三類，並使用水平分區（sharding）與複寫（replication）機制，將全域索引拆解成多點維護。
• 雲端兼容性：將 DBMT 部署於雲端容器或 VMs，利用自動擴縮功能在高峰期臨時增加 CPU 資源，避免單點瓶頸。
• 追蹤與報告：在 HCL Technical Support 認證的排程中加入 HTTP Request（HTTHR） 日誌收集，以即時把握系統負載源頭（HCL Software, 2023）。

結論

Domino DBMT 在多線程 Updall 時的 CPU 泄漏與崩潰問題，雖不易完全消除，但透過限制執行緒數量、分散資料庫、使用 SSD/NVMe、啟用 Dedicated View Thread 以及標記索引為不可丟棄等緩解措施，能在短期內維持系統穩定。長期而言，唯有引入可並行寫入的視圖索引與分布式資料庫架構，才能徹底突破 Domino 本身的擴充性瓶頸。

若您在排查此類問題時需要協助，建議先向 HCL Technical Support 投送 HTTHR 日誌檔案與詳細說明，並參照以下官方資源以獲得進一步指示。

參考文獻