Clearly I am using an old version:
Sleepycat Software: Berkeley DB 4.2.52: (December 11, 2004)
I will upgrade that and see.
You do not mention your OS, distribution, details about your hardware
configuration or anything else relevant to your OL environment save
DB_CONFIG details.
I can't see much wrong with the latter for a small scale DB; if you are
running a large scale DB then you probably haven't allocated enough
cache memory. I don't know what the defaults are for max_locks,
max_lockers or max_objects - Quanah or others could possibly help with
those.
I've been running, and am presently running, OL 2.2.33-2.3.37 SleepyCat
(now Oracle) BDB 4.2.52 in production on 4 servers at my 1500+ user,
50MB DB location 24x7x52 for years with no problems. First on Red Hat
RHEL4, since Aug last on RHEL5. On grade A IBM hardware, both x86_32 and
64. Thousands of others are running 4.2.52 without problem on other
hardware and other OSs.
The proviso is, that the libraries *have* to be patched with 4, possibly
5 depending on the patch versions, discrete patches.
Standard db4 on RHEL5 is 4.3.29. i.e. later than 4.2.52 with patches.
But I've found out for myself by using standard Red Hat-supplied OL
2.3.27 that it doesn't work with OL 2.3.38. Therefore I use discrete db4
4.2.52 libraries for slapd and friends supplied by Buchan Milne.
If you do upgrade your db4 version, please make it 4.6+, enough has been
written about that in this ML. Everything between patched 4.2.52 and 4.6
should be avoided. Moreover, if other things are making use of db4
4.2.52 on your unknown OS/distribution, then simply replacing it with an
upgrade will most probably break everything else depending on 4.2.52.
In the dim and distant past (on RHEL3) I had source OL, BDB 4.2.52,
Cyrus SASL 2.1 all separate in /usr/local and life was hell for various
reasons. Try to avoid this kind of thing, keep installs as uniform as
possible with a package managing system. Luckily, Buchan Milne supplies
plug-in Red Hat rpms, which I use (actually I rebuild his srpms, since I
have 2 architectures to build on).
Bottom line: I don't believe that swapping 4.2.52 for a db4 "upgrade" is
going to help your problem: 4.2.52 works well for all than the most
demanding uses. Could document this with Howard Chu's extensive doco,
but I'll leave it up to you to search this out in the archives.