qmail與Postfix的性能對比測試

一直以來,人們普遍的觀點都認爲qmail很快,比sendmail快得多,甚至有人還吹噓說qmail比postfix也快,爲了來一個客觀一點的評價,對qmail/Postfix進行測試看來是必要的了,至少可以給郵件系統的選擇提供一個評價的基准。

在測試postfix同樣配置的另外一個機器上裝了由hleil提供的rpm包,並咨詢了一下他關于qmail的問題,在此表示感謝。

1.環境

2台配置完全一致的PIII 933*2 + 512M + U160 SCSI 磁盤,qmail-1.03-7。另外系統做了優化,調整了fs.file-max=65535並放開一般限制,將/var目錄單獨分開。

先使用smtp-sink測試qmail,使用系統帳號,效果是26封/秒,覺得效果不理想。

hleil表示,我做的smtp 測試只測試了smtpd的性能而已,隊列並沒受到真正考驗,因爲smtp的速度才是bottleneck。

2.簡單結果:

用系統帳號,smtp-sink 配置成發1000封信,10個並發,耗費了56秒。換成100並發,測試失敗,加大了qmail的並發數後完成順利,結果也大概是26封/秒。

然後用postal軟件,50個並發連接,每個連接發一封信,qmail配置到400個並發上限。結果就大概是1150-1200封/分鍾的樣子,怎麽提高都不行了。看了一下top,發現kjounald頻繁的出現,估計是寫操作耗費了很多資源,並根據postfix測試結果推斷可能是multilog耗費了很多資源的原因。于是去掉multilog記錄的功能,qmail不使用log系統,再測試:

[root@ns2 postal-0.61]# ./do.sh

time,messages,data(K),errors,connections,SSL connections

14:52,2029,2767,0,2078,0

14:53,2056,2684,0,2056,0

14:54,2061,2785,0,2062,0

14:55,2022,2686,0,2021,0

14:56,1998,2684,0,1998,0

14:57,2006,2666,0,2007,0

14:58,1971,2644,0,1971,0

14:59,1971,2584,0,1970,0

15:00,1942,2596,0,1943,0

15:01,1984,2655,0,1984,0

15:02,1957,2567,0,1957,0

很明顯速度提升1倍左右,但部分測試出現could not creat qq(隊列)的問題,看不出具體的原因。估計是qmail沒足夠資源去創建隊列,或者速度太快隊列出了問題?

然後再將/etc/passwd的信息轉換成cdb提高查詢速度:

qmail-pw2u /var/qmail/users/assign

qmail-newu

然後再測試,結果如下:

[root@ns2 postal-0.61]# ./do.sh

time,messages,data(K),errors,connections,SSL connections

16:42,2118,2858,0,2167,0

16:43,2095,2788,0,2096,0

16:44,2114,2790,0,2114,0

16:45,2245,3002,0,2244,0

16:46,2233,2971,0,2233,0

16:47,2165,2891,0,2166,0

16:48,1977,2637,0,1976,0

16:49,1999,2645,0,2000,0

注入速度似乎提高了5%-10%。

hleil對上述測試結果認爲:這個測試是測試smtp的注入,並沒辦法真正考驗隊列,如上所發現的那樣,隊列應該沒有受到特別的考驗,即便是fail to create queue也可能是其他原因。必須是mx-mx真實環境下才有意義,而且一個smtp過程比現在的複雜。

注意:原文我記得不是太清晰,只是轉述hleil說的內容。

當時我認爲這樣的測試起碼還是有點效果的,首先就是測試了郵件dos情況。如果出現dos的時候,不管mta用何方法,只要支持住就可以了。如果qmail真的如我測試這樣容易出現隊列crash的話,是比較危險的。

但似乎這個問題不是那麽嚴重,有那麽多qmail用戶,如果真的那麽多DOS攻擊,那麽多qmail出問題,一定有解決辦法的。

其次就是log的問題,去掉log後速度提高很多,可以說明必須將log的開銷盡量降低,但一個産品系統必須有log。這個是必須解決的問題。

另外,由于qmail的隊列設計,每封處理的郵件至少要在隊列中建立3個文件,因此write的i/o操作頻繁很多(top的時候就看到kjounald占用的cpu資源明顯高于postfix的測試環境),可能會造成一定bottleneck(尤其是log不是async寫的時候更明顯,通過簡單的調整爲非同步寫的話就能提高很多速度,至少注入快了很多)

從2003年這個測試結果說明了如下的問題:

1.這個結果比較的只是smtp注入速度

2.這個結果主要是體現了若幹MTA的I/O消耗及高流量下的並發處理能力

3.從結果可推斷,postfix的fsync()操作最少,而qmail的fsync()較多,從體系結構及設計來說,qmail需要的是一個能立刻將數據同步(sync)到磁盤的文件系統,如果是使用了softupdates或async則在系統崩潰或掉電時,造成丟信。

也就是說,在bottleneck上,同樣的文件系統及磁盤子系統,postfix使用更少資源,如果cpu足夠快,能夠忽略處理隊列耗費cpu的時間的話,那麽postfix的隊列應該比qmail快而穩定。

最後,測試過程中qmail的隊列出現過crash,而postfix從未發生過。

參考資料:

一個專門做測試的網站

Serverwatch

Postfix vs qmail

Posted by hzqbbc at 08:22 AM | Comments (1)

January 18, 2003D. J. Bernstein 和Wietse Venema有關qmail的爭論兩人高手過招,一個mta所需要做的工作不多,也不至于什麽都幹吧??限制smtp log大小是log的事.我覺得。當然,反過來看,mta如果能自己限制,也不錯。類似qmail的配套工具一樣。

以下是wietse的郵件,關于djb的寫的slander回應.

http://groups.google.com/groups?q=artificial+limit+postfix+log+group:mailing.postfix.users%26amp;hl=zh-CN%26amp;lr=%26amp;ie=UTF-8%26amp;inlang=zh-CN%26amp;selm=9t130n%2412ha%241%40FreeBSD.csie.NCTU.edu.tw%26amp;rnum=1

DJB對venema的說法

http://cr.yp.to/qmail/venema.html

另外一個maillist上的郵件,包含了一個簡單的patch

http://lists.q-linux.com/pipermail/plug-misc/2001-November/000963.html

Posted by hzqbbc at 07:18 PM | Comments (0)

在足夠好的硬件條件下Postfix比qmail更快的原因分析經過實際的測試我也發現Postfix比qmail快(在較平等的條件下比較)。究其原因,主要是因爲磁盤I/O 的差異,Postfix的磁盤I/O原則上比qmail少耗用資源,僅1/3左右,所以速度原則上應該快3倍。

以下是wietse的解釋。

以下是postfix作者的原話,就偶自己的小知識,對硬盤寫操作越多性能越低。it's true..

===================================================================

寄件者:Wietse Venema (wietse@porcupine.org)

主旨:Re: performance tuning

View this article only

新聞群組:mailing.postfix.users

日期:2001-02-15 17:34:07 PST

jet:

I'm trying to dump e-mails into postfix via smtp, but can only achieve

speeds of about 15-20 mails/second (locally).

I've tried spawning multiple outgoing-mail scripts, and tweaked with them,

but always end up in the 15-20 mail/second range.

This is pretty much single disk Postfix performance. Most other

mailers are much, much, worse than this.

The bottle neck is your disk.

When I first tested Postfix against qmail, Postfix was 3x faster

on local and LAN benchmarks because Postfix uses one queue file

where qmail uses three. The create/delete operations are much,

much, more time consuming than reading and writing the content.

In order to make Postfix fast you need to avoid queue file

create/delete operations. Multiple recipients per queue file are

a big win. With one recipient per queue file Postfix is starved

because the disk is too slow.

Postfix does mostly random writes, and it actually has to wait

until a file is safe on disk. It's not allowed to wait until dirty

blocks are synced automatically.

In order to process more mails per unit time, you need faster disks.

Well, that is not possible.

You can, however, spread the load over multiple spindles. Don't

use RAID5 because it still has single-disk performance for applications

that produce random writes like Postfix does.

Another possibility is to use non-volatile RAM of the type that

used to be sold for SUN file servers. It speeds up disk access of

random writes by an order of magnitude, because writes can be sorted

for speed without loss of reliability. Next to solid-state disks

it is the best thing you can do.

Wietse

--

My test machine is a:

AMD Athlon Thunderbird 800 mHz

128 megs memory

not enough memory for sending 50K msgs/hour. You'll need 512 or more

to get 400+ SMTP processes into memory.

You will also have to increase maxfiles and maxfilesperprocess with sysctl.

I have a client with a listar announcement list machine hitting 40

msgs/hour on a P500 + 512 megs RAM and just one IDE disk. I think 50

is reachable, but 40 is more than enough for him.

UDMA66 IDE drive

Better to have two IDE master drives on two separate IDE channels,

one for system + logging and the other for mailq, and maybe even a

third for mailbox storage, but that means master/slave disk on IDE

which is slower.

Of course, IDE is slower than SCSI, and SCSI cards with 64 or 128

megs on-board buffer would help the disk channel congestion, which

Wietse says is the limit to an MTA.

好象wietse說不要用raid5哦。。因爲也是random write,這樣的效能低。確實也是。因爲如果是連續的有規律的寫,速度會塊得多的。。

升還是不升 Android2.2與2.3性能測試對比
升還是不升 Android2.2與2.3性能測試對比
Android是目前最火的手機系統,自從去年年底最新的Android2.3版系統和首款搭載該系統的谷歌手機Nexus S發布,其它Android智能手機用戶就在等待自己的手機能盡快更新到最新版本。HTC和谷歌一直有著很好的合作關系,用...查看完整版>>升還是不升 Android2.2與2.3性能測試對比
 
四通道坑爹?多通道內存性能對比測試
四通道坑爹?多通道內存性能對比測試
第1頁:讓帶寬飛起來 海盜船四通道內存Intel LGA2011平台的發布讓PC性能更上一層樓,爲了配合它,新的四通道內存紛紛發布。海盜船、金士頓、芝奇三家被Intel點名的內存廠商近日均發布了各自最新的四通道套裝,均針對...查看完整版>>四通道坑爹?多通道內存性能對比測試
 
世紀互聯完成至強5500性能對比測試
  近日,國內首家商用雲計算服務CloudEx提供商——世紀互聯宣布完成測試英特爾至強 5500系列處理器與前一代至強5400系列處理器的物理機與虛擬機性能對比。此次測試于6月中旬開始,旨在改進硬件設施和技術,不斷完善...查看完整版>>世紀互聯完成至強5500性能對比測試
 
Mysql 在windows 2000和 hp-ux上性能 對比測試
小型機HP 9000/800 # uname -aHP-UX uxserver B.11.11 U 9000/800 552756577 unlimited-user license# ioscan -C diskH/W Path Class Description==========================================...查看完整版>>Mysql 在windows 2000和 hp-ux上性能 對比測試
 
qmail sendmail postfix 三種MTA的分析比較
關于sendmail/qmail/postfix孰優孰劣,以及部署郵件系統的時候該選哪一個的討論已經重複了千百次了。但事實往往並不是A好B壞,或B好A壞,必須根據場合和應用的要求來定。但雖然如此,大多數人還是需要一個相對公平的...查看完整版>>qmail sendmail postfix 三種MTA的分析比較
 
隱藏SMTP旗標(Sendmail/Qmail/Postfix/Exim)
隱藏旗標(軟件名和版本號)將提高安全性,可能的情況下,也請使用Sendmail以外的其他郵件服務器,因爲Sendmail以root運行,比較容易使黑客提升爲root。 Sendmail 尋找sendmail的配置文件並編輯: Code: locate send...查看完整版>>隱藏SMTP旗標(Sendmail/Qmail/Postfix/Exim)
 
[原創] qmail sendmail postfix 三種MTA的分析比較
原文:http://www.hzqbbc.com/blog/arch/2005/06/qmail_sendmail.html [quote:6a4e3c124f] 關于sendmail/qmail/postfix孰優孰劣,以及部署郵件系統的時候該選哪一個的討論已經重複了千百次了。但事實往往並不是A好B壞...查看完整版>>[原創] qmail sendmail postfix 三種MTA的分析比較
 
性能提升幾何 GT335M對比測試GT240M
性能提升幾何 GT335M對比測試GT240M
第1頁:導語,顯卡參數對比· 導語從09年上半年的GT 130M到下半年的GT 240M,再到目前最新的GT 335M,這幾款顯卡依次接過前輩的衣缽,成爲中高端獨顯本的常見配置。在參數方面,它們最明顯的變化是流處理器,比如GT ...查看完整版>>性能提升幾何 GT335M對比測試GT240M
 
微軟Windows 7、蘋果雪豹系統性能對比測試
微軟Windows 7、蘋果雪豹系統性能對比測試
Windows 7本月22日就要正式發布了,除了自家的一系列操作系統,對Windows 7市場占有率能産生威脅的還包括蘋果的Mac OS X Snow Leopard(雪豹)系統,所以在Win7正式亮相前後,我們將看到一系列的對比測試。CNet網站近...查看完整版>>微軟Windows 7、蘋果雪豹系統性能對比測試
 
 
回到王朝網路首頁