Bonjour à tous,
 
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 :
 
ID      Utilisateur   Serveur   Base de don. Commande  Durée
16743  blabla      localhost:2611 blabla     Sleep 1550
16744  blabla      localhost:4823 blabla     Sleep 1523
16746  blabla      localhost:4851 blabla     Sleep 1425
16748  blabla      localhost:1917 blabla     Sleep 1346
16749  blabla      localhost:3083 blabla     Sleep 1308
16753  blabla      localhost:3246 blabla     Sleep 1259
16755  blabla      localhost:3176 blabla     Sleep 1242
16760  blabla      localhost:2721 blabla     Sleep 1180
16815  blabla      localhost:1346 blabla     Sleep 956
16825  blabla      localhost:1955 blabla     Sleep 904
16842  blabla      localhost:1237 blabla     Sleep 674
16844  blabla      localhost:2410 blabla     Sleep 561
16845  blabla      localhost:1358 blabla     Sleep 496
16889  blabla      localhost:4893 blabla     Sleep 386
16903  blabla      localhost:4442 blabla     Sleep 194
16919  blabla      localhost:2445 blabla     Sleep 86
 
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 ?
 
Mille mercis ! :-)

bonjour
le soucis c'est qu'il faut trouver sur ton site, la page qui se connecte à la base de données, et aussi les pages qui appellent la connection à la base. Car une fois la connection établie, il faut la refermer derrière... Sinon tu te retrouves avec 360000 connections ouvertes et à un moment ca bloque...

+1; ça ressemble à des oublis de fermeture de connexions. Pb isolé OU mauvais design général.
 

Ca, pour un service commercial, ça ne fait pas sérieux.    

Ouais, c'est vrai que je suis perdu. En principe, personne n'a touché au code (à part le présumé "pirate" ?).
 
Dois-je chercher sur les pages .jsp ? Ou ailleurs ?

Beh, engage quelqu'un d'autre?
 
Par nature, il faut chercher 'partout' : dans les JSP si on a codé à la petite semaine, ailleurs si on s'y est pris plus proprement. "En principe", les accès DB sont bien rangés au sein d'une persistence layer bien identifiée et séparée du reste. Sauf si on a travaillé comme un sauvage (pas forcément péjoratif : si 3-4 pages temporaires, pas la peine de faire du multi-tier non plus).
 
Un pirate qui s'amuserait à supprimer les releases de connexions, lol. :-D
 
Si tu as un version control (CVS, SVN, ...), tu peux en apprendre bcp.

En fait, le dev n'est pas un pirate, c'est juste un goret
 
Z'avez bien fait de le foutre à la porte.
 
Il avait qu'à venir ici, on lui aurait expliqué qu'il fallait toujours fermer proprement les cnx en fin de page.

D'un autre côté, un hébergeur qui plante la base à cause de cnx mal fermée, c'est évidement des nains compétents.
Mais alors des nains chez les nains hein...
Le timeout et le autoclose sont des fonctions de base dans J2EE et le SGBD.
Ca veut dire que les boulets (ha, nan, des boulets nains c'est des billes) ont installé la plateforme en mode standard, sans rien toucher de plus.
 
Maintenant que le dev nain compétent a été viré, va falloir aussi penser à passer chez un vrai hébergeur.

ct toi le dev ?

Aiaiaillee. Non, le développeur était un ami que j'ai envoyé baladé. C'est depuis que le problème est apparu.
 
Merci, mais où puis-je trouve ces fameux logs ?
 
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)"
 

as tu un accès ssh sur ce serveur ?

Avant d'accuser le dev d'être mal intentionné :
1/ change le mdp d'accès chez l'hébergeur (on sait jamais après tout)
2/ fait corriger tes scripts de façon à ce qu'ils ferment correctement les cnx à la base
3/ fout une branlée à ton hébergeur : pour le coup de l'erreur FTP, soit tu sais pas ce que tu fais, et fait une erreur, soit l'hébergeur a foutu la merde, en tout cas, ça ne peut pas être une attaque extérieure... à moins que l'hébergeur soit une pure passoire

dans tous les cas, vu les erreurs, je dirais :
 
1/ soit c'est une coincidence que ça merde depuis son départ (très certainement)
2/ soit c'est en effet volontaire
 
mais dans les deux cas, c'est 1 heure de boulot à tout péter pour corriger les pages, y'a rien de grave là-dedans. donc trouve un autre pote en vitesse, ou fait ton méa-culpa et rappelle-le (ceci dit, que ce soit le 1/ ou le 2/, il n'a pas l'air très compétent ni très honête, c'est peut-être pas une bonne idée de lui faire corriger).
 
en tout cas, rien ne peut prouver qu'il s'agit d'un act volontaire. et dans tous les cas, les domages sont minimes. il s'agit d'un petit bug extrêment courant, et j'ai peine à croire que l'hébergeur soit suffisament mal paramétré pour que ça plante. j'ai déjà fait ce genre de conneries, et ça a mis des mois avant de planter le serveur (arriver à quelques dizaines de milliers de connections mal fermées, ça fini par foutre en l'air le serveur d'application, mais le SGBD s'en bat les glawis normalement...)

Salut à tous,
 
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 ?