Date: Sun, 23 Jul 2006 08:34:01 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Thierry Lacoste <th.lacoste@wanadoo.fr> Cc: ports@freebsd.org, delphij@freebsd.org Subject: Re: FreeBSD Port: openldap-server-2.3.24: default loglevel and /var/log/debug.log Message-ID: <44C32669.6050603@infracaninophile.co.uk> In-Reply-To: <200607222355.24502.th.lacoste@wanadoo.fr> References: <002001c6adc6$d26dd120$0201a8c0@aldebaran> <44C28E30.6070805@infracaninophile.co.uk> <200607222355.24502.th.lacoste@wanadoo.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig47749D12E3E0995E3F0C556A
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
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 an=
y
>> 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 o=
f logs.
Hmmm... that does seem like quite a lot. Do you have name service cachin=
g
configured on the client machines?=20
> I was considering keeping that setting for testing purposes and
> either turn to local4.info in syslog.conf or set "loglevel=3D0" in slap=
d.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
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enig47749D12E3E0995E3F0C556A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEwyZv8Mjk52CukIwRA284AJ4jWFAYsnu+2NjlH8LLT2RoLsZaQwCfesns
BE8qN/mJyy4MXyRueS4uPaU=
=shqJ
-----END PGP SIGNATURE-----
--------------enig47749D12E3E0995E3F0C556A--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44C32669.6050603>