>>>>> On Sun, 11 Feb 2001 12:44:32 -0500,
>>>>> Andy Hubbell, <[EMAIL PROTECTED]> (ah) writes:
ah> Should the master process exec a new lmtpd for each delivery? This
ah> would seem somewhat wasteful, especially on a busy system with lots
ah> of disk IO... Nothing else is talking lmtp to this server so it
ah> should only be getting lmtp connections on the socket.
You'll probably want to tweak some settings further. Here are a few
things I've got going:
/etc/postfix/main.cf:
# Be careful here. Make sure your box has the resources to
# handle what ever you set this to!
lmtp_destination_recipient_limit = 3000
# Allow a service to be used this many times before recycling.
max_use = 200
/etc/postfix/master.cf:
# Setting max number of lmtp processes to 10.
lmtp unix - - n - 10 lmtp
Something Wietse points out is that you want to avoid the
destination host from switching too much. Here's from the
LMTP_README in snapshot-20010128:
You can prevent the LMTP client from switching between servers by
configuring a separate mail delivery transport for each LMTP server:
/etc/postfix/master.cf:
lmtp1 unix - - n - - lmtp
lmtp2 unix - - n - - lmtp
. . . . . . . .
Configure transport table entries such that the lmtp1 mail delivery
transport is used for all deliveries to the LMTP server #1, the
mail lmtp2 transport for the LMTP server #2, and so on.
/etc/postfix/transport:
foo.com lmtp1:lmtp1host
bar.com lmtp2:lmtp2host
Obviously, for UNIX domain sockets, just change the "lmtp1:lmtp1host"
to the appropriate thing, such as "lmtp1:unix:/path/name".
The reason why I set the lmtp service to a particular number is so
that I can throttle things back a bit. That way if the SMTP host
gets a flood of mail, it won't blast the Cyrus server so hard that
performance crumbles. Personally, it *seemed* like this also helped
connection caching by limiting the likelihood that another lmtp
connection would be kicked off, but I suspect Wietse's analysis is
more accurate. It's been working fine as is, so I didn't dig
further. Only so much time to play, alas.
--
Amos
