Postfix+ldap的性能测试及分析

lcmj44444444

Postfix+ldap的性能测试及分析

1.测试平台
PIII 933 × 2 + 512M + SCSI 18G
Postfix 2.0.0.1 + openldap 2.0.11(默认安装) + virtual 投递
2.使用HASH格式作为查询表（lookukp table）时,SMTP 注入速度大概都有5000多封信/分钟。最高能达到87.5封/s。
这个时候采用的方式为只测试信头,100个并发连接。将postfix的默认进程限制提升到500，即：default_process_limit = 500，这也加大了并发速度。其中对syslogd采用了异步写优化(在设置的目录前加-号) 也能大幅度提高速度。
mail.*              -/var/log/maillog
3.将用户信息保存在ldap里，SMTP注入速度基本都有2500-2800/分钟,再简化了lookup的方式，transport_maps采用固定文本的方式,只有virtual_mailbox_maps才用ldap，这样速度提高到3200-3500封/分钟左右。测试recipients地址固定为10个
4.在ldap里存放50万条用户记录。进行500,1000,2000地址的并发测试，结果发现SMTP注入速度和使用的用户地址多少关系不大，以下是2000地址的结果:
Postal result:
time,msg/m,KB,error,connection,SSL
10:26,3779,1516,2,1930,0
10:27,3889,1556,0,1953,0
10:28,3987,1592,0,1997,0
10:29,4174,1667,0,2067,0
10:30,4308,1720,0,2166,0
10:31,4039,1613,0,1986,0
10:32,2660,1061,0,1338,0
10:33,2436,972,0,1216,0
SMTP注入速度比较快，这里信件内容只包含了信头，采用50个并发连接，每个连接只发2-3封信。感觉效果还是不错的。不过10:32之后速度开始有点问题了，我检查了/var/spool/postfix目录，发现incoming的数量大幅提高，估计是cleanup不能那么快处理incoming的信件，使队列堆积起来；但也可能是ldap反应速度开始变慢。
小结：性能优化技巧·关闭ldap的log使之=0
·将maillog等需要频繁进行write/sync的日志设置为async write，方法见上文
·调整postfix的default_process_limit > 150
·调整/var/spool/postfix目录的属性为async，使用chattr命令
5. 50个并发2000地址，邮件只包含信头，每个连接3封信的结果：

11:17,3613,1447,0,1849,0
11:18,3876,1547,0,1930,0
11:19,4088,1634,0,2080,0
11:20,3920,1566,0,1977,0
11:21,4057,1621,0,2021,0
11:22,3946,1573,0,1960,0
11:23,3316,1324,0,1695,0
11:24,2576,1030,0,1295,0
11:25,2889,1155,0,1439,0
^^^^^^^^^^^^^^^^^^^^^^*
11:26,3984,1596,0,1990,0
11:27,3986,1588,0,1993,0
11:28,4164,1662,0,2064,0
11:29,3973,1591,0,1986,0
11:30,3991,1592,0,1982,0
11:31,3521,1406,0,1758,0
11:32,2590,1035,0,1297,0
^^^^^^^^^^^^^^^^^^^^^^*
11:33,2655,1058,0,1322,0
11:34,2745,1097,0,1348,0
注意^^*所标记的时间段，SMTP注入性能大幅度下降。检查/var/spool/postfix目录，发现qmgr已达到处理上限了，该上限由qmgr_message_active_limit 参数设置。故此incoming开始增长很多，Postfix开始放慢处理速度。
以上所有测试都是在default_destination_concurrency_limit = 10的条件下完成的，所以在virtual进行本地mailbox投递时，并发数很少，而active目录增长得很快，没有足够多的virtual进行投递，结果是无法快速地将邮件写到硬盘。
6.提升default_destination_concurrency_limit：
default_destination_concurrency_limit = 1000
此时出现另外一个问题：active队列大概只维持在200-300百封信的样子，但defer/defered目录开始有所增长，并且SMTP注入速度下降，大概只有1850封信/分钟的速度。此时virtual的并发数目达到了400个！
可以推断，这是因为virtual投递速度和数量大幅度增加，致使磁盘写(write)操作过于频繁，使磁盘I/O性能吃紧，导致性能下降。
解决办法：使用分布式存储，利用mailswitch这一类技术，将最终的邮件投递由存储机器上的软件完成。
将这个default_destination_concurrency_limit改成100，速度提升了一些，但很多出现了很多lookup failure：
time,messages,data(K),errors,connections,SSL connections
Server error:451 : Temporary lookup failure
.
Server error:451 : Temporary lookup failure
.
11:57,2773,1124,2,1459,0
11:58,2302,920,0,1156,0
11:59,2492,996,0,1264,0
12:00,2204,879,0,1087,0
Server error:451 : Temporary lookup failure
.
Server error:451 : Temporary lookup failure
.
12:01,2311,924,2,1146,0
Server error:451 : Temporary lookup failure
.
12:02,2487,993,1,1265,0
12:03,2284,912,0,1112,0
12:04,1515,602,81,808,0
              ^^ 81个错误
12:05,1969,787,11,1012,0
12:06,2139,858,0,1073,0
12:07,2174,868,0,1095,0
12:08,2214,884,0,1093,0
12:09,2252,900,0,1118,0
Server error:451 : Temporary lookup failure

Ezreal

为什么我做同样的测试  直接就重启 或者死机了.  是配置不够 资源 不够 导致的吗 ?