I did try and had to switch it back to queue. Maybe my system is short of
resources at some point, however it has 1Gig of RAM and two 550Mhz
processors. Before it was not spawning new processes in case there was
plenty of alive lmpds even if I had free memory/cpu. Now it was spawning
well till it ran out of mem and out of swap. Then my box almost died, had to
restart sendmail and kill all connections to localhost. It is obvious that
it started to work much better and faster, since spawned lmtpds actually DO
work, but again, lmtpd is slower than sendmail and that causes problems.
Nick
-----Original Message-----
From: Helmut Apfelholz [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 02, 2001 19:37
To: Nick Ustinov; info-cyrus
Subject: RE: forking problem and SleepyCat
Could you please try turning off the DeliveryMode=q
in sendmail for some time, so we could see if the diff
has really helped ?
Thanks.
H.
--- Nick Ustinov <[EMAIL PROTECTED]> wrote:
> I've recompiled 2.0.12 with the latest changes in
> cyrus_db3. It works much
> better now, no problems so far. Before when there
> was 60-70 lmtpds master
> was not forking new processes. I've seen a situation
> with 150 lmtpds +
> imapds + pop3ds today and it worked very well and
> was able to manage all
> processes. However, I still have DeliveryMode=q in
> my sendmail.
>
>
>
> Nick Ustinov
>
> [EMAIL PROTECTED]
> http://www.videinfra.com
>
>
> -----Original Message-----
> From: Spark [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2001 2:01 PM
> To: info-cyrus
> Subject: Re: forking problem and SleepyCat
>
>
> Hello,
>
> We spent most of the day trying to simulate the load
> on the server and
> trying to do some measurements. It's quite hard to
> get conclusive
> evidence to prove its faster or not. But most tests
> do show an increase
> in speed, on average about a 15% increase. When the
> server is heavily
> loaded we still have to wait around 6 seconds for a
> greeting from the pop3d.
>
> We used postal to test the performance with various
> settings. After a
> lot of calculations we found out that we have ~7
> concurrent smtp
> sessions inbound to the mailserver (all local
> deliveries) and ~25
> concurrent pop/imap users during normal hours. With
> those settings in
> postal we were not able to reproduce the problem to
> our liking.
>
> What we really need is a live test, but i can't do
> that here. My users
> would kill me ;) Maybe someone who didn't fallback
> to the old version
> (1.6.xx) can do some tests. Helmut maybe?
>
> Thanks for the quick fix anyway!
>
> Regards,
>
> Hugo
>
>
> Walter Wong wrote:
>
> > Spark <[EMAIL PROTECTED]> writes:
> >
> >> Maybe somebody can comeup with change to the code
> that can implement
> this??
> >
> >
> > ok, the change is in cvs. I also included a diff
> below.
> >
> > Please let us know if this makes things any better
> (or worse).
> >
> > Walter
> >
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
