Thank you for the help. We will look at the clients. I fear sssd would be the culprit, but we have to investigate first. ________________________________ De : Howard Chu <h...@symas.com> Envoyé : lundi 25 mars 2024 20:52 À : Quanah Gibson-Mount <qua...@fast-mail.org>; Christopher Paul <chris.p...@rexconsulting.net>; BECOT Jérôme <jbe...@itsgroup.com>; openldap-technical <openldap-technical@openldap.org> Objet : Re: Help debugging slave slapd issues
[Vous ne recevez pas souvent de courriers de h...@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.p...@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/