[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: CVS of todays code freezing erratically ..
> At 10:28 AM 8/11/00 -0700, you wrote:
> >Likely the server is running out of file descriptors or some
> >other resource... which the server doesn't handle well.
> >
> >You should also look at your client and make sure it is properly
> >unbinding the LDAP session.
>
> Well, I have looked at the script, and every instance of a successful
> connection is followed by a disconnect. Also, this same script has no
> problems against the older 1.2.11 server.
>
> The other thing of note is that there a two scripts I am using. One had
> some bugs, which resulted in incorrect output. However, it also was very
> careful to open and close connections properly. Unfortunately, with that
> script, after about 20 to 30 connections, the server will freeze.
>
> I am baffled by this, and any attempt to debug results in an output file
> sever megabytes in size. Also, is we wait for the server to cleanup the
> network connections (takes about 4 minutes), the LDAP server is STILL
> frozen and non-responsive.
>
I would suspect some problem in the thread pooling. Attach to the
process when hung using gdb and see what it's doing/waiting for.
Also, grep your syslog output for 'ldap_pvt' and see if you get
anything like errors. Although I know you are doing this with
2.0-beta, I had a similar problem with 1.2.11 (having to kill -9) because it
ran out of threads a couple of times, and this caused the active_threads
counts to get off (causing "waiting for n threads", when there really
were no threads left to wait for).
A lot of that code has been re-written now to use thread pools in
2.0, but I wouldn't be surprised if you are hitting some limit, as
Kurt says, and OpenLDAP isn't reacting well to that. I certainly
cheer you on to find the bug and fix it. If your problem is too painful
at the moment, I suggest you try increasing SLAP_MAX_WORKER_THREADS
in server/slapd/slap.h, and create another instance of your database
to debug with.
Randy