☰

後綴性能

tag-icon • tag-icon performance postfix performance-tuning
後綴性能

在 ubuntu 上運行 postfix，每天發送大量郵件（約 100 萬條訊息）。負載非常高，但 CPU 和記憶體負載並不多。有人遇到類似情況並知道如何消除瓶頸嗎？

該伺服器上的所有郵件都是出站的。

我不得不假設瓶頸是磁碟。

只是更新，iostat 如下圖所示：

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.12   99.88    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    12.38    0.00    2.48     0.00   118.81    48.00     0.00    0.00   0.00   0.00
sdb               1.49    22.28   72.28   42.57   629.70  1041.58    14.55   135.56  834.31   8.71 100.00

這些數字是否符合您對單一磁碟的預期效能？

sdb 專用於 postfix。

我認為這是隊列洗牌，從傳入->活動->延遲

問題的更多詳細資訊：

伺服器：四核心 Xeon(R) CPU E5405 @ 2.00GH，附 4 GB 內存

平均負載：464.88、489.11、483.91、4 核心。但記憶體利用率和CPU利用率極低

Postfix 實例在 16 - 32 之間

答案1

這可能聽起來有點瘋狂，但你應該：

  1. 將日誌記錄減少到您需要的最低限度。使 syslog 僅記錄 mail.err 或更高版本。
  2. 添加更多內存。是的，Postfix 不需要它，但是額外的 RAM 意味著核心需要額外的頁面快取。
  3. 您沒有提到 /dev/sdb 上的檔案系統（這也很重要），但肯定會將其切換到noatime，這應該至少會減少一點負載。
  4. 看看你的 /var/spool/postfix 有多大。如果它是在幾個演出下，請考慮將其移至虛擬磁碟。

答案2

我不同意那些建議使用 RAM 磁碟作為“/var/spool/postfix”的人。這意味著您的整個郵件佇列將儲存在 RAM 中。如果您的伺服器崩潰或斷電，佇列中的訊息將永遠消失。從客戶端/用戶的角度來看，這確實很糟糕，因為訊息已經被成功接受傳遞。更糟的是，您的伺服器不會發送通知，說明電子郵件已退回或無法送達，因為當伺服器恢復時佇列將為空。

相反，我會添加盡可能多的快速磁碟，您可以負擔得起；根據所提供的信息，我無法真正估計您需要多少。從上面的“iostat”輸出來看，您似乎正在對“sdb”執行約 120 IOPS（r/s 和 w/s 的總和）。您可以合理地估計單一 15k RPM SCSI 或 FC 磁碟將處理 150 IOPS。我會從 5 個 15k RPM SCSI 磁碟和一個不錯的 RAID 控制器開始。將其設定為跨 4 個磁碟機（帶 1 個熱備用）的 RAID-10。我不確定這是否能完全解決你的問題，但絕對不會讓問題變得更糟。

答案3

在某些分析器（gprof？）下執行 postfix，或檢視日誌。 Postfix 記錄了大量的計時訊息，這些訊息可能會告訴您阻塞在哪裡。常見的地方有：

  1. 磁碟效能。也許是時候對您的隊列進行 RAID-10 了。
  2. 訊息上的任何類型的網路 IO。 DNS 黑名單？薩維？
  3. 您安裝的過濾器和其他過濾器。
  4. 透過網路或進程（ldap、sql）進行身份驗證和 UID 查找。
  5. 不使用代理：對於慢速地圖（如上）

答案4

看起來您的磁碟子系統至少應該被視為問題的一部分。由於 postfix 在 /var 周圍整理文件的方式，我建議在谷歌上搜尋「tweak ext3 filesystem」（至少設定 noatime 和 writeback），看看是否無法提高檔案系統層級的效能。

我有兩個伺服器集群，它們對客戶發送的電子郵件執行雙重任務 DNS 和出站 SMTP，每天運行 250k 則訊息（2k-10k/小時），而與此類 I/O 綁定相差甚遠。

相關內容