Error establishing a database connection côté visiteur, et dans les journaux du serveur MySQL, une ligne bien plus explicite : Too many connections. Ce message est apparu simultanément sur quatre sites différents hébergés sur le même serveur mutualisé, un mardi en milieu de journée, sans qu’aucun déploiement récent n’ait eu lieu sur l’un d’entre eux.
Symptôme
Plusieurs sites du même serveur deviennent indisponibles en même temps, tous affichant une erreur de connexion à la base de données, alors que le serveur lui-même répond normalement aux autres requêtes (fichiers statiques, pages en cache). Le journal MySQL confirme :
2022-02-24 13:12:48 47 [Warning] Aborted connection 47 to db: 'unconnected' user: 'unauthenticated'
ERROR 1040 (HY000): Too many connections
Diagnostic : identifier qui consomme les connexions
La valeur par défaut de max_connections sur une installation MySQL standard est de 151. Sur un serveur mutualisé hébergeant plusieurs dizaines de sites WordPress, ce plafond peut être atteint rapidement si un ou plusieurs sites laissent des connexions ouvertes plus longtemps que nécessaire. La première étape consiste à identifier la source de la consommation :
SHOW PROCESSLIST;
Cette commande affiche l’ensemble des connexions actives, avec la base de données concernée, l’utilisateur et l’état de chaque connexion (Sleep, Query, Locked). Sur l’incident en question, un site particulier apparaissait avec plus de quatre-vingts connexions à l’état Sleep, largement au-dessus du nombre de visiteurs simultanés réels sur ce site.
Trouver la cause précise
L’investigation a révélé une extension tierce récemment installée sur ce site, qui ouvrait une connexion persistante à la base de données pour chaque appel à une tâche planifiée WordPress (wp-cron), sans jamais la refermer explicitement. Sur un site à fort trafic, avec des tâches planifiées déclenchées fréquemment, ces connexions abandonnées s’accumulaient jusqu’à saturer le pool partagé par l’ensemble du serveur.
Correctif immédiat
- Identifier et désactiver temporairement l’extension responsable pour libérer immédiatement les connexions bloquées :
wp plugin deactivate extension-suspecte. - Redémarrer le service MySQL si les connexions abandonnées ne se libèrent pas d’elles-mêmes après la désactivation, en dernier recours seulement, car cela coupe toutes les connexions en cours sur le serveur entier.
- Vérifier que
wp_cronne s’exécute pas en boucle rapprochée sur ce site à cause d’un réglage de fréquence trop agressif introduit par la même extension.
Correctif structurel
Une fois l’incident résorbé, deux ajustements ont été mis en place pour prévenir sa récurrence :
- Une augmentation raisonnée de
max_connections, après avoir vérifié que la mémoire disponible du serveur pouvait absorber ce plafond plus élevé sans provoquer d’autres problèmes. - Un délai d’inactivité plus court pour les connexions en veille, via
wait_timeout, afin que MySQL libère automatiquement les connexions abandonnées après un délai raisonnable plutôt que de les conserver ouvertes indéfiniment.
[mysqld]
max_connections = 300
wait_timeout = 120
Prévention à l’échelle du parc
Sur un serveur mutualisé hébergeant de nombreux sites, un tableau de bord de suivi du nombre de connexions par base de données, mis à jour toutes les minutes, permet de repérer une dérive avant qu’elle n’atteigne le seuil critique, plutôt que de découvrir l’incident au moment où plusieurs sites tombent simultanément.
Une extension qui « fonctionne » en apparence peut consommer des ressources invisibles jusqu’à ce que le plafond soit atteint d’un coup.
En résumé
« Too many connections » sur une base mutualisée pointe presque toujours vers une source de consommation anormale plutôt que vers un plafond simplement trop bas. Augmenter max_connections sans identifier la cause réelle ne fait que repousser l’incident suivant, potentiellement plus difficile à diagnostiquer une fois plusieurs sites concernés simultanément.
