Slow lmtpd

[Andre Nathan]

On Fri, 2007-03-02 at 12:59 -0800, Andrew Morgan wrote:
> You'll lose the ability to effectively use vacation/out-of-office 
> messages.  The vacation system uses deliver.db to determine which person 
> has already received the vacation message, to prevent multiple messages 
> from being sent.

But does vacation depend on the duplicate_{check,mark} calls from lmtpd?
I didn't read the sieve code, but imap/lmtp_sieve.c also calls those
functions.

> From the earlier discussion on this topic, it sounds to me like you are 
> simply pushing your available hardware too hard without further tuning. 
> You mentioned using ATA-over-Ethernet storage for your mail spool.  Have 
> you considered putting your configdirectory files on a local hard drive 
> instead of on the ATA-over-Ethernet storage?  There is a *lot* of 
> contention for the files in the config directory, so maybe it would be 
> better to move them onto a drive separate from the mail spool.

The machine actually doesn't have any local disks (it's booted via pxe
and the root partition is also on AoE). The directories /var/spool/imap
and /var/lib/imap are each on its own LVM logical volume.

I mounted /var/lib/imap/proc as a memory-based filesystem (using tmpfs),
because of the contant writes to this directory, and yesterday I tried
moving deliver.db to that directory, and creating a symlink, but it
didn't improve the situation a lot.

> After running iostat on my cyrus partition (both config and mail spool are 
> kept on a SAN), I'm wondering if I should separate them out as well.  This 
> sounds related to the new metapartition and metapartition_files options 
> that were added in v2.3.x.
> 
> Does anyone have any recommendations or guidance on this topic?

Yes, people, please share :)


Thanks for the suggestions,
Andre