max_user_connections en mutu

[php_addict]

bonsoir

sur ma bêta ultra privée (5 joueurs seulement) un joueur a eu ceci:

Erreur : SQLSTATE[42000] [1203] User already has more than 'max_user_connections' active connections

je comprends très bien ce que cela veut dire mais je ne vois pas comment c'est possible avec seulement 5 joueurs...ok je suis sur un mutu 90plan de chez ovh mais quand même...je sais qu'il faut que je passe sur un dédié dans un futur proche mais en mutu avec 5 joueurs ca devrait le faire quand même , même si ils sont un peu addict

en mutu sur ovh comment connaitre la valeur de max_user_connections ?

[Nosrehl]

Ce serait pas un soucis du côté de l'absence de "close_connection" (pas sûr de la syntaxe ^^) dans ton code ou un truc du genre ?

Il me semble qu'avec OVH faut faire gaffe.

[php_addict]

bah en principe la connexion à la base de donnée est close quand le script est terminé non ?

j'utilise pdo:

$connexion_mmorpg = new PDO('mysql:host='.$PARAM_hote.';port='.$PARAM_port.';dbname='.$PARAM_nom_bd, $PARAM_utilisateur, $PARAM_mot_passe, array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8"));

$connexion_mmorpg->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

//

//

//

$connexion_mmorpg = null;

[Nosrehl]

Ah je peux pas te dire, je connais très peu PDO.

[php_addict]

et si je veut reproduire ce bug je peut faire comment ? parce que là je ne comprends vraiment pas comment cela a pu se produire avec 3 joueurs connectés sans utiliser de connexions persistantes...

j'ai eu tout un tas de gros bugs incompréhensibles ce soir, je soupçonne ovh sur ce coup...ca vous est déjà arrivé en mutu d'avoir ce genre de soucis?

grosso modo je fais comme ceci dans la 99% des contrôleurs:


- je démarre la session avec gestion des sessions en base de données (session_set_save_handler)
- je charge mes fonctions et autres fichiers de config et de données (include)
- je charge mes modèles (include)
- je me connecte à la base
- le script fait tout un tas de truc sur la bdd
- je déconnecte de ma bdd qui je crois est optionnel
- session_write_close() qui je crois est optionnel
- je balance le tout dans la vue

ps une fois la vue chargé il y a un petit script ajax qui interroge la bdd toutes les 5 minutes c'est pas énorme

est ce que je fais quelque chose de mal?

peut être que le hic est que session_set_save_handler est géré par des function mysql mysql_select_db (sans PDO donc) et que mes scripts tournent avec PDO

ou bien peut être que c'est parce que je n'utilse pas PDOStatement::closeCursor

[Argorate]

Tu as demandé a OVH? c'est eux qui te renseigneront le mieux.
Sinon il te faut fermer tes connexion sur chaque page où tu les ouvre.

[php_addict]

Tu as demandé a OVH? c'est eux qui te renseigneront le mieux.
Sinon il te faut fermer tes connexion sur chaque page où tu les ouvre.

j'ai demandé mais je doute qu'ils se penchent sur mon petit cas...

en principe les connexions sont fermés, mais de toutes façon même si je ne le fait pas c'est automatique à la fermeture du script non ?

[christouphe]

La plupart du temps, les hébergeur comptent:

1) le nombre de connexions simultanées
2) le nombre de requêtes envoyées par heure

Dans le cas 1, il suffit d'attendre qu'une des connexion passe en timeout sur le serveur, en dehors de toute fermeture
Dans le cas 2, si tu dépasses le quota, il faut attendre une bonne heure pour pouvoir relance la moindre requête.

[Sephi-Chan]

Improbable avec 5 joueurs. Tu fais des tonnes de requêtes SQL (genre dans une boucle) ?

[php_addict]

Improbable avec 5 joueurs. Tu fais des tonnes de requêtes SQL (genre dans une boucle) ?

non, j'ai totalement merdé:

j'utilise session_set_save_handler avec l'extensio mysqli pour le gestion des sessions en base de donnée

et PDO pour le reste des script

c'est ca qui deconne je pense...car avec une utilisation fichier des sessions pas de probleme...c'est pour cela que je veut passer tout en PDO d'ou mon topic http://www.jeuweb.org/showthread.php?tid=7522


PS: en plus sur mon mutu je suis à: Nombre de connexions simultanées 10 . Donc pas de quoi s'inquieter avec 5 joueurs ...