Un traitement par lots nocturne épuise les connexions à la base et l'API part en timeout. Comment corrigez-vous ça ?

Arrêtez le dommage immédiat en limitant ou en mettant en pause le traitement par lots, puis séparez les charges de travail pour qu'elles ne puissent plus se concurrencer. Pointez le batch vers un réplica en lecture s'il lit beaucoup, donnez-lui son propre pool de connexions avec un plafond dur, et découpez le travail avec des pauses pour qu'il ne monopolise jamais la base. À plus long terme, réservez de la capacité au trafic interactif et alertez sur la saturation du pool de connexions avant que les utilisateurs ne s'en aperçoivent.

D'abord, on arrête l'hémorragie. On met en pause ou on limite le traitement par lots, parce que le chemin interactif est ce que les clients ressentent et que le batch peut tourner une heure plus tard sans que ça n'émeuve personne. Le correctif tentant, c'est de relever le nombre maximal de connexions, et en général ça empire les choses, puisque chaque connexion a un coût en mémoire et en ordonnancement et que vous finissez avec une base qui s'écroule au lieu d'une base simplement occupée. Donc le vrai correctif, c'est l'isolation. Si le travail lit beaucoup, il passe sur un réplica en lecture, ce qui enlève entièrement la charge du primaire. Il reçoit ses propres identifiants et son propre pool avec un plafond dur, dimensionné pour que même complètement saturé il laisse de la marge à l'API. Et le traitement lui-même est découpé, pour qu'il travaille par lots avec une courte pause et un délai maximal par requête, plutôt qu'une énorme transaction unique qui garde des verrous et fait exploser le retard de réplication. Ensuite la prévention : alerter sur l'utilisation du pool et les requêtes longues à un seuil qui se déclenche avant que ce soit visible par l'utilisateur, pour qu'on l'apprenne par la supervision plutôt que par des tickets du support.