erreur trop de connections?????????

passion · 7 Septembre 2006

Bonjour,
Je suis entrain d'agencer mon nouveau site et il me refuse toute connexion à mes BD...j'ai que des erreurs Mysql!!!!
Lorsque je souhaite vérifier mon phpadmin......j'ai un message en rouge
"#1040 - Trop de connections"

Que puis-je faire????

Merci ...je suis dans la mer**!!

kool76 · 7 Septembre 2006

Oulala, en effet je viens d'aller voir, c'est pas beau du tout... Tu devrais vérifier la connection à ta base ainsi que la fermeture de la connexion. Une seule connexion au début du fichier suffit ainsi qu'une seule fermeture. Car à ce que j'ai vu fait plusieurs ouverture et fermeture sur la même page.

passion · 7 Septembre 2006

merci de ton aide mais en faite, j'ai suivi ton conseil ouverture en début et fermeture une fois terminé mais rien!!!!!
toujours pareil!!

achtungbaby · 7 Septembre 2006

Tu es sur quel type d'hébergement ?

kool76 · 7 Septembre 2006

Etrange, peut tu nous montrer ton code ? Sans les identifiants pour la connexion évidement hein

passion · 7 Septembre 2006

Je suis sur un hébergement mutualisé et voici les caractèristiques:

Formule: business Plan
Espace Web: 250Mo
Espace Mails: 250Mo
Nbre Emails: 250
Base Mysql: oui
Base Access: oui
Nbre de hit max/j: 200000
Transfert max/j: 320Mo

et pour ce qui est du code, je peux vous le montrer c'est pas un prob..mais le prob est ailleurs...il a trés bien marché jusqu'à là...et puis d'un seul coup en vérifiant machinalement ma page index....paf!

kool76 · 7 Septembre 2006

Alors là plus qu'étrange, postes un ticket au support de ton hébergeur, ça vient surement d'eux, je vois pas sinon...

finstreet · 7 Septembre 2006

si c un serveur mutu, ce pourrait pas etre le mysql du mutu qui est tout simplement tombé ?

passion · 7 Septembre 2006

Je vous remercie pour votre aide ...je les ai contacté mais bon...vu l'heure je pourrais me brosser pour avoir une réponse rapide!!

kool76 · 7 Septembre 2006

finstreet a dit:
si c un serveur mutu, ce pourrait pas etre le mysql du mutu qui est tout simplement tombé ?

Tout à fait possible, sûrement la réponse la plus probable :?

passion · 7 Septembre 2006

parce que là, étant en pleine période d'indexation, j'ai pas envie que ça me crée de nombreuses erreurs connaissant la fébrilité des bots!!
car il me manquera les contenus de mes pages!!
J'ai fait de la réécriture pour un total final de 6 000 pages indexables...j'en suis à 115
Pensez-vous que cela pourrait venir de mon hébergement trop faible pour supporter ce site???

gastro · 7 Septembre 2006

Bon, tu devrais commencer par masquer ces messages avec:
error_reporting(0);
en haut de ton fichier, histoire de sauver les meubles en attendant et de ne pas exposer la structure de ton site.

Pour ce message d'erreur, c'est que tu as trop de connexions simultanées au serveur sql. En mutu, tu as souvent droit à 3 connexions simultanées (demande à ton hébergeur). C'est largement suffisant pour un site en php jusqu'à quelques milliers de visiteurs par jour.

Donc le problème c'est soit :
- Hausse de trafic, le serveur mysql ne suit plus
- Site trop gourmand (requetes lourdes, pas d'utilisation d'index, des select qui renvoie trop d'infos inutiles etc)
- Utilisation de connexions persistantes (à éviter absolument)

Mais si ton trafic est stable et que tu n'as pas fait de modifs récement, c'est peut-être dû à l'hébergeur.

Sinon, vas voir dans phpmyadmin et clique sur "Afficher les processus" en page d'accueil, voir si tu as un truc en cours avec une durée énorme (tu peux le supprimer voir si ça régle le pb et si ça revient)

passion · 8 Septembre 2006

Je te remecie pour ces précisions gastro
J'ai retiré les messages d'erreurs sur la page index mais en faite je faisait 3 COUNT pour récupérer le nb de mes annonces de mes 3 tables...de là, je l'ai réduit à une seule connection et je m'assure toujours de fermer ma connection et mon script était en fonction depuis 3 ou 4 semaines déjà!!!.
C'est de ce soir qu'il plante!!!
en faite, j'était entrain de développer un fil rss2.0 pour mon site aprés l'avoir chargé sur mon FTP et actualiser mon index....voilà, le résultat!!
Donc je n'ai pas touché à la structure du site auparavant!!

P.S:je ne peux absolument pas me connecter à mon MYSQL

biscuit · 8 Septembre 2006

kool76 a dit:
Oulala, en effet je viens d'aller voir, c'est pas beau du tout... Tu devrais vérifier la connection à ta base ainsi que la fermeture de la connexion. Une seule connexion au début du fichier suffit ainsi qu'une seule fermeture. Car à ce que j'ai vu fait plusieurs ouverture et fermeture sur la même page.

Je rebondis... Il me semble avoir lu que justement il ne fallait pas ouvrir une connection en début de page et la refermer à la fin... qu'il vaut mieux ouvrir et fermer plusieurs fois afin de garder la connection à la base ouverte le moins longtemps possible. Quelqu'un à plus d'infos ?

e-kiwi · 8 Septembre 2006

>> Il me semble avoir lu que justement il ne fallait pas
>> ouvrir une connection en début de page et la refermer à
>> la fin... qu'il vaut mieux ouvrir et fermer plusieurs fois
>> afin de garder la connection à la base ouverte le moins
>> longtemps possible

apres de longues conversations avec mon hebergeur, la conclusion est qu'il faut ouvrir la connection juste avant la requete, et la fermer juste apres, et la ré-ouvrir avant la prochaine requete. effectivement cela permet d'accueillir plus de visiteurs sur son site en même temps (Source Nfrance Conseil)

thierry8 · 8 Septembre 2006

e-kiwi désolé de contredire ton hébergeur (Source Nfrance Conseil), mais pour moi il se plante:

il vaut mieux:

- script php (si besoin avant)
- ouvrir une connexion mysql
- traiter toutes les requêtes
- fermer la connexion mysql
- script php (si besoin après)

il ne faut en aucun cas ouvrir une connexion pour quelques requêtes, puis refermer pour ouvrir quelques millisecondes plus tard...c'est completement incensé, sachant que la connexion et la fermeture prennent du temps:

de l'ordre des 0.025 s. / 0.03s. en fonction du serveur

autant de temps perdu à chacune de tes connexions mysql...alors que cela peut être évité en faisant toutes les requêtes en une fois..
(donc moins de temps de connexion au serveur mysql, donc moins de chance de tomber sur un "Trop de connexion")

biscuit · 8 Septembre 2006

J'ai retrouvé où j'avais lu ça: FAQ infomaniak. Ils préconisent également de ne pas garder la connexion à la base ouverte du début à la fin du script.

Par contre il est évident qu'une fois la connexion ouverte il faut l'utiliser au mieux, donc faire un max de requêtes... Mais dans le cas où des requêtes doivent être faites plus loin dans le script, il faut fermer et rouvrir.

passion · 8 Septembre 2006

Ok je commence à comprendre

cela ne vient pas de moi mais concours de circonstance lorsque je travaillais sur mon site....je viens de regarder mes stats ce matin pour connaître l'état de ma bande passante, BD etc.....et voilà, le message que je reçoit:

Bonjour,
Afin de vous fournir un meilleur service, votre serveur est actuellement en cours de maintenance.
Merci de votre compréhenssion.

j'espère que leur maintenance va être rapide......mais cela va me servir de leçon dans le sens où j'ai envie de changer d'hébergement pour le mettre sur un dédié et ne plus avoir ce genre de prob!!!
J'en ai un qui est sur 1&1 et qui fonctionne parfaitement bien en dédié!

kool76 · 8 Septembre 2006

biscuit a dit:
J'ai retrouvé où j'avais lu ça: FAQ infomaniak. Ils préconisent également de ne pas garder la connexion à la base ouverte du début à la fin du script.

Par contre il est évident qu'une fois la connexion ouverte il faut l'utiliser au mieux, donc faire un max de requêtes... Mais dans le cas où des requêtes doivent être faites plus loin dans le script, il faut fermer et rouvrir.

Tout dépend des limitations de l'hébergement et de l'utilisation dans le script, normalement si c'est codé proprement les connexions à la base ne s'étalent pas sur toute la page.

biscuit · 8 Septembre 2006

Pas d'accord, quelques soient les limites de l'hébergement, l'optimisation du code est importante.

kool76 · 8 Septembre 2006

biscuit a dit:
Pas d'accord, quelques soient les limites de l'hébergement, l'optimisation du code est importante.

Evidement :lol:

finstreet · 8 Septembre 2006

et hop je rebondis... c obligé de fermer la connexion ? c pas fait automatiquement ?

en fait (mais vous foutez pas de moi

, perso j'ouvre tout en haut dans un fichier qui se trouve avant le header... ensuite j'ai le header... ensuite j'ai une page... et ensuite j'ai le footer

y'a des requêtes un peu partout... elles sont pas groupées sur 10 lignes

vaut mieux tout regrouper et définir des variables au tout début ... fermer la base et ensuite afficher les variables ?

thierry8 · 8 Septembre 2006

finstreet a dit:
vaut mieux tout regrouper et définir des variables au tout début ... fermer la base et ensuite afficher les variables ?

très clairement: oui

ce que tu as décrit est le pire des cas et surtout à éviter.

Good Luck pour les modifs

finstreet · 8 Septembre 2006

thierry8 a dit:
finstreet a dit:

vaut mieux tout regrouper et définir des variables au tout début ... fermer la base et ensuite afficher les variables ?

Cliquez pour agrandir...

très clairement: oui

ce que tu as décrit est le pire des cas et surtout à éviter.

Good Luck pour les modifs

m'enfin ce n'était pas ma base dont je parlais

et pour dire à mon ami comment faire... comment vous faites ca quand y'a des boucles ? vous balancez pas un tableau multi quand meme ?

rhoooooooooo tain c'est trop la mort... une corde vite !!!

thierry8 · 8 Septembre 2006

j'ai pas bien compris le problème de ton amis ?

:arrow: je comprends mieux par l'exemple.

finstreet · 8 Septembre 2006

thierry8 a dit:
j'ai pas bien compris le problème de ton amis ?

:arrow: je comprends mieux par l'exemple.

oui mon ami est un gros neuneu... j'ai passé plusieurs heures à lui expliquer mais c'est une vraie burne... déjà qu'il est mono testiculaire

Bref, si j'ai quelques variables sur une page. Genre titre et contenu et pis quelques autres trucs... c'est affiché sur toute la page

Si je comprends bien, on ouvre la base. On fait toutes les requetes. On balance tout dans des variables. On clot la connection et ensuite on affiche les variables dans le corps.

Mais

si jamais on a besoin de plusieurs lignes sur une table ... genre 5 actus provenant de la meme table

Tu stockes aussi les résultats dans des variables, tu clos la connection et ensuite tu affiches ? ca fait pas des centaines de variables ce truc ?

merci d'etre très clair... mon ami est mono neuronal en + d'etre mono testiculaire

thierry8 · 8 Septembre 2006

et bien il suffit de conserver la variable de la requête:

#EXEMPLE#

- code php (si nécessaire)

- ouverture mysql

- $requete_1 = mysql_query(ma_requette); // 1 enregistrement

- $requete_2 = mysql_query(ma_requette); // 1 enregistrement

- $requete_3 = mysql_query(ma_requette); // plusieurs enregistrements

- $requete_4 = mysql_query(ma_requette); // 1 enregistrement nécessaire à la requête 5

$val_rq_4 = mysql_fetch_assoc($requete_4 );
mysql_free_result($requete_4);
$id = $val_rq_4 ['nom_du_champ_1']

- $requete_5 = mysql_query(ma_requette avec $id); // 1 enregistrement

- fermeture mysql

$val_rq_1 = mysql_fetch_assoc($requete_1);
mysql_free_result($requete_1);
echo $val_rq_1['nom_du_champ_1'].$val_rq_1['nom_du_champ_2'];

$val_rq_2 = mysql_fetch_assoc($requete_2);
mysql_free_result($requete_2);
echo $val_rq_2['nom_du_champ_1'].$val_rq_2['nom_du_champ_2'];

while($val_rq_3 = mysql_fetch_assoc($requete_3))
echo $val_rq_3['nom_du_champ_1'].$val_rq_3['nom_du_champ_2'];

mysql_free_result($requete_3);

$val_rq_5 = mysql_fetch_assoc($requete_5);
mysql_free_result($requete_5);
echo $val_rq_5['nom_du_champ_1'];

mysql_free_result($requete_5);

- autre code php (si nécessaire)

#FINEXEMPLE#

biscuit · 8 Septembre 2006

j'espère que ton pote n'es pas mono-main avec un mono-doigt parce qu'apparemment va y avoir du code à changer...

Dans la mesure du possible, faut regrouper les requêtes et les stocker. Dans le cas de boucles, ça peut faire des tableaux assez lourds, donc c'est peut-être pas la meilleur solution... donc:

1 - ouverture mysql et un max de requetes
2 - mysql_free_result()
3 - mysql_close()
4 - plein de choses ici
5 - re-ouverture mysql et re-requête avec la boucle
6 - re-mysql_free_result()
7 - re-mysql_close()
...

En fait rien ne te force à grouper toutes les requêtes au même endroit... et là c'est l'avis d'un simple biscuit (même pas au beurre) : faut trouver l'équilibre entre le stockage et les requêtes directs. L'important c'est de ne pas garder de connexion ouverte sans en avoir besoin...

-- EDIT: me suis fais gauffré par thierry8

finstreet · 8 Septembre 2006

ahhhhhhhhhhhhhhhhhhhh.... ah oui là c clair tu as mieux expliqué que moi je lui avais expliqué

et donc l'avantage principal de cela (oui c parce que con comme il est, il va me demander)... donc l'avantage c'est d'avoir une durée d'accès à la base très court, le temps de faire les requêtes... comme ca si à ce moment là, le serveur rame... la durée de "construction" de la page dans son ensemble ne vas pas impacter toute la durée de connection à la base... donc en gros plutot que ce soit ouvert 0.012 par exemple... c ouvert que 0.006 et moins c ouvert longtemps, mieux c'est... c'est l'idée ?

thierry8 · 8 Septembre 2006

biscuit a dit:
1 - ouverture mysql et un max de requetes
2 - mysql_free_result()
3 - mysql_close()
4 - plein de choses ici
5 - re-ouverture mysql et re-requête
6 - re-mysql_free_result()
7 - re-mysql_close()

Attention mysql_free_result() s'emploit après avoir récupéré sous forme de tableau la ressource envoyée par la requête pas avant.

Il faut donc d'abord fermer la connexion mysql et ensuite seulement traiter les données (cf. exemple ci-dessus).

finstreet · 8 Septembre 2006

biscuit a dit:
-- EDIT: me suis fais gauffré par thierry8

voui mais ca me permet d'avoir deux visions différentes pour mon ami manchot... oui l'est manchot aussi et comme tout le monde le sait... pas de bras, pas de ... bol

thierry8 · 8 Septembre 2006

finstreet a dit:
et donc l'avantage principal de cela (oui c parce que con comme il est, il va me demander)... donc l'avantage c'est d'avoir une durée d'accès à la base très court, le temps de faire les requêtes... comme ca si à ce moment là, le serveur rame... la durée de "construction" de la page dans son ensemble ne vas pas impacter toute la durée de connection à la base... donc en gros plutot que ce soit ouvert 0.012 par exemple... c ouvert que 0.006 et moins c ouvert longtemps, mieux c'est... c'est l'idée ?

oui un gain de temps non négligeable.
si tout le monde faisait ainsi sur un serveur dédié tu pourrais mettre le double de trafic.
(<- ça permet de mieux voir l'impact ainsi, car cela peut s'embler ridicule, mais pas du tout)

de plus tes pages seronts beaucoup plus lisibles.
en cas de modification tu sais ou sont tes requêtes, etc..

autre avantage (énorme) lorsque l'on utilise encore une gestion de cache par fichiers..
mais ça c'est encore une autre histoire (intéressante du moins) !

biscuit · 8 Septembre 2006

thierry8 a dit:
Attention mysql_free_result() s'emploit après avoir récupéré sous forme de tableau la ressource envoyée par la requête pas avant.

exact... donc

1 - ouverture
2 - requete
3 - stockage
4 - mysql_free_result
5 - requete 2
6 - mysql_free_result
7 - ...
8 - fermeture

gastro · 8 Septembre 2006

Sur mes premiers sites pas optimisés question requetes, impossible de regrouper toutes les requetes (trop de boulot). J'ai donc optimisé uniquement les requetes les plus lourdes et utilisé jpcache pour le cache fichier.

Ca m'a permis de rester en mutu près de 6 mois de plus alors que mon trafic avait doublé.

thierry8 · 8 Septembre 2006

@biscuit

regarde l'exemple que j'ai donné.
il est préférable de fermer la connexion avant et de s'occuper après des données sous forme de ressource pour les passer en tabelau associatif (ou non).

finstreet · 8 Septembre 2006

j'ai... enfin mon ami... utilise un système de cache ... qcache je crois ... c dans mysql

donc mon ami a du boulot sur la planche si j'ai bien compris... et il y aurait pas un moyen pour mon ami de savoir combien i la gagné... genre ca donne le temps total de construction... parce que sur phpmyadmin, on peut juste voir le temps d'une requete, pas un temps global d'une page

en tout ca très très grand merci de la part de mon ami

thierry8 · 8 Septembre 2006

avant de faire quelque modification que ce soit:

- ben c'est possible tu prend le temps au début du script (au moment de la connexion mysql) puis tu prend le temps à la fin (à la fermeture mysql).

- tu fais temps fin - temps début = temps exécution actuel (pour les requêtes + le script)

- tu test plusieurs fois (sur une ou plusieurs pages), tu note les différents temps obtenu.

ensuite tu fais les lourdes modifications et quand tout fonctionne:

rebelote:
- tu prend le temps au début des requêtes (au moment de la connexion mysql) puis tu prend le temps à la fin (à la fermeture mysql).

- tu fais temps fin - temps début = temps exécution actuel (pour les requêtes uniquement)

:arrow: tu test plusieurs fois (sur une ou plusieurs pages), tu note les différents temps obtenu et tu compare..

:arrow: tu vera la différence de temps gagné entre les deux..

biscuit · 8 Septembre 2006

finstreet a dit:
et il y aurait pas un moyen pour mon ami de savoir combien i la gagné... genre ca donne le temps total de construction...

au début de ta page tu fais un $start = microtime(); à la fin $end = microtime() et y'a plus qu'à faire la différence

-EDIT j'en ai marre d'être Suisse! J'réponds plus lentement et moins complétement en plus ! Damned

biscuit · 8 Septembre 2006

thierry8 a dit:
@biscuit

regarde l'exemple que j'ai donné.
il est préférable de fermer la connexion avant et de s'occuper après des données sous forme de ressource pour les passer en tabelau associatif (ou non).

On est d'accord, ton exemple est très bon.
Mais dans le cas de requêtes "lourdes", c'est préférable de libérer la mémoire allouée à la requête non ?

finstreet · 8 Septembre 2006

je connaissais pas le micro time

mais arretez de dire "tu" c pour mon ami

bon vais essayer de lui modifier quelques pages pour voir... il est manchot alors il est long

marchi pour tout

thierry8 · 8 Septembre 2006

biscuit a dit:
thierry8 a dit:

@biscuit

regarde l'exemple que j'ai donné.
il est préférable de fermer la connexion avant et de s'occuper après des données sous forme de ressource pour les passer en tabelau associatif (ou non).

Cliquez pour agrandir...

On est d'accord, ton exemple est très bon.
Mais dans le cas de requêtes "lourdes", c'est préférable de libérer la mémoire allouée à la requête non ?

et bien non cela n'y change rien de conserver une ressource (résultat de la requête directe) plutôt que de conserver une variable en tableau associatif contenant les valeurs. ça aura plus ou moins le même poids, sauf que tu pénalise en temps la connexion à mysql étant donné que tu rajoute tu traitement php qui peut se faire en dehors.

- donc tu garde la ressource
- tu ferme mysql
- tu récupère sous forme de tableau associatif
- tu libère la ressource
- tu travail sur ton tableau associatif pour en faire ce que tu feux

edit: je rajoute dans l'exemple la libération ressource

edit: 2 en plus si tu libère la ressource lors de la connexion mysql et que tu as plusieurs enregistrements tu serai obligé de faire une boucle while pour tout mettre dans un tableau. grosse perte de temps encore..

il y a juste dans le cas de la requête_4 et requête_5 que ce n'est pas évitable. lorsqu'une requête à besoin d'un ou plusieurs résultat(s) d'une autre requête.

biscuit · 8 Septembre 2006

... j'aime bien les manchots moi... (sinon faut dire que je n'aurai pas répondu à ces questions :lol

microtime() c'est comme time() sauf que
- microtime() = temps UNIX en millisecondes
- time() = temps UNIX en secondes

finstreet · 8 Septembre 2006

biscuit a dit:
... j'aime bien les manchots moi... (sinon faut dire que je n'aurai pas répondu à ces questions :lol

j'ai dis les manchots , pas les gros blaireaux mdr

biscuit · 8 Septembre 2006

thierry8 a dit:
- donc tu garde la ressource
- tu ferme mysql
- tu récupère sous forme de tableau associatif
- tu libère la ressource
- tu travail sur ton tableau associatif pour en faire ce que tu feux

ok...

mais libèrer la ressource après avoir fermé la connexion, ça sert plus à grand chose... d'ailleurs je crois même que cela cré un erreur du genre "$sql is not a valid mysql result" (enfin un truc comme ça) ?

thierry8 · 8 Septembre 2006

biscuit a dit:
thierry8 a dit:

- donc tu garde la ressource
- tu ferme mysql
- tu récupère sous forme de tableau associatif
- tu libère la ressource
- tu travail sur ton tableau associatif pour en faire ce que tu feux

edit: je rajoute dans l'exemple la libération ressource

edit: 2 en plus si tu libère la ressource lors de la connexion mysql et que tu as plusieurs enregistrements tu serai obligé de faire une boucle while pour tout mettre dans un tableau. grosse perte de temps encore..

il y a juste dans le cas de la requête_4 et requête_5 que ce n'est pas évitable. lorsqu'une requête à besoin d'un ou plusieurs résultat(s) d'une autre requête.

Cliquez pour agrandir...

ok...

mais libèrer la ressource après avoir fermé la connexion, ça sert plus à grand chose... d'ailleurs je crois même que cela cré un erreur du genre "$sql is not a valid mysql result" (enfin un truc comme ça) ?

non aucune erreur.
et si ça sert à libérer de l'espace mémoire..

source php:
mysql_free_result() libère toute la mémoire et les ressources utilisées par la ressource de résultat de la variable.

finstreet · 8 Septembre 2006

bon ben j'ai fais mes premiers tests e effectivement suis arrivé... mais bon y'a eu du boulot à passer de 0,020-0,025 à 0,011-0,015

bo npar contre c assez chiant à faire c clair... mais sur certaines pages je crois que ca peut avoir un très très bon impact

en fait le truc c de faire le close juste après la dernière requete... et donc le but est de remonter au maximum la dernière requete... dans certains cas ca remonte pas très haut mais dans d'autres si

en attendant j'ai planté le close en haut du footer... ca gagne pas grand chose du tout... mais ca m'a pris 2 mns à faire

en tout cas merci... merci de m'avoir pourri ma prochaine semaine because vais etre obligé de retravailler chaque page... bande de ù^* $%¨§§ mdr

thierry8 · 8 Septembre 2006

de rien, c'est toujours un plaisir

:wink:

Bonne chance +

bordas_69 · 12 Septembre 2006

Bon, ben j'ai également du boulot... J'ai déjà modif pas mal de chose dans l'annuaire que je suis en train de faire... J'ai encore "trouvé" du nouveau travail d'optimisation à faire (annuaire categorizer)...

Merci à vous

colonies · 13 Septembre 2006

Edit : j'aais pas vu qu'il y avait plusieurs pages, rien à ajouter à ce qu'on dit d'autres personnes, en fait ;-)