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