[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Berkeley DB versions

Thanks to you all,

I must confess I was clutching at straws - I'm only seeing the issue
rarely (it happened twice in the space of a week about two months ago
then again yesterday). I thought I'd got coreadm all set up properly
(even tested by sending slapd an ABRT signal on my test box)  but didn't
get a core - it turns out I forgot to enable per-process setid core
dumps on my production systems (chimp).  As you guys are finding 4.2
rock solid I'm going to stick with it for now, but recompile BDB with
debugging symbols in case that is where the problem is.  Now I've worked
out why it didn't drop a core I'm less concerned than I was because at
least next time I should be able to find out where the problem is.
Right now all I know is that its dying during a user login at the point
where it trys to write to the db, I'm guessing the write is a result of
the ppolicy overlay (but that is a guess).


-----Original Message-----
From: owner-openldap-software@OpenLDAP.org
[mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Quanah
Sent: 13 January 2006 00:10
To: James F. Hranicky; openldap-software@OpenLDAP.org
Subject: Re: Berkeley DB versions

--On Thursday, January 12, 2006 3:45 PM -0500 "James F. Hranicky" 
<jfh@cise.ufl.edu> wrote:

> On Thu, 12 Jan 2006 15:21:27 -0500 (EST)
> Aaron Richton <richton@nbcs.rutgers.edu> wrote:
>> I'm still using 4.2.52(+4). Quanah still lists 4.2.52(+4) on his
>> 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
> 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
> sol10,  over a minute for Linux, and not worth mentioning for FreeBSD
> (haven't tested 6). Varying the number of threads would sometimes
> some of the queries to finish earlier on Linux, but I don't believe
> average was affected very much.
> This was on a machine I set up to triple boot Linux, Solaris, &
> using the same software versions of BDB & openldap.
> If anyone else has corroborating or contradictory evidence I'd love to
> hear it.

I'll note a few things...

a) I've been using BDB 4.2.52+patches on Solaris for 2 years now.  Once
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
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
BDB 4.3.29 might be usable, I don't know.  I was never very impressed
it, and to this day most people reporting issues around BDB and OpenLDAP
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
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
to performance in a configuration with only a single backend using bdb
hdb.  My servers all run at "threads 8", much less than the default 
"threads 16".  Using additional backends (ldap, meta, etc) and overlays
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
performance of your system is.


Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html


BMRB wins two BMRA awards - http://www.bmrb.co.uk
This message (and any attachment) is intended only for the 
recipient and may contain confidential and/or privileged 
material.  If you have received this in error, please contact the 
sender and delete this message immediately.  Disclosure, copying 
or other action taken in respect of this email or in 
reliance on it is prohibited.  BMRB Limited accepts no liability 
in relation to any personal emails, or content of any email which 
does not directly relate to our business.