skiplist vs db format

Andrew Brink abrink at netstandard.net
Sat Jan 24 11:44:03 EST 2004


Just curious but what is the correct way to kill an imapd or pop3d
process?

-----Original Message-----
From: owner-info-cyrus at lists.andrew.cmu.edu
[mailto:owner-info-cyrus at lists.andrew.cmu.edu] On Behalf Of Igor Brezac
Sent: Friday, January 23, 2004 4:46 PM
To: throwaway-it at cox.net
Cc: info-cyrus at lists.andrew.cmu.edu
Subject: Re: Re: skiplist vs db format



After I read your message again, you should _not_ kill an imapd process
by hand.  This is probably a large part of your problem.  If you want to
be able to do this, you need to upgrade to cyrus 2.2.3.

> > > Is there a fix/solution for the SSL imap/pop daemons dieing other 
> > > than to upgrade to latest Cyrus?
> > >
> >
> > I am not aware of SSL issus with cyrus and solaris.  What entropy 
> > package do you use?
> >

What is providing entropy for cyrus (/dev/(u)random)?  Solaris 8
requires a patch or a /dev/(u)random package from
http://www.cosy.sbg.ac.at/~andi/SUNrand/...


> > -Igor
> >
> > >   Bob
> > >
> > > >
> > > > Your drives are working overtime.  There is nothing waiting to 
> > > > be written (good), but service time is high and I imagine things

> > > > feels a bit sluggish.  Is this software RAID?  Can you add more 
> > > > drives?
> > > >
> > > > I do not know if skiplist will reduce your disk load (my guess 
> > > > is yes because skiplist does not maintain on-disk environment 
> > > > like berkeley does), but I would change to skiplist regardless 
> > > > because of stability. You will not have to restart cyrus as 
> > > > often if at all.
> > > >
> > > > -Igor
> > > >
> > > > On Fri, 23 Jan 2004 throwaway-it at cox.net wrote:
> > > >
> > > > > It 4.0.14 (November 18, 2001).
> > > > > Here's the output from 6 periods:
> > > > >
> > > > >     r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b
device
> > > > >     1.3   24.7    8.0  202.5  0.0  3.3    0.5  125.6   0  15
c3t17d2s0
> > > > >     2.1   57.8   10.8  414.6  0.0  7.0    0.0  116.4   0  45
c3t17d2s0
> > > > >     1.5   62.6    7.5  443.7  0.0 25.2    0.0  394.1   0  55
c3t17d2s0
> > > > >    63.6   63.6  502.9  443.1  0.0  7.7    0.0   60.8   0  64
c3t17d2s0
> > > > >     1.8   67.1    9.0  471.4  0.1 24.4    0.8  354.0   1  47
c3t17d2s0
> > > > >     1.9   69.7    8.9  485.0  0.0 16.5    0.0  229.9   0  53
c3t17d2s0
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > What version of Berkeley DB4?  If it is 4.1.25+ you need to 
> > > > > > upgrade cyrus (2.1.16 or 2.2.3).  What does 'iostat -xPn 30'

> > > > > > show for the RAID 1 partition?
> > > > > >
> > > > > > -Igor
> > > > > >
> > > > > >
> > > > > > On Fri, 23 Jan 2004 throwaway-it at cox.net wrote:
> > > > > >
> > > > > > > For those of you who have converted from the Berkeley db 
> > > > > > > to skiplist, what kind of a performance improvement did 
> > > > > > > you receive?
> > > > > > >
> > > > > > > We are using Berk. db4 and the IO wait for the disk 
> > > > > > > containing the db is consistantly over 50%.  The partition

> > > > > > > is 7GB, which also contains the user, quota, proc, and db 
> > > > > > > directory.  It resides on an STK V960 fibre channel, RAID 
> > > > > > > 1 disks.  I am seeing "DBERROR db4: nnnn lockers" errors 
> > > > > > > with the number over 10,000+ ... usually soon afterwards, 
> > > > > > > the imap process needs to be restarted.
> > > > > > >
> > > > > > > Also, the 'imapd -s' and 'pop3d -s' process unexpectedly 
> > > > > > > dies and SSL connections are no longer possible until imap

> > > > > > > process is restarted.  Is this a known problem?
> > > > > > >
> > > > > > > Our platform is :
> > > > > > > Cyrus 2.1.11
> > > > > > > Solaris 8, Sunfire 280R
> > > > > > > 4GB memory, 2 CPU
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > >   Bob
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Igor
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Igor
> > > >
> > >
> > >
> >
> > --
> > Igor
> >
>
>

-- 
Igor





More information about the Info-cyrus mailing list