[Date Prev][Date Next]
Re: Berkeley DB versions
--On Thursday, January 12, 2006 3:45 PM -0500 "James F. Hranicky"
On Thu, 12 Jan 2006 15:21:27 -0500 (EST)
Aaron Richton <email@example.com> wrote:
I'm still using 4.2.52(+4). Quanah still lists 4.2.52(+4) on his config
website. I'm not sure if anybody else confesses to using Solaris...
I admit it, and I posted about it here last summer, I believe.
Sol 10 x86 flat out smoked Linux and FreeBSD all the times I tested it.
I did a simple test of 10 parallel queries of the entire DB (about 10k
records, 12M ldif total). Each query averaged about 15 secs per query on
sol10, over a minute for Linux, and not worth mentioning for FreeBSD 4/5
(haven't tested 6). Varying the number of threads would sometimes cause
some of the queries to finish earlier on Linux, but I don't believe the
average was affected very much.
This was on a machine I set up to triple boot Linux, Solaris, & FreeBSD
using the same software versions of BDB & openldap.
If anyone else has corroborating or contradictory evidence I'd love to
I'll note a few things...
a) I've been using BDB 4.2.52+patches on Solaris for 2 years now. Once the
final patch sets were in place for it, it has been rock solid for me, on
both OpenLDAP 2.2 and OpenLDAP 2.3. Issues I've had have been outside of
BDB (heimdal, cyrus-sasl, OpenLDAP). My LDAP servers run at a very high
volume 24x7, so I'd expect if there was a BDB 4.2 issue, I'd have seen it.
BDB 4.3.29 might be usable, I don't know. I was never very impressed with
it, and to this day most people reporting issues around BDB and OpenLDAP to
the list are using 4.3. Now with 4.4 out, I'm guessing it is even less
worthwhile to pursue.
b) I've not tested Solaris 10 on the x86 platform at all, so I can't really
speak to that. However, if you were using the Linux 2.6 kernel, the 2.6
kernel developers broke sched_yield deliberately, and OpenLDAP 2.3.17 is
the first real release to address that. I suspect if you were using 2.6
previously, you may find it to be much faster now.
c) I've generally found fewer (rather than more) threads to be beneficial
to performance in a configuration with only a single backend using bdb or
hdb. My servers all run at "threads 8", much less than the default
"threads 16". Using additional backends (ldap, meta, etc) and overlays may
also have an effect requiring more threads for better performance.
For benchmarking purposes, I honestly suggest using a product like slamd
(opensource, www.slamd.com). It uses distributed clients to perform the
queries, which will give you a much more accurate picture of what the real
performance of your system is.
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html