Il y a quelques semaines, j'ai eu un différend avec le développeur qui avait travaillé sur le développement du back-office du site Internet de l'agence que je dirige.
Depuis samedi, comme par hasard (même peut-être est-ce seulement un hasard), toutes les pages JPS du site affichent une belle erreur HTTP Status 500 (le site est sur Apache Tomcat), ce qui est plutôt dramatique pour le "sérieux" de ma société.
Quand j'essaie de me connecter à ma base SQL pour savoir ce qui se passe, voilà ce qui s'affiche :
phpMyAdmin - error
#1226 - User 'blabla' has exceeded the 'max_connections' resource (current value: 50)
Le service technique de mon herbergeur althosting m'a alors répondu ceci :
1) Un de vos scripts semble se connecter a la base mysql mais ne se referme pas nous avons plusieurs centaines de connection de votre utilisateur en mode sleep, merci de remedié à ce problème.
2) Il semble qu'il y ai quelque part sur votre site une fonction qui se connecte en permanence sur le serveur sans jamais se deconnecter (les requetes restent en mode sleep) d'ou l'erreur que vous obtenez.
3) Vous n'etes pas en mesure de vous connecter car il y a trop de connection actuellement de votre compte sur le serveur sql, il semble que ce soit votre site qui crée ses connections , sans doute une requete sql non fermé, nous avons reseter votre nombre de connection votre site devrait donc remarcher mais il faudrait pouvoir identifier la requete qui pose problème.
Effectivement, depuis qu'ils ont "reseté" la chose, ça marche, mais la liste des processus de la base SQL s'allonge minute après minute :
Je suis légèrement nul en informatique (je sais programmé en C et HTML, mais rien de plus), mais savez-vous ce qui se passe et ce que je peux faire pour réparer le problème ?
A mon avis, c'est un problème de conception (les connexions ne sont pas refermées) et peut-être qu'un script est appelé un peu trop fréquemment.
Il faut s'orienter vers les stats d'utilisation web pour voir quel script est en cause et quelle IP l'appelle fréquemment (pour la bannir le cas échéant).
Vérifies bien les logs pour voir si un fichier particulier n'est pas appelé fréquemment, quitte à demander à althosting s'ils peuvent jeter un oeil sur les logs apaches (ils sont habituellement réactifs et prêt à rendre service)
La série noire continue, puisque lorsque j'envoie un fichier sur le serveur via mon FTP, ça me met maintenant :
"Requested action not taken (e.g., file or directory not found, no access)"
L’hébergeur a résolu provisoirement le problème. Le développeur de la SSII qui avait pris en charge le développement d’une partie de l’application (puis j’avais fait appel à un deuxième développeur pour terminer l’application) m’a également répondu.
Vous trouverez ci-dessous leurs réponses.
Si cela vous donne des idées de solutions, n’hésitez pas ! Je vous en remercie d’avance ! :-)
REPONSE DE L’HEBERGEUR :
Nous avons mis en place une solution qui fait que les connections inactive sont coupé au bout de 30mn pour réduire le nombre de connection venant de votre site, cela dis si le nombre de visite augmente le problème risque de se reproduire, si vous avez le moyen de savoir comment fonctionne vos requetes mysql pour les fermer ca sera utile sinon on restera comme ca pour le moment
REPONSE DU DEVELOPPEUR :
J'ai jeté un coup d'oeil sur les process mysql, et il semble qu'il y ait
effectivement création d'un nouveau process toutes les 90 seconds environ.
Les process disparaissent au bout d'une demi-heure, c'est probablement
le timeout défini dans mysql pour une connexion inactive. Si ce taux
de naissance et de mort reste contant, le nombre de process devrait etre
d'une vingtaine environ, en permanence. Mais si la création de process
est plus rapide on peut donc arriver à la limite des 50 process.
J'ignore ce qui génère ces process. Je n'ai pas les autorisations pour faire
des commandes systèmes sur la machine et investiguer davantage. Est-ce
que cette période de 90 secondes vous dit quelque chose? Avez-vous convenu
avec l'autre développeur d'un système de surveillance ou d'interrogation
régulière de la base? Sinon il est possible qu'un utilisateur ait installé
un système de ce genre. Avez-vous par exemple la possiblité de consulter
les statistiques d'accès à vos pages, et vérifier si quelqu'un ne fait
pas login régulièrement ?
Vous allez répondre sur un sujet resté inactif pendant plus de 6 mois. Assurez-vous d'apporter des éléments nouveaux à la discussion avant de poursuivre.