-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
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 Sle
Hi,
we will try to apply the patch to our server in one -
two days time. This will provide some reall life
testing. Hopefully that will show something.
H.
--- Spark <[EMAIL PROTECTED]> wrote:
> Hello,
>
> We spent most of the day trying to simulate the load
> on the server and
> trying to do so
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
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
Nick,
we did not have the problem on Cyrus 1.5.14 (not using LMTP) on a Linux 2.2
kernel (Linux RedHat 6.0)
Regards
Niek Rijnbout
At 21:46 25-04-2001 +0300, Nick Ustinov wrote:
>well, it seems that this problem is only experienced by redhat users. i
>played with different kernels, same result
--- Nick Ustinov <[EMAIL PROTECTED]> wrote:
> well, it seems that this problem is only experienced
> by redhat users. i
> played with different kernels, same result. what was
> cyrus ver that worked
> fine for you? i tried 2.0.9 - it was just like
> 2.0.12.
Our server was running 1.5.21 first (I
il 25, 2001 23:27
To: Nick Ustinov; [EMAIL PROTECTED]
Subject: RE: forking problem cd..
Nick,
we did not have the problem on Cyrus 1.5.14 (not using LMTP) on a Linux 2.2
kernel (Linux RedHat 6.0)
Regards
Niek Rijnbout
At 21:46 25-04-2001 +0300, Nick Ustinov wrote:
>well, it seems that this
--- [EMAIL PROTECTED] wrote:
> Hello fellow listmembers,
>
> We switched to a new version of the cyrus imapd
> (version 2.0.12) and i think we have encounted the
> 'locking problem' that is being discussed here.
>
> What we are seeing here is that it takes a long
> while for the greetings to sh
well, it seems that this problem is only experienced by redhat users. i
played with different kernels, same result. what was cyrus ver that worked
fine for you? i tried 2.0.9 - it was just like 2.0.12.
nick
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wedn
--- Simon Loader <[EMAIL PROTECTED]> wrote:
>
> > After some more testing we think that the main
> problem
> > is between lmtpd processes accessing the
> > /var/imap/deliverdb databases. While reading a
> source
> > of imap/duplicate.c, there's a note next to
> > get_db_name
> > function saying
Helmut Apfelholz writes:
>
>I've just checked the CVS, duplicate.c hasn't been
>changed at all, so the algorithm remains the same. I
>also haven't seen any patch in the archives.
The patch was submitted to the Cyrus bug reporting address some time
ago. All it does, though, is to provide an eve
oader [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 25, 2001 2:00 PM
To: Helmut Apfelholz
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: forking problem cd..
> After some more testing we think that the main problem
> is between lmtpd processes accessing the
> /var/imap/deliv
> After some more testing we think that the main problem
> is between lmtpd processes accessing the
> /var/imap/deliverdb databases. While reading a source
> of imap/duplicate.c, there's a note next to
> get_db_name
> function saying that too many processes where
> contending for the locks on del
> > This is a workaround. We really need a solution to
> the
> > problem. We will be looking into some alternatives
> to
> > sleepycats library for some of the databases. I
> was
> > thinking about trying the tdb library from samba
> > project.
>
> What is the advantage of tdb over BerkeleyDB?
I
Helmut Apfelholz wrote:
> This is a workaround. We really need a solution to the
> problem. We will be looking into some alternatives to
> sleepycats library for some of the databases. I was
> thinking about trying the tdb library from samba
> project.
What is the advantage of tdb over BerkeleyD
This is a workaround. We really need a solution to the
problem. We will be looking into some alternatives to
sleepycats library for some of the databases. I was
thinking about trying the tdb library from samba
project.
Or maybe there should be some way to, hm 'renice' the
lmtpd having a locks in
I can confirm that with this solution works,
but there is still a problem with cyrus which
should be fixed.
Regards,
ds
Nick Ustinov wrote:
> I have solved the problem my switching sendmail to DeliverMode=q with 1m
> interval
>
> -Original Message-
> From: Helmut Apfelholz [mailto:[EMA
I have solved the problem my switching sendmail to DeliverMode=q with 1m
interval
-Original Message-
From: Helmut Apfelholz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 24, 2001 19:04
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: forking problem cd..
Hi,
he
lly help.
Nick Ustinov
[EMAIL PROTECTED]
http://www.videinfra.com
-Original Message-
From: Krzysztof Sierota [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 18, 2001 11:44 PM
To: Dori Seliskar; Nick Ustinov
Cc: '[EMAIL PROTECTED]'
Subject: Re: forking problem
I'd like to
Nick Ustinov wrote:
> Hi!
>
> I use cyrus 2.0.12 + pam_mysql, sendmail 8.11.0 on a dual p3/550 with 1G ram
> (linux redhat7, kernel 2.4.2).
> I've faced a very strange problem -- when the system is under heavy load
> (however, there is ~300Mb of free memory and free ~50% cpu) master process
> is
22 matches
Mail list logo
