L’épuisement des connexions à la base de données en PHP se manifeste souvent par des erreurs intermittentes : certaines requêtes échouent, d’autres restent en attente et le problème s’aggrave aux heures de forte charge. Augmenter la limite de connexions peut apporter un répit, mais aussi déplacer la saturation vers le serveur de base de données. La solution commence par déterminer quelle ressource est épuisée et qui maintient les connexions occupées.
Reconnaître les symptômes et circonscrire la panne
Recherchez des erreurs telles que « too many connections », des échecs à l’ouverture d’une connexion, des délais d’attente dépassés ou des requêtes qui dépassent le temps d’exécution maximal. Comparez leur fréquence au trafic et à d’autres indicateurs : latence de l’application, utilisation du processeur et de la mémoire, erreurs de la base de données et durée des requêtes.
La différence entre les périodes de forte et de faible charge fournit un premier indice. Si les erreurs apparaissent pendant les pics et disparaissent lorsque le trafic baisse, il peut s’agir d’une limite de concurrence. Si elles persistent avec peu de requêtes, recherchez des connexions retenues, des processus bloqués, des requêtes prolongées ou une base de données inaccessible. Vérifiez également si d’autres services partagent la même limite : PHP n’est pas nécessairement le seul consommateur.
Distinguer l’épuisement des connexions des requêtes lentes et des blocages
Ces problèmes sont liés, mais ne sont pas équivalents. L’épuisement des connexions se produit lorsqu’il ne reste aucune place pour en ouvrir une autre. Une requête lente occupe une connexion plus longtemps et peut provoquer l’épuisement lorsque les requêtes s’accumulent. Un blocage laisse une requête en attente jusqu’à ce qu’une autre transaction libère des ressources. L’indisponibilité signifie que la base de données ne peut pas accepter ou traiter les connexions pour une raison plus générale.
Examinez le message et le point de défaillance. Si la requête échoue avant l’exécution d’une requête SQL, vérifiez la création des connexions et la limite atteinte. Si elle parvient à se connecter, puis prend du temps, examinez les requêtes en cours, leur durée, les attentes et les transactions ouvertes. Ne concluez pas que « les connexions manquent » simplement parce que l’application répond lentement : augmenter le nombre de connexions autorisées ne corrige ni une requête coûteuse ni un blocage.
Relier la concurrence de PHP à la limite de la base de données
Dans le modèle habituel de PHP où des processus traitent les requêtes, chaque processus peut avoir besoin d’une connexion pendant qu’il effectue des opérations sur la base de données. La demande potentielle dépend du nombre de processus pouvant travailler simultanément, du nombre de connexions ouvertes par chacun et de la durée pendant laquelle ils les conservent. Il faut également comptabiliser les connexions des tâches en arrière-plan, des commandes en ligne de commande et des autres services.
Établissez une estimation prudente du pire cas : multipliez la concurrence maximale effective de chaque groupe de processus par le nombre de connexions simultanées que chaque processus peut utiliser, puis ajoutez les consommateurs qui partagent la base de données. Comparez ce résultat à la limite configurée et gardez une marge pour les opérations d’administration et les variations de charge. Ne partez pas du principe que chaque requête correspond toujours à une connexion : le cycle de vie dépend du client de base de données, de la configuration et du mode d’utilisation.
Examinez également la répartition de la charge. Plusieurs instances PHP peuvent respecter leurs limites locales tout en dépassant ensemble le quota de la base de données. La mise à l’échelle horizontale augmente la concurrence potentielle ; ce n’est pas une mesure d’atténuation sûre si le nombre total de connexions n’est pas recalculé.
Mesurer depuis les deux extrémités
Corrélez les métriques de l’application et de la base de données à l’aide d’horodatages. Dans PHP, enregistrez la durée des requêtes, les erreurs de connexion, les délais d’attente et le nombre de processus occupés. Dans la base de données, examinez le nombre de connexions actives et le maximum atteint, les refus, les requêtes en cours d’exécution, l’ancienneté des sessions et les attentes observées dans le moteur de base de données.
Évitez d’enregistrer les identifiants, les chaînes de connexion complètes ou des données sensibles issues des requêtes. Si le moteur permet d’identifier les sessions et leur état, utilisez ces informations pour distinguer une connexion inactive d’une requête active ou d’une transaction en attente. Comparez les journaux des deux côtés : un pic de connexions simultané à une forte occupation des processus PHP indique un problème de concurrence ; de nombreuses sessions anciennes ou des processus inactifs suggèrent une rétention ; quelques requêtes de longue durée peuvent expliquer la consommation progressive du quota.
L’instrumentation doit permettre de répondre à trois questions : combien de connexions sont utilisées, combien de temps elles durent et quelle activité les maintient occupées. Sans cette chronologie, modifier les limites ou activer les connexions persistantes introduit davantage de variables et rend la recherche de la cause plus difficile.
Évaluer les connexions persistantes et de longue durée
Une connexion persistante peut réduire le coût de l’ouverture répétée de connexions, en particulier lorsque l’environnement conserve les processus entre les requêtes. Cependant, une connexion qui reste associée à un processus peut également continuer à occuper une place même si aucune requête n’est en cours d’exécution. S’il y a de nombreux processus ou plusieurs instances, l’ensemble des connexions retenues peut atteindre la limite de la base de données.
Vérifiez le cycle de vie réel du processus et du pilote avant d’activer ou de désactiver ces connexions. Vérifiez comment la session est réutilisée et si l’application rétablit l’état attendu entre les requêtes, notamment les transactions, les variables de session ou la configuration propre à la connexion. Les connexions persistantes ne constituent pas un pool universel et ne garantissent pas une consommation moindre ; testez-les sous une charge représentative et observez le nombre maximal de connexions, la latence et l’état résiduel.
Atténuer le problème par étapes et sur la base de faits
- Limiter la concurrence. Ajustez le nombre de processus PHP ou le parallélisme des workers afin que la demande simultanée soit compatible avec le quota partagé. Cela réduit la pression, mais peut augmenter la file d’attente et la latence si la capacité reste inférieure à la demande soutenue.
- Libérer les ressources dès qu’elles ne sont plus nécessaires. Fermez explicitement les connexions si la bibliothèque et le mode d’exécution le permettent, et évitez de les conserver pendant des opérations sans rapport avec la base de données. Gardez à l’esprit que la fermeture d’une connexion persistante ne libère pas nécessairement la connexion physique du serveur : le résultat dépend du pilote et du cycle de vie du processus. Vérifiez les transactions qui restent ouvertes et les chemins d’erreur qui ne terminent pas correctement le nettoyage.
- Réduire la durée d’occupation. Analysez les requêtes lentes, les index, le volume des résultats et les transactions. Optimiser une opération qui retient une connexion longtemps peut réduire la demande simultanée sans relever la limite.
- Ne régler les limites qu’après avoir effectué des mesures. Augmenter le maximum peut être raisonnable si la base de données dispose encore d’une capacité CPU et mémoire suffisante et si le nouveau pire cas reste soutenable. Dans le cas contraire, cela permet à davantage de travail de s’accumuler et aggrave la saturation.
Appliquez une modification à la fois, consignez l’état précédent et définissez une condition de retour arrière. Si le système est déjà affecté, réduire temporairement la concurrence peut être plus sûr que de redémarrer tous les processus en même temps, ce qui risquerait de créer un nouveau pic de connexions.
Quand envisager un pool ou un proxy de connexions
Un pool ou un proxy peut réutiliser les connexions physiques et contrôler leur nombre à destination du moteur, ce qui est utile lorsqu’un grand nombre de processus applicatifs utilisent des connexions de courte durée. Cela ne supprime pas le travail simultané et n’accélère pas les requêtes ; cette solution ajoute une couche avec sa propre capacité, ses files d’attente, ses limites et ses modes de fonctionnement.
Avant de l’adopter, vérifiez sa compatibilité avec le moteur, le pilote PHP, l’authentification, l’utilisation des transactions et l’état de session. Examinez la gestion des connexions longues, des reconnexions et des défaillances du proxy, et définissez des métriques et des procédures d’exploitation. Validez la solution à l’aide de tests représentatifs de la concurrence réelle : une configuration qui fonctionne en développement peut se comporter différemment sous pression.
Préparer le rétablissement et éviter les récidives
Configurez des alertes lorsque le nombre de connexions approche de la limite, en cas de refus, de durée excessive des requêtes ou de saturation des processus PHP. Ajoutez un test de charge représentatif incluant les instances, les tâches en arrière-plan et les autres consommateurs ; vérifiez le pire cas, pas seulement la moyenne. Maintenez une procédure opérationnelle précisant quoi mesurer, comment limiter la concurrence, qui peut modifier le quota et à quel moment revenir en arrière.
Après le rétablissement du service, examinez la séquence qui a précédé l’incident : variations du trafic, déploiements, nouvelles requêtes, augmentation du nombre de processus ou défauts de nettoyage. L’objectif est d’établir un lien de cause à effet à partir des données. Si les métriques révèlent des connexions retenues, corrigez leur cycle de vie ; si la durée des requêtes est le facteur dominant, optimisez-les ; si la concurrence légitime dépasse la capacité, dimensionnez le système et limitez-la à l’aide d’un budget de connexions explicite.
