Why do you need to kill an imapd process? http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&searchterm=kill&msg=25918
-Igor On Sat, 24 Jan 2004, Andrew Brink wrote: > Just curious but what is the correct way to kill an imapd or pop3d > process? > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Igor Brezac > Sent: Friday, January 23, 2004 4:46 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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