reoccuring DBERRORs

[Mika Iisakkila]

Rob Mueller wrote:
> I don't know anyone who uses BDB for critical DB's in cyrus. They're too 
> big for seen/sub state db's, too slow for enumerating across the 
> mailboxes db, which really only leaves suplicate delivery and tls cache 
> dbs.

HP-UX people. The mmap() implementation on HP-UX won't do for the kind
of operations that Cyrus does, and without real mmap() skiplist becomes
unusably slow for mailboxes.db.

2.2.12 works now nicely on HP-UX 11.23, but it's really sensitive
on the version of BDB, and the mutex implementation used when compiling
BDB itself. I had to ditch POSIX mutexes and revert to test-and-set
spinlocks, but now BDB 4.2.52 and 4.3.28 both seem stable.

> We have seen many strange problems with BDB over the years. It's taken 
> quite a bit of fiddling of /var/imap/db/DB_CONFIG values to get a BDB 
> environment that will run stably over extended periods and loads and on 
> large servers with growing user bases.

Having a Berkely cache large enough to contain the entire database
seems to help a lot. OpenLDAP FAQs contain lots of tuning info on BDB,
most of which applies to Cyrus, too. BDB locking in particular has several
parameters which don't consume too much resources when increased, but
will hose the database if the limit is reached during runtime. The defaults
will not be enough for hundreds of service processes.

--mika