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

Re: OpenLDAP under Solaris




I would like to second these findings, I had similar 
problems running thirty clients. I ended up
stopping all my threaded connections to the LDAP
server call for the moment. Any other insight into
this problem would be great.




On Thu, 21 Jan 1999, Roy Hooper wrote:


> Date: Thu, 21 Jan 1999 20:21:16 -0500
> From: Roy Hooper <rhooper@cyberus.ca>
> To: openldap-bugs@OpenLDAP.org, openldap-devel@OpenLDAP.org,
     openldap-general@OpenLDAP.org
> Subject: OpenLDAP under Solaris
> 
> Good and bad news about OpenLDAP under Solaris 2.6_x86:
> 
> 	- threads don't work worth a damn.  Under heavy load, the server dies an
> unexpected death, and does not generate a core file (unless you run it
> with -d).  The closest to anything useful i've been able to get is that the
> server is dying in _lwp_mutex_unlock().  Without debug information,
> occasionally I got stack traces, but all in hex after _lwp_mutex_unlock().
> With debug information, I only ever got a stack trace from gdb with one
> resolvable item: _lwp_mutex_unlock().
> 
> 	- with a simple patch (attached), you can get OpenLDAP to compile in a
> useable manner:
> 		LIBS="-lposix4 -lpthread"; export LIBS; ./configure --without-threads
> 
> A 45 client performance test running on much more powerful clients than the
> server (common these days, unfortunately), I have been able to sustain about
> 1/2 of the clients at 0.15 seconds a request and the rest at between 0.19s
> to 0.30s per request.  I don't know the reasons why the clients get
> different performance other than maybe the way select() works.  Internal db
> caching may have a great deal to do with the performance differences -- many
> of the clients were started later, so wouldn't be using the newer cache data
> that the first 25 clients are using.
> 
> 45 clients hammering the ldap server non-stop, causing it generate a load of
> 100% isn't really common, i'd imagine, so hey, what can I say?  I'm happy to
> use this version of openldap for authentication now.  I wasn't when it was
> dying on me.
> 
> Unfortunately, a big query will lock the ldap server up solid until it
> finishes.  YUCK.
> 
> I make no guarantees that this patch will actually be a good thing, or that
> it even works anywhere but here.  It's probably completely Not What You
> Want, as it does not take into account autoconf (./configure) or anything
> else.  Hell, I don't know if threads work anymore (my Next test).
> 
> 
> *** ldap/include/lthread.h      Thu Dec 31 14:32:04 1998
> --- openldap-1.1.2/include/lthread.h    Thu Jan 21 19:13:06 1999
> ***************
> *** 208,217 ****
> --- 208,219 ----
> 
>   typedef void  *(*VFP)();
> 
> + #ifndef __sun__
>   /* thread attributes and thread type */
>   typedef int   pthread_attr_t;
>   typedef int   pthread_t;
> 
> + #endif
>   /* default attr states */
>   #define pthread_mutexattr_default     NULL
>   #define pthread_condattr_default      NULL
> ***************
> *** 223,228 ****
> --- 225,231 ----
>   #define PTHREAD_SCOPE_PROCESS   0
>   #define PTHREAD_SCOPE_SYSTEM    0
> 
> + #ifndef __sun__
>   /* mutex attributes and mutex type */
>   typedef int   pthread_mutexattr_t;
>   typedef int   pthread_mutex_t;
> ***************
> *** 234,239 ****
> --- 237,243 ----
>   /* condition variable attributes and condition variable type */
>   typedef int     pthread_condattr_t;
>   typedef int   pthread_cond_t;
> + #endif
> 
>   LDAP_END_DECL
> 
> 
> --
> Roy Hooper
> Sr. Systems Administrator
> Cyberus Online Inc.
> (613) 233-0068
> 
> 

-  ___________.___________________.___________________._______________________
- < Al Piszcz | apiszcz@mitre.org | MITRE Corporation | 703.883.7124/3308 FAX >