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 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/