[spip-dev] Demande d'assistance

Dev
1

Chers développeurs,

J'ai reçu de mon provider le message suivant :

Amen :

Vous avez des scripts faisant appel au serveur MySQL qui "tournent dans le vide" : ouvrir de multiple connexion sans les fermer et que nous sommes obligés de détruire nous-même. Il faut revoir certains de vos scripts sous peine de voir votre base suspendu si cela ne diminue pas. )

Qui a donné lieu aux échanges suivants :

CD : Pourriez-vous être plus spécifique quant au(x) sites qui posent problème, j'accède deux de vos serveurs au travers de 2 packs web pro.

Les scripts utilisés sont soit spip version 1.4 soit postnuke 7.14, aucun des deux n'ayant pas été modifié par moi. Auriez-vous des indications quant à leur fiabilité réciproque.

Amen : C' ets un script qui "kill" les process durant plus de 30 seconde Il nous donne juste le nombre fermé par base ( pas plus de détails): -connexion non fermée
-requetes trop longue ( MySQL cherche la réponse mais il n' y en a pas Ces process occupent la memoire du serveur ce qui peut provoquer des ralentissements.

Auriez-vous une idée du problème qui pourrait s'être posé (j'ai 'upgradé le site quasiment tous les jours avec les divers CVS au cours du mois écoulé).

Comme certains autres intervenants, je rencontre aussi des difficultés à accéder l'espace prive, le mot de passe étant systématiquement non reconnu à la première introduction, l'étant en moyenne ensuite reconnu à environ 50% au deuxième essai, et à 0% si le premier et le deuxième essais ont été infructeux. Un 'fix' fiable consiste à sélectionner l'option 'se connecter sous un autre identifiant', à re-introduire un identifiant identique au précédent et le mot de passe correspondant.

D'avance merci de votre aide.

Constant Depièreux
www.riskmanager.be

2

Salut,

Amen : C' ets un script qui "kill" les process durant plus de 30 seconde Il nous donne juste le nombre fermé par base ( pas plus de détails): -connexion non fermée
-requetes trop longue ( MySQL cherche la réponse mais il n' y en a pas Ces process occupent la memoire du serveur ce qui peut provoquer des ralentissements.

Ils sont vagues chez Amen. Il faudrait au minimum qu'ils disent :
- quel est le script précisément qui déclenche l'"anomalie"
- quelle est la requête MySQL en cours lorsque leur script la détecte

Sinon, on ne peut pas trouver grand'chose.

a+

Antoine.

3

Ils sont vagues chez Amen. Il faudrait au minimum qu'ils disent :
- quel est le script précisément qui déclenche l'"anomalie"
- quelle est la requête MySQL en cours lorsque leur script la détecte

- sur lequel des deux serveur ça se produit. Sur les deux ? Ah ben c'est
  normal alors, ils ne gèrent pas de pool de connexion, donc 1 connexion
  sur deux se prend les pieds dans les scripts spip. Ce qui explique les
  histoire de lenteurs, de redemeandes de cnx, etc.

Sinon ne peut pas trouver grand'chose.,

A vue de nez, refaire une passe, et surveiller que les connexions sur
les bases mysql se font "vite", c'est à dire qu'on respecte toujours la
séquence "open" "select" "fetch" "close".

Ca va ralentir le bouzin, mais au moins, ça règlera le problème d'accès
sur les deux serveurs.

Autre solution, désactiver le mysql_pconnect, et le remplacer par un
mysql_connect.

Enfin, s'assurer que les connexions sont toujours toutes fermées dans le
MEME script, et valider le fait que le script est bien exécuté jusqu'au
bout par apache, même si la connexion avec le client est perdue.

A+

PS: 30", c'est un peu court, non ?