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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quanah Gibson-Mount Sent: 13 January 2006 00:10 To: James F. Hranicky; [email protected] Subject: Re: Berkeley DB versions --On Thursday, January 12, 2006 3:45 PM -0500 "James F. Hranicky" <[EMAIL PROTECTED]> wrote: > On Thu, 12 Jan 2006 15:21:27 -0500 (EST) > Aaron Richton <[EMAIL PROTECTED]> 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 > 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 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. --Quanah -- 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. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
