On 1/18/2012 4:46 AM, Konrad Rzepecki wrote: > I have similar problem, and I suspect you may also hit it. In my case I > send ~10k-20k mails through sendmail wrapper. My problem is caused by > fsync done on EVERY queued mail. It take on my servers (4 core AMD @ > ext4 @ LVM @ RAID10 @ 8disk) ~ 0.2-0.3s for each one. Sometimes it's > even 0.6s! So simple mail queuing for 15k recipients can take 1 hour or > more... > > > I don't know why it take some much time, but it cannot be disabled > (fsync) in postfix due to delivery guarantee. However, my mails (those > ones) are not very important, and lost some of them is not a problem, so > such option will be useful for me. Best in some > "recipient|sender_disable_fsync_maps" fashion.
fsync isn't your (only) problem if batch queuing 15K messages takes an hour+ with an 8 disk RAID10 w/4 spindles of IOPS throughput. Even at 7.2K RPM each disk should be able to fsync at least 50 small (4KB-16KB) msgs/sec, unless they are something huge like 1MB newsletters with attachments or some such. 50*4*3600 = 720,000 msgs/hour Likewise, at 200 msgs/sec fsync'd: 15,000/200 = 75 seconds You've got some other problem(s). The EXT4 filesystem backing the queue may be heavily fragmented. The RAID controller BBWC may not be properly configured to ack fsync before data actually hits the disks. You may have something (mis)configured in Postfix slowing down the queue. Moving the queue to XFS with proper stripe alignment would probably help considerably, though it's not going to give you the 30 fold improvement that the bare hardware should be capable of. So there's still something else going on somewhere. -- Stan
