后缀性能

在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专用于后缀。

我认为这是队列改组，来自传入->活动->递延

有关问题的更多详细信息：

服务器：四核Xeon（R）CPU E5405 @ 2.00GH，具有4 GB内存

平均负载：464.88、489.11、483.91、4核。但是内存利用率和cpu最小

16-32之间的Postfix实例

这听起来可能有点疯狂，但是您应该：

1. 将日志记录减少到所需的最低限度。使syslog仅记录mail.err或更高版本。
2. 添加更多的RAM。是的，Postfix不需要它，但是额外的RAM意味着内核需要额外的页面缓存。
3. 您没有提到/ dev / sdb上有什么文件系统（这也很重要），但是肯定将其切换到noatime，这至少可以减少一点负载。
4. 查看您的/ var / spool / postfix有多大。如果它在几场演出以下，请考虑将其移至虚拟磁盘。

我必须不同意那些建议将RAM磁盘用于“ / var / spool / postfix”的建议。这意味着您的整个邮件队列将存储在RAM中。如果服务器崩溃或断电，队列中的消息将永远消失。从客户端/用户的角度来看，这确实很糟糕，因为已经成功接受了邮件的传递。更糟糕的是，您的服务器将不会发送通知，指出电子邮件被退回或无法发送，因为服务器恢复时队列将为空。

取而代之的是，我将添加尽可能多的快速磁盘。根据所提供的信息，我无法真正估算出您需要多少。从上面的“ iostat”输出中，您似乎对“ sdb”（r / s和w / s之和）进行了约120 IOPS的操作。您可以合理地估计单个15k RPM SCSI或FC磁盘将处理150 IOPS。我将从5个15k RPM SCSI磁盘和一个不错的RAID控制器开始。将其设置为具有1个热备用的4个驱动器上的RAID-10。我不确定这是否可以完全解决您的问题，但绝对不会使情况变得更糟。

在某些探查器（gprof？）下运行postfix，或在日志中查找。Postfix记录了许多时序信息，这些信息可能会告诉您保持状态。常见的地方有：

1. 磁盘性能。可能需要等待RAID-10进入队列。
2. 消息上的任何类型的网络IO。DNS黑名单？SAV？
3. 您已安装的微调器和其他过滤器。
4. 身份验证和UID查找是通过网络或进程（ldap，sql）完成的。
5. 不使用代理：用于慢速地图（如上述）

假设吞吐量恒定，则每天一百万条消息大约为每秒11条消息。Postfix本身应至少能够比入门级服务器硬件处理至少一个数量级。因此，我怀疑您不仅有运行postfix的功能，还是分布非常不均匀的吞吐量峰值。

您的情况肯定看起来像是一个受I / O约束的服务器。这是MTA所期望的，它需要进行大量小写操作以确保它不会丢失邮件。

花一些时间来调整I / O上都/var/spool/postfix和/var/log。繁忙的postfix服务器的最佳实践是将两个主轴分开，并确保启用了异步日志记录。在Linux上，邮件日志的日志文件名前带有短划线。

mail.info                              -/var/log/mail.log

或类似。

如果您使用的是amavisd-new，请确保其工作区在tmpfs文件系统上。我们通常穿上它/tmp/vscan/。这是安全的，因为在下游（后过滤器）跃点接受消息之前，amavisd-new不会返回数据结束响应。

有人建议noatime为后缀假脱机安装选项。由于后缀依赖文件系统语义的方式，这可能是不明智的。参见例如http://archives.neohapsis.com/archives/postfix/2006-01/1916.html。

显然，您的磁盘子系统至少应该被视为问题的一部分。由于后缀在/ var周围重新整理文件的方式，我建议使用谷歌搜索“调整ext3文件系统”（至少设置noatime和writeback）以查看是否无法提高文件系统级别的性能。

我有两个服务器群集，它们对客户发送的电子邮件具有双重作用的DNS和出站SMTP，并每天运行25万条消息（2k-10k /小时），而I / O绑定几乎没有。

对我来说，存储性能似乎是瓶颈。

iowait 99.88告诉您系统正在花费大量时间等待存储。

我同意比尔·韦斯的观点。您应该查看队列的raid10设置。

或开始于

vmstat 1

moshen建议的“ iostat 1”也很好

从统计数据来看，显然更快的磁盘子系统会更好。在6-8个15k rpm磁盘上的raid-10可能带有一些缓存，板载内存为数演出。

使用noatime，nodiratime选项安装假脱机目录。考虑调整或更改文件系统以处理大量小文件（我认为）。

布赖恩

您确实需要更快的磁盘，或者最好是使用RAID解决方案。这是哪种服务器？

詹姆士

如果您正在运行用于垃圾邮件+病毒过滤的amavis，则应增加并发amavis进程的数量。根据您的设置，您可能需要增加postfix master.cf中smtp-amavis进程的数量，以及amavis.conf中的相关设置。

包装盒中有多少个核心，实际负载是多少？您收到邮件的实际速率是多少？

像大多数人一样，我首先想到的是磁盘，因此请检查一下。

但是，网络利用率可能是高中断负载（卡不良）的原因，因此请进行检查。我发现即使对于普通的邮件服务器，在同一机器上具有快速缓存的DNS服务器（我偏爱“未绑定”）也有助于减轻延迟和网络负载。

每秒要进行630次读取和1042次写入，我绝对建议您增加系统中的内存（以更好地处理OS和ram驱动器），然后将postfix文件夹设置为ramdisk。

如果不完全将磁盘放在自己的磁盘上，也建议将邮件日志放在其自己的分区上。

这不是IO问题，而是后缀配置问题。您要它一次完成太多工作，并为您自己创建一个瓶颈。查看postfix性能调整自述文件和/或发布您的main.cf，以便我们提供帮助。

看起来您有一块躲闪的磁盘。您的服务器仅执行72次读取请求/秒和42次写入/秒。我的Seagate 7200 RPM台式机硬盘每秒可以执行100多个随机读/写请求，并且仍然可以应付。

尝试将线轴安装在sda上，看看负载是否有所改善。

但是在将更多的钱花在磁盘上之前，请执行以下操作：

1. 运行qshape active，qshape deferred和qshape呼入，让我们知道每个命令的总数。

   延迟队列中的邮件数量异常多，这意味着垃圾邮件发送者可能会使用您的邮件服务器来转发其垃圾邮件（例如，将电子邮件发送到不存在的域，这将导致您的postfix一次又一次地重试）。

2. 确保您的邮件服务器未列入黑名单（http://www.mxtoolbox.com/blacklists.aspx）

3. 检查DNS响应时间并运行本地DNS缓存。

   邮件服务器大量使用DNS。请 dig somedomain.com mx 在几个不同的主机上运行它。通常，响应时间应小于100-400ms。如果您获得更高的响应，则您的DNS可能无法正常运行。尝试使用其他DNS（您可以尝试使用Google的8.8.8.8或OpenDNS：208.67.222.222）

4. 检查您的网络。（例如ifconfig），并查看有多少个错误数据包。检查链接是否饱和或变形。检查邮件日志上是否有大量的超时操作。请执行tcpdump并确保数据包不会丢失或重新传输。

5. 您能告诉我们控制台是否响应（例如，当您键入某些命令时，系统将如何快速反馈给您）？

   通常，网络问题（例如DNS）将导致负载激增，但系统仍会响应。