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 <[email protected]> > *Envoyé :* lundi 25 mars 2024 20:52 > *À :* Quanah Gibson-Mount <[email protected]>; Christopher Paul > <[email protected]>; BECOT Jérôme <[email protected]>; > openldap-technical > <[email protected]> > *Objet :* Re: Help debugging slave slapd issues > > [Vous ne recevez pas souvent de courriers de [email protected]. 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 >> <[email protected]> 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/
