修正 Zimbra Amavis 佔用 100% CPU 且不中斷郵件流的問題

一個好的解決方案應該是什麼樣的？

當某個amavisd行程的 CPU 使用率達到或接近 100% 時，目標並非只是讓該行程停止運作。有效的修復方案應該恢復正常的郵件流，降低處理延遲，確保反垃圾郵件和防毒保護功能正常運行，並防止 Postfix 佇列持續成長。

在 Zimbra 中，Amavisd-New 位於郵件傳輸代理程式 (MTA) 和內容掃描器之間。 Zimbra 目前的 Daffodil 管理指南將 Amavisd-New 描述為 Zimbra MTA、ClamAV 和 SpamAssassin 之間的介面。這意味著 CPU 使用率飆升可能來自 Amavis 本身、SpamAssassin 規則或郵件內容、防毒掃描，或積壓的請求佔用所有可用工作流程。請參閱Zimbra Daffodil 管理員指南。

成功解決問題有四個跡象：Amavis CPU 使用率降至穩定水平，延遲佇列和活動佇列停止成長，新郵件處理速度正常，反垃圾郵件/防毒服務運作良好。如果 CPU 使用率下降只是因為過濾功能被停用，則根本問題尚未解決。

步驟 1：確認 Amavis 確實是 CPU 佔用最多的進程。

先從作業系統層面入手。不要因為郵件投遞速度慢就斷定是 Amavis 的問題。檢查最繁忙的進程，確認是否有一個或多個amavisd工作進程持續佔用一個完整的 CPU 核心。

top -c

ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -20

終端機顯示 amavisd 進程 CPU 使用率接近 100%，而其他 Zimbra 進程的 CPU 使用率則低得多。

圖註：終端視圖顯示 amavisd 是主要的 CPU 消耗者，這是在更改 Zimbra 設定之前需要驗證的第一個條件。

掃描大型郵件或壓縮附件時，出現短暫的 CPU 使用率高峰可能是正常現象。如果郵件延遲或佇列深度增加，且症狀持續存在，則應將問題視為持續性問題。此外，還應檢查平均負載、可用記憶體、交換空間活動和 I/O 等待時間。如果 CPU 使用率過高且有嚴重的交換空間或儲存爭用，則可能需要進行更廣泛的主機級調查，而不僅僅是修改 Amavis 的配置。

步驟 2：重新啟動任何服務之前，請檢查 Zimbra 服務的運作狀況。

切換到 Zimbra 帳戶並查看服務狀態。 Zimbra 文件使用zmcontrol status標準方法來檢查已啟用服務。

su - zimbra
zmcontrol status
zmamavisdctl status

終端顯示 Zimbra 反垃圾郵件、防毒、Amavis 和 MTA 服務正在運行

圖註：Zimbra 服務狀態顯示 Amavis、反垃圾郵件、防毒和 MTA 元件在故障排除開始前正在運作。

這一步驟至關重要，因為「CPU佔用率100%」和「服務宕機」是不同的故障模式。如果Amavis沒有運行，請轉而調查啟動錯誤。如果Amavis正在運作但CPU已飽和，請繼續進行佇列和日誌分析。

步驟 3：測量郵件佇列，而不僅僅是 CPU 使用率

佇列深度可以告訴您高 CPU 使用率是否會影響郵件投遞。 Zimbra 的佇列故障排除資料文件zmqstat包含佇列計數信息，Postfix 佇列指令包含郵件詳細資訊。請每隔幾分鐘重複執行這些檢查。

sudo /opt/zimbra/libexec/zmqstat
postqueue -p

終端機顯示 Zimbra Postfix 佇列中存在延遲訊息，而 Amavis 伺服器正處於負載狀態。

標題：佇列統計資訊和延遲郵件比單獨的 CPU 使用率更能衡量郵件流的影響。

要專注於趨勢，而不是某個孤立的數字。如果每次採樣佇列都在上升，則表示吞吐量低於到達率。隊列在變更後持續下降，這是變更確實有效的有力證據之一。

如果您執行的是多 MTA 部署，請特別檢查受影響的 MTA 節點。不要假設其他節點上的佇列也反映了同樣的瓶頸。

步驟 4：使用 Zimbra 日誌辨識慢速階段

Amavis 和 SpamAssassin 的故障排除訊息會寫入/var/log/zimbra.log。搜尋 CPU 使用率高峰出現前後的時間點，並將訊息 ID、進程 ID 和掃描持續時間關聯起來。

grep -iE 'amavis|spamassassin|clam' /var/log/zimbra.log | tail -n 200

終端機顯示 Zimbra 日誌中有關 Amavis 和 SpamAssassin 郵件掃描的處理時間條目

標題：Amavis 和 SpamAssassin 的日誌行可以揭示單一訊息或掃描階段是否耗時異常長。

有用的模式包括：重複的長時間 SpamAssassin 掃描、針對相同佇列 ID 的重複重試、ClamAV 通訊錯誤、解壓縮相關故障，或少量郵件重複佔用工作進程資源。 Zimbra 的故障排除文件特別建議，當掃描延遲導致郵件流中斷時，應啟用 Amavis 和 SpamAssassin 的偵錯日誌記錄。請參閱Zimbra 的日誌記錄故障排除參考。

步驟 5：如果常規日誌不足以得出結論，請暫時增加 Amavis 日誌記錄等級。

Zimbra 為 Amavis 和 SpamAssassin 提供了獨立的日誌記錄控制。 Amavis 的日誌等級範圍為 0 到 5，而zimbraAmavisSALogLevelSpamAssassin 的日誌等級通常為 0 或 1。除非需要更深入的調試，否則建議從 Amavis 等級 2 開始，而不是使用最高詳細等級。

su - zimbra
zmprov mcf zimbraAmavisLogLevel 2
zmprov mcf zimbraAmavisSALogLevel 1

終端機顯示 Zimbra 指令，這些指令會暫時增加 Amavis 和 SpamAssassin 的日誌記錄。

標題：臨時日誌記錄變更使掃描時間和 SpamAssassin 行為更容易與 CPU 峰值關聯。

僅需重現或觀察問題足夠長的時間，以便收集有用資料。更高的日誌等級會增加磁碟寫入次數，並可能使繁忙的伺服器雜訊更大。調查結束後，請恢復到先前的設定；Zimbra 文件中將 SpamAssassin 的預設日誌等級設為 0，而 Amavis 的日誌等級通常較低。

zmprov mcf zimbraAmavisSALogLevel 0
zmprov mcf zimbraAmavisLogLevel 1

步驟 6：如果 SpamAssassin 處於緩慢階段，請驗證並更新其規則

如果日誌始終指向 SpamAssassin，請檢查問題是否是在規則變更、自訂規則部署或規則更新失敗後出現的。設計不良的正規表示式和有問題的規則可能會對某些郵件正文造成過大的開銷。

Zimbra 官方的 Amavis 故障排除資料中，ZCS 8.8 及更高版本捆綁的 SpamAssassin 更新指令記錄如下：

su - zimbra
/opt/zimbra/common/bin/sa-update -D

終端機顯示捆綁的 SpamAssassin sa-update 指令正在檢查和安裝規則

標題：當日誌或啟動錯誤指向過時或損壞的規則資料時，更新捆綁的 SpamAssassin 規則是合適的。

請勿將此方法sa-update視為通用的 CPU 使用率修復方案。如果 CPU 使用率飆升是在新增自訂規則後立即出現的，請先測試該規則。 Zimbra 將最新的自訂 SpamAssassin 規則儲存在 `<path>` 下/opt/zimbra/data/spamassassin/localrules/。在可控的維護視窗期內，僅移除或停用可疑的自訂規則，然後比較掃描時間和佇列行為。

Zimbra 官方 Wiki 也提到了新版 ZCS 的自動規則更新和編譯設定。在已建立的伺服器上啟用自動化功能之前，請務必查看Zimbra 反垃圾郵件原則。

步驟 7：只有在您清楚自己更改了哪些內容後，才能重新啟動 Amavis。

重新啟動可以清除卡住的工作進程並載入更新後的規則，但應該在診斷之後再進行，而不是取代現有進程。除非有證據表明問題出在更廣泛的 MTA 堆疊上，否則請先僅重啟 Amavis。

su - zimbra
zmamavisdctl restart

說明：重新啟動 Amavis 會在特定規則或設定變更後重新載入服務，而不會不必要地重新啟動所有 Zimbra 服務。

如果 CPU 使用率立即恢復到 100%，則表示問題仍然存在。傳回日誌，查看是否再次出現相同的訊息、掃描器或規則。反覆重啟服務可以暫時緩解症狀，同時允許隊列成長。

步驟 8：以三項獨立檢查驗證恢復狀況

不要因為 CPU 使用率下降就斷定問題已解決。必須同時驗證進程負載、佇列方向和服務運行狀況。

top -c
sudo /opt/zimbra/libexec/zmqstat
zmcontrol status

終端機顯示 amavisd CPU 使用率較低，郵件佇列幾乎為空，Zimbra 服務運作正常。

標題：當 CPU 使用率、佇列深度和 Zimbra 服務狀態同時改善時，復原能力會更強。

然後透過受影響的郵件傳輸代理程式 (MTA) 發送測試郵件，並確認其在正常延遲範圍內送達。對於應該通過過濾的郵件，請檢查其郵件頭中是否存在預期的 Zimbra/Amavis 垃圾郵件和病毒掃描欄位。 Zimbra 文件中記錄了啟用這些檢查時郵件頭的X-Virus-Scanned相應欄位。X-Spam-Status

如何決定下一步該怎麼做

你所觀察到的	下一步最佳行動	為什麼
一則訊息反覆導致長時間掃描。	安全地隔離或檢查該訊息，並將其佇列 ID 與日誌關聯起來。	瓶頸可能與內容有關，而非容量問題。
SpamAssassin 的時機掌握得非常出色	查看自訂規則、規則更新和偵錯輸出	規則集如果包含大量正規表示式或有缺陷，則會增加計分成本。
ClamAV錯誤或超時是主要問題。	檢查防毒軟體運作狀況並更新狀態	Amavis可能只是在等待它所呼叫的掃描器。
CPU 使用率高，但佇列長度接近零。	在做出顛覆性改變之前，要觀察更久。	如果吞吐量和延遲保持健康，高利用率是可以接受的。
即使進行了針對性修復，排隊人數仍然不斷增加。	升級至能力、訊息模式或支援等級分析	伺服器可能配置不足、遭受攻擊或遇到軟體特定缺陷。

應避免的首要應對措施

不要僅僅為了降低 CPU 使用率而永久停用反垃圾郵件或防毒掃描。 Zimbra 的確支援針對特定可信任/來源流量的繞過策略，但這會改變安全模型，因此應該作為一項經過深思熟慮的郵件策略決策，而不是一項通用的效能最佳化措施。 Zimbra 關於SpamAssassin 來源流量繞過的文件明確指出，該繞過與可信任的內部網路相關。

此外，切勿盲目增加 Amavis 工作進程數。雖然增加工作進程數可以提高並發性，但也會增加記憶體壓力，並可能加劇 CPU 爭用。適當的工作進程數取決於訊息類型、附件大小、掃描器行為、可用核心數、記憶體和 I/O 情況。測試時應關注佇列吞吐量和延遲，而不是想當然地認為更大的工作進程池速度更快。

此故障排除路徑的局限性

此流程旨在解決 Amavis 運作但持續佔用大量 CPU 資源的常見情況。它不能取代針對已確認的產品缺陷、伺服器被入侵、惡意訊息拒絕服務攻擊或具有外部掃描器的多節點架構等情況的 Zimbra 版本特定支援指南。

Zimbra 社群的技術資料記錄了一些歷史案例，在這些案例中，精心建構的郵件或 SpamAssassin 的行為可能導致 Amavis 工作進程長時間佔用大量 CPU 資源。由於具體受影響程度取決於已安裝的 Zimbra 和 SpamAssassin 版本，因此請勿盲目地應用舊的軟體包升級方案。首先，請使用 `zimbra version` 指令記錄您的 Zimbra 版本zmcontrol -v，將其與您支援的版本和修補程式等級進行比較，並遵循最新的供應商指南進行升級。