[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]