Zimbra 開源遇到無法解釋的減速，只能通過重新啟動來解決
我們的 zimbra 伺服器每隔幾天就會出現無法解釋的減速，只有在重新啟動伺服器後才能解決。從最終使用者的角度來看，如果他們正在使用 webmail 並發送消息，那麼它最終會超時。從系統終端，登錄、切換使用者和重新啟動 zimbra 服務都會出現減速。使用“su -”更改使用者最多需要 2 分鐘
重新啟動所有 zimbra 服務、dns 服務並不能解決問題。該問題僅在完全重新啟動後才能解決。重新啟動後，登錄、切換使用者和重新啟動伺服器會很快發生。
由於 NAT，我們使用 dnsmasq 進行拆分 DNS，這是我們的環境所需要的。但是查詢 DNS 會立即返回結果。我們使用外部 ldap 數據庫進行身份驗證，但使用它的其他伺服器沒有顯示任何問題，也沒有負載問題。其他一切都是預設安裝和配置。
系統日誌中沒有明顯的錯誤。伺服器負載，磁碟 IO，有問題和沒有問題的時候是一樣的。
最初，這通常每週發生一次，通常在星期一或星期二。本週，它發生在周一和周四。
我的版本是：
zimbra@servername ~ $ zmcontrol -v Release 7.2.1_GA_2790.RHEL6_64_20120815212147 UNKNOWN_64 FOSS 版本。
有沒有人遇到或解決過這樣的問題？
我發現 rsyslog 在通過 TCP 將日誌轉發到遠端主機時，有時會在無法轉發到遠端主機時掛斷。即使遠端主機重新啟動，rsyslog 仍然掛起，因此會減慢系統上嘗試記錄的所有其他內容。重新啟動 rsyslog 可以解決問題，但是通過 cron 作業定期重新啟動它似乎對我不起作用。我找到的最好的解決方案是不要讓遠端主機停機這麼多。:)
但是，可以對 rsyslog 進行一些調整，使其排隊而不是鎖定。您可能仍然會遇到該問題，在這種情況下，在重新啟動 rsyslog 之前不會轉發任何日誌，但它不會影響整個系統。
註釋掉您目前的轉發規則，並將其放在 rsyslog.conf 的末尾：
$WorkDirectory /var/spool/rsyslog # where to place spool files $MainMsgQueueFileName mainqueue # unique name prefix for spool files $MainMsgQueueMaxDiskSpace 2g # 1gb space limit (use as much as possible) $MainMsgQueueSaveOnShutdown on # save messages to disk on shutdown $MainMsgQueueType LinkedList # run asynchronously $MainMsgResumeRetryCount -1 # infinite retries if host is down *.* @@1.2.3.4:514 # replace this with your own forwarding rule您需要確保 /var/spool/rsyslog 存在，否則它不會創建它。