[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-technical
Subject:    Re: Help debugging slave slapd issues
From:       Howard Chu <hyc () symas ! com>
Date:       2024-03-27 14:07:11
Message-ID: 37604c0f-a4e7-a4af-ca1e-e91dda6603f1 () symas ! com
[Download RAW message or body]

BECOT Jérôme wrote:
> Thank you for the help. We will look at the clients. I fear sssd would be \
> the culprit, but we have to investigate first.

There's really nothing that needs to be done here. The deferred operations \
will eventually get processed.
> -------------------------------------------------------------------------- \
> --------------------------------------------------------------------------------------
>                 
> *De :* Howard Chu <hyc@symas.com>
> *Envoyé :* lundi 25 mars 2024 20:52
> *À :* Quanah Gibson-Mount <quanah@fast-mail.org>; Christopher Paul \
> <chris.paul@rexconsulting.net>; BECOT Jérôme <jbecot@itsgroup.com>; \
> openldap-technical <openldap-technical@openldap.org>
> *Objet :* Re: Help debugging slave slapd issues
> 
> [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/


[prev in list] [next in list] [prev in thread] [next in thread]