Thanks for your explanation. It's good to know that it's not my fault and I will ignore the messages. At least it is now in the archives.
I gave up trying the new skiplist backend because I couldn't figure out how to set it up. -Simon Amos Gouaux schrieb: > > >>>>> On Fri, 22 Feb 2002 10:09:37 +0100, > >>>>> Simon Matter <[EMAIL PROTECTED]> (sm) writes: > > sm> I have upgraded to db4 today, db3 libs are still there for other > sm> applications. I have then recompiled my cyrus-imapd RPM version 2.1.2. > > sm> Feb 22 10:06:46 dhcp-141-104 pop3d[2135]: DBERROR db3: 8 lockers > sm> Feb 22 10:06:46 dhcp-141-104 pop3d[2136]: DBERROR db3: 9 lockers > sm> Feb 22 10:06:46 dhcp-141-104 pop3d[2139]: DBERROR db3: 10 lockers > sm> Feb 22 10:07:13 dhcp-141-104 imapd[2149]: DBERROR db3: 14 lockers > > To some extent these are normal for BDB. I'm not sure why Sleepycat > chose to log these at error level. I've also never been able to > figure out exactly what trips this message to be logged. Very > roughly there should be somewhere around as many lockers as Cyrus > processes. This will vary somewhat depending on whether you're > using SSL/TLS or not. > > Here's my understanding of things. The lmtpd process will typically > have two read locks: one for deliver.db and another for mailboxes.db. > Other Cyrus processes can have: one for mailboxes.db and another for > tls_sessions.db, depending on whether SSL/TLS is being used. Then > any of these processes can open write locks (via cursor) to update > these db files. > > You can check the current status of lockers by using the db_stat > command. First become the "cyrus" user, then cd to the "db" > directory where the "__db.*" files are at, typically "/var/imap/db". > Then you can run db_stat with the -c option: > > $ /usr/local/BerkeleyDB.4.0/bin/db_stat -c > 18898 Last allocated locker ID. > 9 Number of lock modes. > 50000 Maximum number of locks possible. > 50000 Maximum number of lockers possible. > 50000 Maximum number of objects possible. > 216M Current locks. > 4294M Maximum number of locks so far. > 2147 Current number of lockers. > 2152 Maximum number lockers so far. > 0 Current number lock objects. > 16 Maximum number of lock objects so far. > 274M Number of lock requests. > 274M Number of lock releases. > 0 Number of lock requests that would have waited. > 1188 Number of lock conflicts. > 2 Number of deadlocks. > 0 Number of transaction timeouts. > 0 Number of lock timeouts. > 19MB 624KB Lock region size (20561920 bytes). > 267M The number of region locks granted after waiting. > 2271M The number of region locks granted without waiting. > > You might see a rise in lockers if you experience a lot of Cyrus > processes that crash unexpectedly. Search your logs for the string > 'exited, signaled'. > > Now, 2.1.2 goes a long way to improve the run-away lockers I was > seeing previously. However, I *think* there still might be a tiny > leak somewhere. I'm not sure if it is something stupid I'm doing, a > leak elsewhere in the code, or something crashing my Cyrus > processes. One thing I have observed is that someone using Mozilla > periodically seems to generate an 'exited, signaled to death by 10' > when using SSL with POP. What's odd is that it doesn't seem to > happen all the time, just occasionally. Though, I'm not entirely > sure that alone is the cause of the rising lockers since the number > of lockers seems to be growing faster than his 'death by 10' > incidents. Still looking into it. > > -- > Amos -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:[EMAIL PROTECTED]]
