>>>>> 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
