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

RE: thread problem OpenLDAP 2.1.8 + Solaris 9

> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@stanford.edu]

> --On Friday, November 08, 2002 5:21 PM -0800 Howard Chu
> <hyc@highlandsun.com> wrote:

> > Just echoing this - syslog() takes a huge toll on performance. On a
> > single-CPU machine with local log targets, the syslog
> daemon will eat up
> > more CPU and I/O resources than slapd itself. This is
> because syslogd
> > always flushes its disk buffers for every individual
> message it logs. I
> > haven't tested using a remote log destination; it may be
> cheaper since
> > the remote syslog protocol uses UDP, so there would be no filesystem
> > impact.

> Howard,
>
> Since we _must_ have logs of who is accessing our server, with such
> information as IP, SASL bind DN, and query, we need some form of logging.
> Unfortunately, the only logging options I see provided with OpenLDAP are
> the syslog debugging options.  Something like the Netscape Directory Server
> access & error logs would be wonderful to have.  I see nothing in your
> notes above that indicate how someone is supposed to generate those types
> of logs, nor does there appear to be anything in the online documention on
> how to do so either.

Any type of logging that performs reliable writes is going to lower your
query performance. The slapd "-s" and "-d" options will both have this
impact. (Since -d just uses stdio to write to stderr, and stderr is normally
line-buffered, every message is written immediately.) As I already mentioned
above, you may be able to reduce the syslog delay if you configure the local
syslogd to send slapd's messages to a remote syslog daemon. You still incur
the overhead of multiple context switches using the syslog facility, but if
you have multiple CPUs this might not be noticable. You might also improve
matters by using a separate physical disk for syslog output. This is all
ordinary sysadmin stuff, nothing particular to OpenLDAP, which is why I
didn't explicitly state it before.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support