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

Re: OpenLDAP 2.1 (?) on RedHat Enterprise summary

On Thu, 6 May 2004, Rich Graves wrote:

> This summer I'll be replacing our perfectly stable servers running openldap
> 2.0.27 (rebuilt with ldbm backend, berkeley db 4.1.25NC) on redhat
> 7.3+progeny to redhat enterprise. 2.0.27 is terribly unreliable on RHEL 3,
> see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122356, so that's
> clearly out. I'd like to summarize the issues and get updates.
> We run a master and 3 slaves, typically 150K searches (mostly eq indexed
> email aliases) and less than 500 mods/deletes/modrdns on a typical day (but
> up to 7K changes when semesters roll over). TLS is a requirement, krb5 is
> not (but it might be nice if it were stable).
> * OpenLDAP 2.1 v. 2.2 - the sense seems to be that openldap 2.1.30 is where 
>   I should focus my attention. Would anyone recommend that I jump to 2.2.11
>   instead?
> * So is anyone running a serious production environment on RHEL 3/openldap 
>   2.0.27? How did you compile/configure it so that it crashes less than
>   twice per week?
> * Kerberos. There are some old notes that heimdall is required because MIT 
>   kerberos is not thread-safe. Is this still an issue? RedHat seems to 
>   believe that it is not, because they link servers with 1.2.7-19.
> * Backend - bdb is the clear consensus, with caveats that I need to read 
>   the friendly cache tuning documentation.
> * Berkeley DB version. 4.2.52+patches freshly compiled, no question. Don't 
>   try to use the system installed version.
> * libtool, automake, autoconf. I don't understand why the RPM builds have 
>   gone back and forth on dependencies on particular versions of these. 
>   Fedora Core 1.92 wants to compile local copies of all of these just for 
>   openldap. Can someone point me to a discussion of why?

No idea.

> * NPTL kernel issues - redhat backported an entirely new threading model 
>   from the 2.6 kernel. Here's where I'm lost. Mailing list mentions 
>   possible severe performance penalty, with 2 messages recommending use of 
>   the older RHEL 2.1 instead of 3 for this reason. Fedora Core 1.92 adds 
>   extra linkage with this note. Does this patch resolve the problem? Would 
>   building and running with LD_ASSUME_KERNEL=2.2.5 be a good idea?

Granted, you will be serving orders of magnitude fewer searches than I am 
catering for (our performance target is approx 10000 searches per minute 
per server peak) , but we found RHEL3 an order of magnitude slower than 
exactly the same hardware / configuration /software versions as RHEL2.1, 
and RH could provide no assistance. So, RHEL3 doesn't meet the performance 
targets (and neither is it certified for clustering on EMC as 2.1 is).

The performance problem was present on all the versionsofOpenLDAP we 
testedon RHEL3 (2.0.27 original RH-provided packags, our own 2.1.25 and 
2.1.29 packages etc).