From openldap-technical Wed Mar 27 14:07:11 2024 From: Howard Chu Date: Wed, 27 Mar 2024 14:07:11 +0000 To: openldap-technical Subject: Re: Help debugging slave slapd issues Message-Id: <37604c0f-a4e7-a4af-ca1e-e91dda6603f1 () symas ! com> X-MARC-Message: https://marc.info/?l=openldap-technical&m=171154844331098 BECOT J=E9r=F4me 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 operation= s will eventually get processed. > -----------------------------------------------------------------------= -------------------------------------------------------------------------= ---------------- > *De :* Howard Chu > *Envoy=E9 :* lundi 25 mars 2024 20:52 > *=C0 :* Quanah Gibson-Mount ; Christopher Paul ; BECOT J=E9r=F4me ; ope= nldap-technical > > *Objet :* Re: Help debugging slave slapd issues > =A0 > [Vous ne recevez pas souvent de courriers de hyc@symas.com. D=E9couvrez= pourquoi ceci est important =E0 https://aka.ms/LearnAboutSenderIdentific= ation ] >=20 > ATTENTION : Cet e-mail provient de l'ext=E9rieur de l'organisation. Ne = cliquez pas sur les liens et n'ouvrez pas les pi=E8ces jointes =E0 moins = que vous ne > reconnaissiez l'exp=E9diteur et que vous sachiez que le contenu est s=FB= r. >=20 > Quanah Gibson-Mount wrote: >> >> >> --On Monday, March 25, 2024 6:06 PM +0000 Christopher Paul wrote: >> >>>> Those aren't errors. >>> >>> But a deferral is not optimal, is it? I think the question "hints abo= ut >>> way to debug" is probably a good one. The brute force method to fix t= his >>> would be to add consumers and spread out the load. Horizontal scaling= is >>> the main benefit of a replicated architecture. >=20 >>>> slapd[37277]: connection_input: conn=3D32974 deferring operation: to= o many executing >=20 >> 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 th= at needs to be >> addressed or not. >=20 > 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 po= orly written > client. >=20 > Simply adding more replicas does nothing to address this, you need a lo= ad balancer that > spreads all client queries out, even when they're all coming in from a = single connection. >=20 > Better yet is to identify the client and fix it. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/