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

RE: thread problem OpenLDAP 2.1.8 + Solaris 9





--On Monday, November 11, 2002 12:47 PM -0800 Howard Chu <hyc@highlandsun.com> wrote:

-----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,

In our testing, we found no measurable difference between logging at level 256 (11 lines) and no logging.

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.

Understood. I was simply unsure from your post if there was an alternate form of logging with OpenLDAP that I just completely missed. That is obviously not the case. ;)


--Quanah

--
Quanah Gibson-Mount
Senior Systems Administrator
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html