Thank you for the answer.
--- Walter Wong <[EMAIL PROTECTED]> wrote:
> Helmut Apfelholz <[EMAIL PROTECTED]> writes:
> > this is greate that the development of the server
> is
> > moving along. I hope that you guys at cmu also
> watch
> > to mailing list, and have seen the 'forking
> problem' that
> > ppl here have been describing.
>
> Yes, we read the mailing lists but have been busy
> with some issues
> internally. In chatting briefly with Larry, we
> agreed that we both
> need to ponder the issue a little more and so we
> haven't responded
> (beyond throwing in a quick hack in this release).
>
> We saw some problems, though not as severe and
> perhaps the problem is
> most severe under Linux.
>
> Speaking of Linux, did you do the chattr +S to make
> the disk writes
> synchronous? If you are willing to lose data on a
> crash, you may want
> to see if performance improves by changing that. If
> you aren't willing
> to lose data on a crash, maybe you can see if
> resierfs performs
> better?
We started to run with asynchronous writes, the
performance is better, but the problem happens from
time to time. The reiserfs is out of the question at
the moment, since we don't consider it to be stable
fs.
> Do you have a set of test scripts that shows this
> behavior?
We've seen this on the production system.
I think that one might reproduce it using the Postal
package. http://www.coker.com.au/postal/
> Some other notes...
>
> a) you don't have to use duplicate delivery
> suppression if it appears
> that the locking overhead on that is getting in
> the way.
After turning of the duplicate delivery suppression,
the congestion is lower, but the 'fork problem'
happens
from time to time, so this is not a very good
solution.
> b) If you are primarily using POP some of the recent
> changes probably
> don't help since we only implemented the process
> reuse in imapd
> (and probably will do this in lmtpd eventually
> too)
> c) We got around some of our problems by running
> sendmail in queue
> only mode. In this manner, email comes in but
> gets dumped into a
> queue. A queue processor fires up, connects to a
> lmtpd and sends
> down a bunch of messages. This helps reduce the
> number of
> simultaneous lmtpds
Our server has no more than 4 concurrent lmtpd
processes running. We use lmtp unix sockets, to
receive mail. The software that injects the letters
does
connection cacheing, so it doesn't close the
connections to the lmtpd and pipes a lot of messages
at once. Having thought about this, I am not sure that
incoming 'lmtpd deamon reuse' hack will solve the
problem since our setup doesn't require forking lmtpd
deamons all the time and exhibits the problem we are
talking about.
I hope that my description will help to deduce the
nature of the problem.
Helmut.
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
