Thierry Lacoste wrote: >> So, Correct, yes. However that loglevel records the activity of the >> server in about the same level of detail as you'ld hope to see from any >> other network server.
> With no negative impact on performance for a loaded production server?
> My /var/log/debug.log was already rotating every hour and the machine
> is only in a testing phase.
That depends... The big deal with LDAP is not so much how much data it
can pump out per second, but how fast it can answer each individual
query. That is, *latency* is more important than *bandwidth*.
Remember that from the point of view of slapd, all it has to do is
inject the log message into syslog(3) -- it can then get on with
processing other queries, while syslogd marshals the log data and gets
it into the required log file. In other words, the logging shouldn't add
anything significant to the *latency* of your LDAP queries, unless the
system is so loaded that syslog and slapd are competing for CPU time
slices.
If your LDAP database is sufficiently large that searches are going to
hit the disk rather than being cached in memory, then there's a possible
disk IO contention problem. If that is the case, then arranging things
so that the logging data goes to one drive, and the LDAP database lives
on a different drive would be a big win.
> But clearly /var/log/slapd.log is now rotating fast.
> I'm using nss_ldap and a simple "id lacoste" generates more than 2 KB of logs.
Hmmm... that does seem like quite a lot. Do you have name service caching
configured on the client machines?
> I was considering keeping that setting for testing purposes and
> either turn to local4.info in syslog.conf or set "loglevel=0" in slapd.conf
> when in production. Is this a bad idea?
The only way you're going to get a definitive answer is to benchmark the
different settings under production-level workloads. Logging is the sort
of thing that most of the time you probably don't need, but when things
go horribly wrong, then you will need it badly. Even if you run log-less
most of the time, probably your first response to reported LDAP problems
will be to turn on logging...
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
