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 < /etc/passwd > /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, 2003

D. 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&hl=zh-CN&lr=&ie=UTF-8&inlang=zh-CN&selm=9t130n%2412ha%241%40FreeBSD.csie.NCTU.edu.tw&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，这样的效能低。确实也是。因为如果是连续的有规律的写，速度会块得多的。。