| 導購 | 订阅 | 在线投稿
分享
 
 
 

qmail與Postfix的性能對比測試

來源:互聯網  2008-05-31 00:03:30  評論

一直以來,人們普遍的觀點都認爲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,這樣的效能低。確實也是。因爲如果是連續的有規律的寫,速度會塊得多的。。

一直以來,人們普遍的觀點都認爲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,這樣的效能低。確實也是。因爲如果是連續的有規律的寫,速度會塊得多的。。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
王朝網路微信公眾號
微信掃碼關註本站公眾號 wangchaonetcn
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有