I did not see a reply to Martijn's inquiry. I am particularly interested in
question #2and #4 below, but in my case it's on a Solaris 5.8 (Cyrus 2.1.11)
platform migrating to Linux AS 3.0 (Cyrus 2.2.12).
2.1.11 does not have the "xfer" command, 2.2.12 does. Which release of 2.1.XX
was the 'xf
I did not see a reply to Martijn's inquiry. I am particularly interested in
question #2and #4 below, but in my case it's on a Solaris 5.8 (Cyrus 2.1.11)
platform migrating to Linux AS 3.0 (Cyrus 2.2.12).
2.1.11 does not have the "xfer" command, 2.2.12 does. Which release of 2.1.XX
was the 'xfe
I'll have to check on the entrophy but I believe we are past the 12/02 release
mentioned in 1-25-27606-1, but I'll check on Monday.
I remember reading in the archives that you need to kill the "master" process as
there is no other way to restart it. Am I incorrect? Usually when we have DB lo
We're using :
cyrus sasl 1.5.20
Open SSL 0.9.6g
Kerberos V5
The majority of the clients are:
Pine 4.21 and Outlook
Thanks,
Bob
>
> On Fri, 23 Jan 2004 [EMAIL PROTECTED] wrote:
>
> > We are using STK's Shared Virtual Array, V960's with PPRC
> > (Peer-to-peer-remote-copy).
> >
> > Just fo
We are using STK's Shared Virtual Array, V960's with PPRC (Peer-to-peer-remote-copy).
Just for a test, we moved the /var/imap directory onto local disk (disk mirrored using
Disksuite) and IO wait shot up to over 80%.
Is there a fix/solution for the SSL imap/pop daemons dieing other than to upg
It 4.0.14 (November 18, 2001).
Here's the output from 6 periods:
r/sw/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
1.3 24.78.0 202.5 0.0 3.30.5 125.6 0 15 c3t17d2s0
2.1 57.8 10.8 414.6 0.0 7.00.0 116.4 0 45 c3t17d2s0
1.5 62.67.5
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
