Re: Slaves taking up 100% cpu

[Jeff Leung <jeffleung@mac.com>]

Hi all,

Thanks for the replies (and discourses on stability versioning =).

We are already in the process of testing out OpenLDAP 2.1.25 and BerkeleyDB
4.2.52 (with that one patch they have available). In the meantime though, we
are stuck with OpenLDAP 2.1.22 with BerkeleyDB 4.1.25 (the accompanying
patch, btw, seems to only have an effect on databases that include indices,
but I may be wrong).

I was hoping that someone would be able to spot an obvious (or non-obvious)
configuration flaw on my part that would explain the behavior exhibited in
the db_stat output and the 100% cpu usage. Like perhaps an idea on why this
only happens to a slave, or if there is a change that I can make
configuration-wise that will fix or alleviate the relatively high number of
locks being held, etc.

I know it's a PITA to read through all that debugging information (which is
why I summarized the differences), but any help would be greatly
appreciated. Of course, I realize that nobody here is paid to answer other
people's questions. =)

Thanks.

On 1/20/04 9:06a, "Quanah Gibson-Mount" <quanah@stanford.edu> wrote:

> 
> 
> --On Tuesday, January 20, 2004 4:24 PM +0100 Tony Earnshaw
> <tonye@billy.demon.nl> wrote:
> 
>> tir, 20.01.2004 kl. 11.53 skrev Buchan Milne:
>> 
>>> Hmm, I would like to point out that this is not obvious. Previously,
>>> SuSE was criticised for shipping 2.1.22, but at the time SuSE 9 (and
>>> Mandrake 9.2 for that matter) shipped, 2.1.22 was shown on the openldap
>>> site as being the current stable release.
> 
>> There is *no* stable release of Openldap software. As soon as a release
>> has been proved as being stable, it is then judged (Quanah ;) as being
>> no longer supported (me, I'm an experimental person, so what the heck?
>> There's money to be earned on it).
> 
> Tonni,
> 
> Good points. ;)  Although I don't mark other releases as necessarily being
> unsupported (we are currently running 2.1.23 in production, as I've not
> seen anything that really forces me to move forward at this point), but I
> do happen to know from *experience* that 2.1.22 had some major issues. ;)
> And, in general, if someone writes to the list noting that things aren't
> working for them, and it is an older release that has had a number of bugs
> fixed since its release, do I want to spend a lot of time tracking down
> their issue, when it could well be that simply upgrading would fix it? ;)
> (other than obvious errors like bad LDIF files, which definitely won't be
> fixed by upgrading. ;) ).
> 
> --Quanah
> 
> --
> Quanah Gibson-Mount
> Principal Software Developer
> ITSS/TSS/Computing Systems
> ITSS/TSS/Infrastructure Operations
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
> 
> 

-- 
Jeff
// Diplomacy is the art of saying 'nice doggy'
// until you can find a rock.