> > Under heavy client load, the log shows many "deferring operation: binding" 
> > messages in the same second. slapd is using only 400% cpu (of 1600 
> > possible).
>
> Probably you could increase # of listeners. In a pure Bind-only workload 
> slapd ought to be able to utilize 100% of all cores.

Do you mean the tcp port listeners on the slapd process? Do you think
I'm hitting a socket accept queue max backlog or something else?

slapd  -h ldap://:389 ldaps://:636




On Tue, Apr 13, 2021 at 1:32 PM Howard Chu <[email protected]> wrote:
>
> Zetan Drableg wrote:
> > openldap 2.4.57 on 16 core OracleLinux VMs with NVME disk.
> > 8 nodes in n-way multi master configuration, MDB backend, 50k unique DNs.
> > We see about 10,000 auths per minute per node.
> >
> > Under heavy client load, the log shows many "deferring operation: binding" 
> > messages in the same second. slapd is using only 400% cpu (of 1600 
> > possible).
>
> Probably you could increase # of listeners. In a pure Bind-only workload 
> slapd ought to be able to utilize 100% of all cores.
> >
> > [2021-04-13 19:15:58] connection_input: conn=150474 deferring operation: 
> > binding
> >
> > When I write LDIFs to one node like delete user or remove user from group, 
> > we see spikes in authentication latency metrics (what's normally .2 - .5 
> > second
> > response time goes up to 15-30 seconds) across all nodes in the cluster at 
> > the same time.
> >
> > What knobs can be adjusted to allow for more concurrency? It seems like 
> > writes are impacting reads.
>
> You need more information, like I/O wait %, network % utilization, to 
> identify the cause of these latency spikes.
>
> Nobody can suggest what to tune without knowing why the bottleneck occurs.
>
> --
>   -- Howard Chu
>   CTO, Symas Corp.           http://www.symas.com
>   Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Reply via email to