使用 ClamAV 或 FreshClam 修復 Zimbra CPU 使用率過高的問題

當 Zimbra 伺服器突然變慢時，管理員通常會在進程日誌頂部看到「ClamAV」clamd或「ClamAV」字樣，並誤以為是防毒服務卡住了。這種情況確實會發生，但這兩個進程執行的任務不同：前者負責下載和驗證病毒庫更新，後者負責掃描檔案和郵件。繁忙的郵件佇列、資料庫重新載入、更新循環失敗或第二個防毒守護程序都可能導致「ClamAV 佔用過多 CPU」的顯示效果。在重啟任何服務或變更防毒設定之前，請先確定哪個程序佔用過多 CPU 資源。freshclamtopfreshclamclamd

本指南從低風險檢查逐步講解到服務恢復。以下命令和路徑適用於常見的 Zimbra 安裝；捆綁的 ClamAV 的具體路徑和支援的恢復步驟會因 Zimbra Collaboration 版本而異。在進行任何更改之前，請務必根據您已安裝的版本進行確認。

1. 確認哪個 ClamAV 進程正在佔用 CPU

首先記錄進程名稱、CPU 使用率、運行時間和命令路徑。以 root 使用者身分或使用有權檢查系統進程的帳戶執行此命令：

ps -eo pid,pcpu,pmem,etime,args | grep -E 'clamd|freshclam'

然後使用 `--run` 指令觀察可疑進程至少一小段時間top -p PID，並將 `--run` 替換PID為第一個指令中的數字。單次讀取不足以診斷持續存在的問題：` ps--run` 報告的是快照，而 ` top--run` 可以幫助您查看掃描或更新完成後 CPU 使用率是否仍然很高或下降。另請注意該路徑屬於 Zimbra（通常位於 `/usr/local/bin` 下）/opt/zimbra，還是屬於單獨的作業系統軟體包。

如果freshclam進程在成功更新後短暫出現峰值並退出或恢復空閒狀態，這與持續繁忙的進程不同。如果進程clamd是持續消耗資源的進程，則郵件掃描或資料庫載入更有可能是峰值出現的原因。不要因為某個樣本值較高就終止任何進程；先檢查日誌以及郵件是否仍在正常傳輸。

2. 更改設定前，請先閱讀防毒日誌。

Zimbra 的日誌參考手冊列出了其日誌目錄下的防毒日誌。在許多安裝環境中，可以使用以下命令查看最近的日誌條目：

tail -n 80 /opt/zimbra/log/clamd.log
tail -n 80 /opt/zimbra/log/freshclam.log

查看 CPU 使用率峰值旁的時間戳記。在 CPUclamd.log使用率峰值較高的情況下，重複的掃描請求或資料庫載入訊息可能與郵件活動或簽章重新載入有關。在 CPU 使用率較低的情況下freshclam.log，一次更新完成後的一段平靜期表示正在進行例行更新工作；而重複的連線失敗、重試、校驗和錯誤或始終無法完成的更新則需要進一步調查。同時，也應檢查同一時間段內的 Zimbra 郵件日誌，因為傳入郵件或附件流量的激增可能會導致掃描次數增加。

請使用 Zimbra 的日誌檔案參考文件來確認您目前版本的日誌位置。 ClamAV 的FreshClam 故障排除指南解釋了常見的更新程式錯誤，包括 DNS、下載和速率限制問題。引擎版本低於 ClamAV 最新上游版本的警告本身並不能證明資料庫已損壞；Zimbra 會將經過測試的引擎與 ZCS 版本一起打包。

3. 檢查是否有重複的更新程式、磁碟空間不足或工作負載激增

在進行任何調整之前，請先排除可能導致服務繁忙的常見原因：

• 重複進程：檢查是否存在多個clamdClamAVfreshclam進程。單獨安裝的作業系統級 ClamAV 服務或自訂定時任務可能會在 Zimbra 託管服務之外啟動第二個副本。在確認哪個產品擁有該服務以及由哪個產品啟動該服務之前，請勿停用該服務。
• 磁碟壓力：使用 `dksplit` 和 `dksplit` 檢查可用空間和 inode 數量df -h /opt/zimbra。df -i /opt/zimbra檔案系統已滿會阻止臨時更新或日誌寫入，並導致重試。請勿手動刪除簽名檔案來釋放空間。
• 郵件量：clamd將 CPU 使用率高峰與收到的郵件數量、附件大小、排隊郵件以及最近的大量郵件發送進行比較。即使服務運作正常，掃描量激增也可能導致 CPU 使用率上升。
• 更新連線：如果freshclam持續失敗，請檢查主機的 DNS 解析、時鐘、出站連線以及任何必要的代理設定。請修復底層網路或代理問題，而不是重複啟動手動更新作業。

ClamAV 在其設定手冊中詳細說明了 FreshClam 的配置如何控制更新行為和記錄。 Zimbra 也提供了病毒定義更新頻率屬性的說明，但其值和配置應根據您自己的 ZCS 版本進行檢查。不要為了快速降低 CPU 佔用率而降低更新頻率：過時的病毒庫會削弱防護能力，而錯誤的 DNS 或代理路徑無論更新頻率如何都會持續失效。

4. 採用與證據相符且幹擾最小的補救措施。

如果蛤蜊在郵件爆裂期間正忙的話

在監控 CPU 使用率和郵件收發情況的同時，讓目前運作正常進行。如果同樣的模式反覆出現，請將其與郵件大小、壓縮附件和入站郵件量關聯起來，然後檢查伺服器容量和貴組織的附件掃描策略。切勿在未評估安全影響並檢查 Zimbra 已安裝版本支援哪些控制措施的情況下，新增未記錄的 ClamAV 限製或排除檔案類型。

如果鮮蛤蜊反覆失敗

修復日誌中指示的 DNS、代理、防火牆、時鐘或出站網路存取問題。確保僅執行 Zimbra 的預期更新程式。請勿經常手動呼叫更新程式或使用臨時腳本下載簽名資料庫；ClamAV 已將 FreshClam 或 cvdupdate 識別為受支援的更新方法，並且 Zimbra 的軟體包整合應始終是 Zimbra 伺服器的唯一權威來源。

如果資料庫發生損壞或 clamd 無法啟動

資料庫格式錯誤、校驗和失敗或資料庫載入失敗等錯誤需要版本感知復原。 Zimbra 的ClamAV 定義重置流程針對不同的 ZCS 版本（包括不同的 FreshClam 二進位檔案路徑）有不同的說明。在移動或重建任何資料庫檔案之前，請務必閱讀與您正在執行的版本完全匹配的完整流程。在確認復原成功之前，請保留現有資料庫的副本，切勿盲目地套用舊版本指南中的指令。

請勿將 Zimbra 的 ClamAV 二進位檔案替換為獨立的上游建置版本作為首選效能修復方案。 Zimbra 文件警告稱，非週期性引擎變更可能不受支援；如果捆綁的引擎本身需要更新，請使用相應的 ZCS 修補程式或升級路徑。

僅在檢查原因後才重啟防毒軟體服務。

如果根本問題解決後服務仍然卡住，可以嘗試重新啟動防毒軟體，這或許可以清除過期的進程或重新載入已修復的資料庫。請安排在可以接受短暫中斷掃描的時間進行重啟，並按照適用於您 ZCS 版本的命令順序執行操作。 Zimbra 的操作流程文件中提供了相關說明，zmantivirusctl stop請zmantivirusctl start以以下使用者身分執行zimbra：

su - zimbra
zmantivirusctl stop
zmantivirusctl start
zmcontrol status

除非您的維護計劃要求，否則請勿對僅與 ClamAV 相關的問題使用完整重新啟動zmcontrol stop。如果防毒服務無法恢復運行，請保留相關日誌，並使用 Zimbra 特定版本的故障排除或支援管道，而不是重複重新啟動。

5. 確認 CPU 使用率和郵件掃描已恢復正常

修正或重新啟動後，重複進程檢查並觀察 CPU 使用趨勢，而不是僅依賴一個瞬時值。確認進程clamd存在，freshclam未陷入反覆重試，並且zmcontrol status報告防毒軟體正在運行。檢查新的日誌條目，確認資料庫載入成功，且不存在重複的更新或掃描錯誤。最後，驗證正常的測試郵件是否能夠依照貴組織的郵件安全策略進行投遞和處理。

一次成功的恢復有三個可觀察的跡象：負責的進程在完成工作後不再持續佔用 CPU；日誌不再重複出現相同的錯誤；Zimbra 的郵件流和防毒服務狀態保持正常。如果 CPU 使用率仍然很高，請收集帶有時間戳記的進程快照、匹配的clamd.log郵件freshclam.log日誌條目、磁碟空間使用情況以及您的 ZCS 版本。這些證據有助於區分真正的掃描程式缺陷、郵件量過大或更新路徑中斷等問題，同時也能排除惡意軟體掃描只是猜測的可能性。

版本說明：指南已於 2026 年 10 月 6 日核實。 Zimbra 技術中心包含目前參考資料和較舊的、特定版本的故障排除頁面；請根據您已安裝的 ZCS 版本的文件驗證命令和路徑。