Q: "deferring operation: too many executing" / "deferring operation: pending operations"
Hi!
I have a question for the following log messages: slapd[2215]: connection_input: conn=144871 deferring operation: too many executing slapd[2215]: connection_input: conn=144871 deferring operation: pending operations slapd[2215]: connection_input: conn=144871 deferring operation: pending operations
What is "too many", i.e. where is that limit configured? Is it possible to tell how many "pending operations" there are?
Finally: It seems slapd "drives against the wall hard", meaning it runs at full speed until the limit is reached, the refuses any more connection/operation. Is it possible to activate (configure) a "soft knee" behavior, where after reaching a specified limit of connections or operations rate slapd starts responding increasingly slower? That would help load balancers to select a different server in time...
Regards, Ulrich
Am Mon, 10 Dec 2018 10:16:54 +0100 schrieb "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de:
Hi!
I have a question for the following log messages: slapd[2215]: connection_input: conn=144871 deferring operation: too many executing slapd[2215]: connection_input: conn=144871 deferring operation: pending operations slapd[2215]: connection_input: conn=144871 deferring operation: pending operations
What is "too many", i.e. where is that limit configured? Is it possible to tell how many "pending operations" there are?
In fact bash(1) is the culprit, read bash(1) on ulimit. The reason most likely is too many filesystem I/O's requested, bad search filter design, too many operations on the same index database, etc.
-Dieter
Dieter Klünter wrote:
Am Mon, 10 Dec 2018 10:16:54 +0100 schrieb "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de:
Hi!
I have a question for the following log messages: slapd[2215]: connection_input: conn=144871 deferring operation: too many executing slapd[2215]: connection_input: conn=144871 deferring operation: pending operations slapd[2215]: connection_input: conn=144871 deferring operation: pending operations
What is "too many", i.e. where is that limit configured? Is it possible to tell how many "pending operations" there are?
In fact bash(1) is the culprit, read bash(1) on ulimit. The reason most likely is too many filesystem I/O's requested, bad search filter design, too many operations on the same index database, etc.
No, ulimit has nothing to do with this.
No single connection is allowed to use more than half of the number of slapd threads. Once that limit is reached on any connection, further ops on that connection are queued.
Howard Chu hyc@symas.com schrieb am 11.12.2018 um 13:07 in Nachricht
de393557-10ad-55a1-8771-61311d35f000@symas.com:
Dieter Klünter wrote:
Am Mon, 10 Dec 2018 10:16:54 +0100 schrieb "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de:
Hi!
I have a question for the following log messages: slapd[2215]: connection_input: conn=144871 deferring operation: too many executing slapd[2215]: connection_input: conn=144871 deferring operation: pending operations slapd[2215]: connection_input: conn=144871 deferring operation: pending operations
What is "too many", i.e. where is that limit configured? Is it possible to tell how many "pending operations" there are?
In fact bash(1) is the culprit, read bash(1) on ulimit. The reason most likely is too many filesystem I/O's requested, bad search filter design, too many operations on the same index database, etc.
No, ulimit has nothing to do with this.
No single connection is allowed to use more than half of the number of slapd
threads. Once that limit is reached on any connection, further ops on that connection are
queued.
I hardly saw any connection executing more than one operation simultaneously in the past. So I'd really like to learn what's going on. Unfortunately thes events are quite rare. Could it be caused by some disk I/O (read slow) problem?
Ulrich
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
openldap-technical@openldap.org
-
Dieter Klünter -
Howard Chu -
Ulrich Windl