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?
Do you have a set of test scripts that shows this behavior?
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.
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
Walter
