openldap.git branch master updated. 2d5996ac603391ddbd618425f88eb13e5e0e2cc0

[Howard Chu]

Content preview: openldap-***@OpenLDAP.org wrote: > A ref change was
pushed to the OpenLDAP (openldap.git) repository. > It will be available
in the public mirror shortly. > > The branch, master has been updated > via
2d5996ac603391ddbd618425f88eb13e5e0e2cc0 (commit) > via 5324d283d9ff1ba0f608d1130be683eb698f831e
(commit) > from 9f97c1d2efdabc8817538464cd7d08d55f7e51fd (commit) > > Those
revisions listed above that are new to this repository have > not appeared
on any other notification email; so we list those > revisions in full, below.

- Log > commit 2d5996ac603391ddbd618425f88eb13e5e0e2cc0 > Author: Howard

Chu <***@openldap.org> > Date: Wed Oct 28 14:22:58 2015 +0000 > > ITS#8054
Cleanup duration patch > > Don't need op->o_hr_time, just use o_tincr, that's
what it > was intended for anyway. Use "etime=" like other products do. >
Simplify ifdefs. Use gettimeofday, it's always available now. > > commit

Date: Thu Feb 5 18:52:19 2015 -0800 > > ITS#8054 operation duration logging

Summary of changes: > include/ldap_log.h | 6 ++++++ > servers/slapd/operation.c

| 32 +++++++++++++++++++++++--------- > servers/slapd/result.c | 42 ++++++++++++++++++++++++++++++++

servers/slapd/slap.h | 20 ++++++++++++++++++++ > 4 files changed, 81 insertions(+),

19 deletions(-) [...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[69.43.206.106 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: highlandsun.com]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

A ref change was pushed to the OpenLDAP (openldap.git) repository.
It will be available in the public mirror shortly.
The branch, master has been updated
via 2d5996ac603391ddbd618425f88eb13e5e0e2cc0 (commit)
via 5324d283d9ff1ba0f608d1130be683eb698f831e (commit)
from 9f97c1d2efdabc8817538464cd7d08d55f7e51fd (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 2d5996ac603391ddbd618425f88eb13e5e0e2cc0
Date: Wed Oct 28 14:22:58 2015 +0000
ITS#8054 Cleanup duration patch
Don't need op->o_hr_time, just use o_tincr, that's what it
was intended for anyway. Use "etime=" like other products do.
Simplify ifdefs. Use gettimeofday, it's always available now.
commit 5324d283d9ff1ba0f608d1130be683eb698f831e
Date: Thu Feb 5 18:52:19 2015 -0800
ITS#8054 operation duration logging
-----------------------------------------------------------------------
include/ldap_log.h | 6 ++++++
servers/slapd/operation.c | 32 +++++++++++++++++++++++---------
servers/slapd/result.c | 42 ++++++++++++++++++++++++++++++++----------
servers/slapd/slap.h | 20 ++++++++++++++++++++
4 files changed, 81 insertions(+), 19 deletions(-)

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
more limited.

Very soon we're going to need higher resolution when logging is enabled.

[Michael Ströder]

Post by Howard Chu
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
more limited.
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
resolution.

Ciao, Michael.

[Howard Chu]

Content preview: 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 >>
more limited. >> >> 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 > resolution. [...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: highlandsun.com]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[69.43.206.106 listed in list.dnswl.org]
X-BeenThere: openldap-***@openldap.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OpenLDAP development discussion list <openldap-devel.openldap.org>
List-Unsubscribe: <http://www.openldap.org/lists/mm/options/openldap-devel>,
<mailto:openldap-devel-***@openldap.org?subject=unsubscribe>
List-Archive: <http://www.openldap.org/lists/openldap-devel/>
List-Post: <mailto:openldap-***@openldap.org>
List-Help: <mailto:openldap-devel-***@openldap.org?subject=help>
List-Subscribe: <http://www.openldap.org/lists/mm/listinfo/openldap-devel>,
<mailto:openldap-devel-***@openldap.org?subject=subscribe>
Errors-To: openldap-devel-***@openldap.org
Sender: "openldap-devel" <openldap-devel-***@openldap.org>
X-Spam-Score: -4.2 (----)
X-Spam-Report: Spam detection software, running on the system "gauss.openldap.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: 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 >>
more limited. >> >> 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 > resolution. [...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[69.43.206.106 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: highlandsun.com]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

Post by Michael Ströder

Post by Howard Chu
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
more limited.
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
resolution.

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)