[Vous ne recevez pas souvent de courriers de hyc@symas.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

ATTENTION : Cet e-mail provient de l'extérieur de l'organisation. Ne cliquez pas sur les liens et n'ouvrez pas les pièces jointes à moins que vous ne reconnaissiez l'expéditeur et que vous sachiez que le contenu est sûr.

Quanah Gibson-Mount wrote:
>
>
> --On Monday, March 25, 2024 6:06 PM +0000 Christopher Paul <chris.paul@rexconsulting.net> wrote:
>
>>> Those aren't errors.
>>
>> But a deferral is not optimal, is it? I think the question "hints about
>> way to debug" is probably a good one. The brute force method to fix this
>> would be to add consumers and spread out the load. Horizontal scaling is
>> the main benefit of a replicated architecture.

>>> slapd[37277]: connection_input: conn=32974 deferring operation: too many executing

> Deferrals are common, they are not necessarily indicative of an issue, and without more detail there's no way to determine there is an issue that needs to be
> addressed or not.

Yes, they're common, and these are caused by a client sending too many operations over
a connection without waiting for them to complete. In other words, a poorly written
client.

Simply adding more replicas does nothing to address this, you need a load balancer that
spreads all client queries out, even when they're all coming in from a single connection.

Better yet is to identify the client and fix it.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/