On 12/04/2016 01:22 PM, Quanah Gibson-Mount wrote:
--On Saturday, December 03, 2016 6:42 PM -0500 Brendan Kearney
<[email protected]> wrote:
where do i chase down the source of roughly 10k messages a week, given
that this is my home network? do i have a bottleneck in ldap? is
bind-dyndb-ldap pounding on ldap for some unknown reason? i dont
believe
this to an appropriate amount of logs for what seems to be a low volume
network.
Hi Brendan,
a) This has nothing to do with MMR/Mirror Mode
b) It's not uncommon, and it rarely indicates a problem. Again, you
would need to show that things are actually being deferred for a
significant amount of time. Most often it is only for milliseconds.
I.e., it's an informational message that may or may not be indicative
of a real issue.
Overall, you haven't really provided a lot of the necessary
information to help you move forward, such as:
OpenLDAP release
OpenLDAP backend(s) in use
Thread settings
concurrency settings
Specific messages of the problem
etc
For example, it could be the application(s) are poorly written, and
fail to use persistent connections, causing binds to be constantly be
deferred. Or it could be searches being deferred, etc. I.e., we have
no idea /which/ operations are being deferred because you haven't
provided that information.
I personally prefer applying the patch to OpenLDAP that provides
timing information for every operation so that I can actually tell
whether or not real problems are occurring. If that interests you, I
can point you at it.
Hope that helps!
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
my line of thinking was that if mirror mode was not appropriate for
multi master replication, then i would remove the setting and eliminate
the item from my list of potential contributing factors. if mirror mode
is not needed, there are potential efforts and cpu cycles being spent on
doing work that is unnecessary or even detrimental to the performance of
slapd. i am looking make sure mirror mode is safe to remove from my
configs, so i can test the theory.
the below shows 12 log events over a 6 second duration from the same
connection.
ReceivedAt SysLogtag Message
2016-11-15 20:35:05 slapd[1514]: connection_input: conn=6836
deferring operation: too many executing
2016-11-15 20:35:05 slapd[1514]: connection_input: conn=6836
deferring operation: pending operations
2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836
deferring operation: too many executing
2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836
deferring operation: too many executing
2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836
deferring operation: too many executing
2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836
deferring operation: too many executing
2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836
deferring operation: too many executing
2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836
deferring operation: too many executing
2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836
deferring operation: too many executing
2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836
deferring operation: too many executing
2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836
deferring operation: too many executing
2016-11-15 20:35:11 slapd[1514]: connection_input: conn=6836
deferring operation: too many executing
i am running OpenLDAP: slapd 2.4.44 on fedora 24 using lmdb.
listener threads are the default of 1, and the value is not set.
concurrency is the default value, is not set, and i dont know how to
query for the current setting.
i will have to turn up the log level to stats, in order to collect the
log events associated with the deferred connections. i will do that and
reply later with those details. in the meantime, so details about the
environment:
2 hp n54l microservers with 2.2 GHz Athlon II dual core cpu, 16 GB RAM,
250 GB Samsung SSD with a separate mount point for /var/lib/ldap that
has noatime, nodiratime and noexec specified in the mount options to
reduce i/o. boxes also run dns, dhcp, kerberos, sasl, squid, radius,
mariadb, rsyslog over tcp, privoxy, httpd. each has a 4 port Gb NIC,
bonded with increased ring buffers and a bunch of sysctl tweaks for tcp,
udp and ipv4 performance. tcp low latency is also set, to favor low
latency over high bandwidth. what can be load balanced, run in High
Availability, etc is being done behind HAProxy or natively (dhcpd, etc).
with everything i am doing, how do i determine how many listeners and
what concurrency level i should be setting, if at all? are there best
practices? i am thinking that with the slapd environment validated, and
tuned if need be, i have my "ducks in a row" when starting the
conversation on the freeipa mailing list about the bind-dyndb-ldap
package, and potential issues to work through in my configs there.
thanks for the help, input and patience,
brendan
