[Date Prev][Date Next]
Re: openldap.git branch master updated. 2d5996ac603391ddbd618425f88eb13e5e0e2cc0
- To: Michael Ströder <email@example.com>, openldap-commit2devel@OpenLDAP.org
- Subject: Re: openldap.git branch master updated. 2d5996ac603391ddbd618425f88eb13e5e0e2cc0
- From: Howard Chu <firstname.lastname@example.org>
- Date: Sun, 1 Nov 2015 16:02:18 +0000
- In-reply-to: <email@example.com>
- References: <E1ZsUnp-0001tt-KU@euler.openldap.org> <5634AF7E.firstname.lastname@example.org> <email@example.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38a1
Michael Ströder wrote:
Howard Chu wrote:
A note about this revised patch - accesslog uses op->o_time/op->o_tincr to
generate its RDNs. We actually have a problem here in that microsecond
resolution may no longer be adequate. Back in January I was on site with a
customer whose 64-core server was hitting ~1 million queries/sec. Granted,
that was with syslog and accesslog disabled; with logging enabled we're far
Very soon we're going to need higher resolution when logging is enabled.
At that speed I'm mostly concerned about entryCSN values and MMR conflict
Note that CSNs already support finer than microsecond resolution.
But since delta-syncrepl relies on accesslog, that's more of a concern.
As for syslog - currently, with my experimental syslog() code, my best result
still takes 60% longer when running with -s256 (STATS loglevel) vs -s0. If I
comment out the send() on the /dev/log socket to rsyslogd, and leave all the
message formatting code intact, it's only 10% slower. So most of the slowdown
is in the actual send() syscall.
(Using the original code is around 2.5x slower for -s256 than -s0)
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/