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

Re: Open LDAP Load Handling

Prashant K.S wrote:
> Thanks for Responding.Basically my setup consists of a
> Linux 6.1 machine running openldap 1.2.7-2. Of course
> my hardware is good with a RAM of 1GB.

[ ... LDAP falls over after a while, when being used as
      an authentication data store for users on 4 mail
      servers for ~1 million non-simultaneous users ... ]

Thank you for the details of your configuration.

First, make sure that you have a version of the program
with full debugging information (a "-g" compiled version).

The running program should be one that has been copied
from the "-g" version, and stripped of debugging symbols.

This will let you run a small image, but have full source
code available for debugging.


In the "death" case, there should be either a core dump
or a log message about the cause of death.  I don't know
if Linux does this, but BSD systems, as well as other
UNIX systems, will provide a kernel log entry when a
process terminates abnormally, and when a process is
teminated as a result of a signal.

If the abnormal termination is a segmentation violation
or a bus error or an unaligned access error, etc., the
default action should be to log the signal number, and
to dump core for the program.

If your system does not do this currently, you will want
to configure it to do so.  From there, you will have a
base of operations from which to work in determining the

When the system hangs, you should attempt to use the
"gcore" command.  This will generate a core dump for
the live process (without actually killing it), and you
will be able to debug it, at the very least getting a
stack trace to tell you where it's stuck.

In all cases, this will let you debug the problem with
source code.


As a side note, if you are using Linux with kernel
threads based threading enabled, realize that Linux
kernel threads are very heavy weight, so you will
consume as many resources as the same number of
processes, minus the per process open file table, and
minus the page mapping.  With the number of clients
you are running, and the model of one thread per
client, this can become a huge number of resources.

Also, your problem with the dying, if it is a bus error
or segmentation violation, may end up being that you
are doing allocations on a thread local storage, and
passing the data to another thread, without marshalling
it.  It is a common problem with Windows threads, and
with many kernel threads implementations, that the
addresses allocated in one thread, passed to another,
are invalid.

This should at least get you started debugging your
problem... sorry for the rushed answer.

-- Terry Lambert
- Whistle Communications, Inc., an I.B.M. Company
-- terry@whistle.com
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.