/opt/cyrus/mailboxes.db: Not enough space

[+archive.info-cyrus at utdallas.edu]

On Wed, 14 Jan 2004, Igor Brezac wrote:

> Hmm.  You can clear this up by running db_recover from the /po/var/imap/db
> directory.  What does db_stat -c say before you run db_recover?  Do
> tls_prune|cyr_expire|ctl_cyrusdb -c run properly on your system?
>
> Also apply http://www.sleepycat.com/update/4.2.52/patch.4.2.52.html...

Ah, thanks for pointing that out, and naughty me for not thinking
to check for patches at the db site.

Anyway...

$ /usr/local/BerkeleyDB.4.2/bin/db_stat -c -h /po/var/imap/db
227362  Last allocated locker ID.
2147M   Current maximum unused locker ID.
9       Number of lock modes.
50000   Maximum number of locks possible.
50000   Maximum number of lockers possible.
50000   Maximum number of lock objects possible.
332     Number of current locks.
604     Maximum number of locks at any one time.
664     Number of current lockers.
1198    Maximum number of lockers at any one time.
2       Number of current lock objects.
13      Maximum number of lock objects at any one time.
12M     Total number of locks requested.
12M     Total number of locks released.
0       Total number of lock requests failing because DB_LOCK_NOWAIT was set.
454     Total number of locks not immediately available due to conflicts.
0       Number of deadlocks.
0       Lock timeout value.
0       Number of locks that have timed out.
0       Transaction timeout value.
0       Number of transactions that have timed out.
19MB 624KB      The size of the lock region..
8560    The number of region locks granted after waiting.
19M     The number of region locks granted without waiting.


Though, things much quieter now than they were earlier.
Hmmm... I wonder if I need to raise some of those limits.

As to tls_prune|cyr_expire|ctl_cyrusdb, haven't seen any
problems with those.  I wonder if I should run tls_prune
more often than the default once a day at 4am....

-- 
Amos