openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8054) Operation duration logging
by h.b.furuseth＠usit.uio.no 11 Feb '15

11 Feb '15

On 11. feb. 2015 12:38, Michael Ströder wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Cool feture, but please use fewer characteres in the already >> bloated log. How about "time=<integer>us" or even omit the "us"? > > +1 > > But 'time' sounds a bit general. > How about 'tdu' or even 'td' as abbreviation for "time duration"? I don't think so. You can't see from that what it means unless you already know, so you have to look it up just to see if you're interested. 'time' you can decide to look up if you are interested. -- Hallvard

1 0

Re: (ITS#8056) [PATCH] libdb version is not detected correctly when using gcc5
by jsynacek＠redhat.com 11 Feb '15

11 Feb '15

--=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Howard Chu <hyc(a)symas.com> writes: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: 2.4.40 >> OS: GNU/Linux >> URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150211-fix-li= bdb-detection-with-gcc-5.patch >> Submission from: (NULL) (94.112.188.81) >> >> >> The old cpp version generated: >> __db_version 5 >> >> Configure then correctly picked up the version, since it greps for >> "__db_version". >> >> The new output: >> __db_version >> 5 >> >> Grepping no longer works and configure fails. >> >> Running cpp with -P (inhibit linemarkers generation) fixes this when usi= ng gcc >> 5. >> Behavior with older versions of gcc is not changed. > > Your patch is simple enough but frankly this sounds like a bug in gcc=20 > 5's cpp. It shouldn't be inserting gratuitous whitespace in the middle=20 > of lines, or inserting line breaks arbitrarily. Yes, probably. But in the meantime, I needed the package to build, so I wrote this patch. Cheers, =2D-=20 Jan Synacek Software Engineer, Red Hat --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU22YfAAoJEL3BmMJQOtjBgz0P/0C6vOFzNeDmB/6gJApRB97j qQ+eAfs+VVi1nzanutQUZWIHM8F1wFFUm1ULp76z8dkxrquI9VSpTzWSj2kMPMqY iGZfK6fRM84Weog2iCR9LoVqXrNCkih1pOi3SBaQE8pLxZh0iLCg5ZEW3QEgoVam UMQz0fU5fFKtvKB85Xcy02drn64dTSn5zyF59H0CgVCTC3GBYP/tR2qp//ZPb2jj WsOMdSzx9ENf56Y/r6fmMRpKN3+c8jLHf7/zbStDIgVnCv6Haf8bLevgSYYejkus Av5U88rM9proraf6DvjwpJFfk6OCzvVo0eOcE63orw+uHyYQz/vWCLaK4/Wwo1e/ 84MekmHm1G9pQMpnrgOkUqQv/MYVQpeIgrL29DZC4y4nDa68iL7+WdNqova3s5ST 6onQTdIR8YBwVRXAfnV00SmJAEslzouhEH5MF7mcLCI+/06EnaKzqtMuTsQZvC1I 9oucRZRgdnax3jTyzDwyvxvei5/yvIESvj3NOx2vq35NxE2vqSpRqIGVucDM4cnN HVzk7fd6nFGhG9ZKWgv+2+kz6lZlH+3duIR0nJydgUJJPlRS8NxysNw439Q+Wu2D ql+Vfl9BglSrCwiE6+QrVmE9W5PLj1/I5AgE6Wrdl6zrAxYI2fj7LgiavM8tmWIp RvUpCjFNkI6AiD2KmmpV =bSRG -----END PGP SIGNATURE----- --=-=-=--

1 0

Re: (ITS#8056) [PATCH] libdb version is not detected correctly when using gcc5
by hyc＠symas.com 11 Feb '15

11 Feb '15

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: 2.4.40 > OS: GNU/Linux > URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150211-fix-libdb-dete… > Submission from: (NULL) (94.112.188.81) > > > The old cpp version generated: > __db_version 5 > > Configure then correctly picked up the version, since it greps for > "__db_version". > > The new output: > __db_version > 5 > > Grepping no longer works and configure fails. > > Running cpp with -P (inhibit linemarkers generation) fixes this when using gcc > 5. > Behavior with older versions of gcc is not changed. Your patch is simple enough but frankly this sounds like a bug in gcc 5's cpp. It shouldn't be inserting gratuitous whitespace in the middle of lines, or inserting line breaks arbitrarily. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8054) Operation duration logging
by michael＠stroeder.com 11 Feb '15

11 Feb '15

h.b.furuseth(a)usit.uio.no wrote: > Cool feture, but please use fewer characteres in the already > bloated log. How about "time=<integer>us" or even omit the "us"? +1 But 'time' sounds a bit general. How about 'tdu' or even 'td' as abbreviation for "time duration"? Ciao, Michael.

1 0

Re: (ITS#8054) Operation duration logging
by h.b.furuseth＠usit.uio.no 11 Feb '15

11 Feb '15

Cool feture, but please use fewer characteres in the already bloated log. How about "time=<integer>us" or even omit the "us"? When duration is of interest, what's usually interesting is probably which operations stand out as slower, not the actual speed. When duration is not of interest, then it's noise to keep small and boring. And we should document at least the default log format (Statslog). == About the code, ignoring the above suggestion for now: Once upon a time, floating-point was slow. Today, that extra code to avoid it is a pessimization at least on my Linux/x86. Try this: #define TIMEDIFF_MS(a,b) \ (((a)->tv_sec-(b)->tv_sec)*1000 + ((a)->tv_usec-(b)->tv_usec)/1000.0) OTOH floating-point printf is compex, you save a bit by doing msec = (int)t; printf("%d.%03d", msec, (int)((t-msec)*1000)); instead of printf("%4.3f", t); %d format requires 'int msec;' and (int)(duration.tv_usec % 1000). Since timersub() is use the same way each time, a macro could instead compute duration and msec, and maybe declare them too: DURATION_DECLARE(duration, msec, op->o_hr_time); For that matter, maybe we should get rid of the #ifdef-duplicated Statslog() statements and put the ugliness in macros instead. Like this, I think - an untested draft: DURATION_DECLARE(duration, msec, op->o_hr_time); StatslogDuration( LDAP_DEBUG_STATS, "%s DISCONNECT tag=%lu err=%d "DURATION_LOG_FMT" text=%s\n", op->o_log_prefix, rs->sr_tag, rs->sr_err, DURATION_LOG_ARG(duration, msec) /* no comma after this */ rs->sr_text ? rs->sr_text : "", 0 ); #ifdef HAVE_GETTIMEOFDAY #define DURATION_DECLARE(..blah..) <the duration code before Statslog> #define DURATION_LOG_FMT "duration=%d.%03dms " /* This is passed to StatslogDuration() without a comma before next arg. * So it is not an extra arg to StatslogDuration(), but it gives two * extra 'int' args to whatever StatslogDuration() passes it args on to. */ #define DURATION_LOG_ARG(duration,msec) (msec), (int)((duration).tv_usec%1000), #define StatslogDuration <like Statslog, but using Log7 instead of Log5> #else #define DURATION_DECLARE(..blah..) #define DURATION_LOG_FMT "" #define DURATION_LOG_ARG(duration, msec) #define StatslogDuration Statslog #endif

1 0

(ITS#8056) [PATCH] libdb version is not detected correctly when using gcc5
by jsynacek＠redhat.com 11 Feb '15

11 Feb '15

Full_Name: Jan Synacek Version: 2.4.40 OS: GNU/Linux URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150211-fix-libdb-dete… Submission from: (NULL) (94.112.188.81) The old cpp version generated: __db_version 5 Configure then correctly picked up the version, since it greps for "__db_version". The new output: __db_version 5 Grepping no longer works and configure fails. Running cpp with -P (inhibit linemarkers generation) fixes this when using gcc 5. Behavior with older versions of gcc is not changed.

1 0

(ITS#8055) High CPU usage with syncreply and wrong port
by adam＠cassar.id.au 10 Feb '15

10 Feb '15

Full_Name: Adam Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.70.231.55) Specifying a syncrepl provider with an unreachable port results in high CPU usage with slapd with slapd never terminating. Example configuration: syncrepl rid=1 provider=ldap://10.1.1.10:9292 type=refreshAndPersist interval=00:00:01:00 retry="60 +" searchbase="dc=howard,dc=chew" scope=sub schemachecking=on bindmethod=simple binddn="cn=admin,dc=howard,dc=chew" credentials=iwritecode

1 0

Re: (ITS#8054) Operation duration logging
by michael＠stroeder.com 09 Feb '15

09 Feb '15

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> ebackes(a)symas.com wrote: >>> Here is a patch to add duration logging for operations that appears in the >>> standard result messages of statslog. It's a reasonably small change with >>> negligible performance implications except under pathological benchmarking >>> conditions. It does change the quasi-machine-parsable statslog format, however, >>> so it might not be appropriate for general 2.4 release. Example line: >>> >>> 54d8298c conn=1000 op=1 SEARCH RESULT tag=101 err=0 duration=0.170ms nentries=1 >>> text= >> >> This is a very important feature. Highly appreciated! >> >> I'd love to see this in RE24. Yes, I know. No more features. :-( >> >> Would it be possible and make sense to have this configurable per database? > > No it would not make sense. There are ops like Abandon and Unbind which > have no associated database. Aren't Abandon and Unbind associated by authz-DN? Or how is this solved in slapo-accesslog? Ciao, Michael.

1 0

Re: (ITS#8054) Operation duration logging
by hyc＠symas.com 09 Feb '15

09 Feb '15

michael(a)stroeder.com wrote: > ebackes(a)symas.com wrote: >> Here is a patch to add duration logging for operations that appears in the >> standard result messages of statslog. It's a reasonably small change with >> negligible performance implications except under pathological benchmarking >> conditions. It does change the quasi-machine-parsable statslog format, however, >> so it might not be appropriate for general 2.4 release. Example line: >> >> 54d8298c conn=1000 op=1 SEARCH RESULT tag=101 err=0 duration=0.170ms nentries=1 >> text= > > This is a very important feature. Highly appreciated! > > I'd love to see this in RE24. Yes, I know. No more features. :-( > > Would it be possible and make sense to have this configurable per database? No it would not make sense. There are ops like Abandon and Unbind which have no associated database. Adding variation here is creating gratuitous complexity for no benefit. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8054) Operation duration logging
by michael＠stroeder.com 09 Feb '15

09 Feb '15

ebackes(a)symas.com wrote: > Here is a patch to add duration logging for operations that appears in the > standard result messages of statslog. It's a reasonably small change with > negligible performance implications except under pathological benchmarking > conditions. It does change the quasi-machine-parsable statslog format, however, > so it might not be appropriate for general 2.4 release. Example line: > > 54d8298c conn=1000 op=1 SEARCH RESULT tag=101 err=0 duration=0.170ms nentries=1 > text= This is a very important feature. Highly appreciated! I'd love to see this in RE24. Yes, I know. No more features. :-( Would it be possible and make sense to have this configurable per database? Ciao, Michael.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs