On Tue, Jan 26, 2016, at 05:24 PM, Hallvard Breien Furuseth wrote: > Maybe it would work to move Statslog( ... ACCEPT ...) > above ldap_pvt_thread_mutex_unlock( &c->c_mutex ); > at the end of servers/slapd/connection.c:connection_init(). > Holding on to the mutex longer would make slapd a bit > less responsive, though. No idea how much.
That's kinda what I initially expected openldap to do :D > Another variant: Put the cost in the log parser instead. yep, that's the way I worked around this problem > When you see an ACCEPT, delay processing log lines until > you've seen some more lines, in case they are out of order. > I've got an old tweak to contrib/slapd-tools/statslog > which does that and some other stuff, here: > <http://folk.uio.no/hbf/OpenLDAP/statslog.reorder> I was sending my logs through syslog=>logstash=>elasticsearch correlating binds and accepts in logstash (whose filters prevented me to easily implement delays) So, considering the rarity of the mixed log entries, I decided to: 1) save both accept and bind entries in elasticsearch 2) keep correlating events in passing through logstash, if possible 3) schedule a script which "correlates uncorrelated" binds and deletes old connections data from elasticsearch > Don't remember why I haven't committed it. Maybe > it isn't quite finished or I hoped to optimize it, > since it does slow the script down. I'd be glad to > hear of any improvements from you:-) Perl scares me :) > Come to think of it, statslog is quite old. It > might need some tweaks to catch up with whatever has > been done to OpenLDAP logs since it was written. I suppose it would be nice to have an option to force Openldap to write ordered logs (obviously with a performance penalty). Or maybe enabling logging the real operation timestamp (as in: generated just before the operation itself), enabling a simple filter to reorder logs. Thanks > Hallvard dario
