site qui tombe en rade sur plan 60gp (ovh)

Bonjour,

cela commence à devenir invivable pour les administrateurs d'un site d'une ONG pour laquelle je suis bénévole.

Le message "Warning: a technical problem (MySQL server) prevents access to this part of the site" vient régulièrement interrompre
le travail d'édition du contenu.

Le site est hebergé chez ovh sur un plan 60gp.

J'ai un temps remis en question mes boucles et mon arborescence mais je pense que cela vient de chez l'hebergeur car en utilisant
sur SPIP la fonction "tout déplier" depuis la page ?exec=articles_tous mySQL renvoi ce message d'erreur et le site est immobilisé
durant une dizaine de minute avant de reprendre du service.

Il nous faut prendre une décision, soit rester chez ovh et passer à un cran au dessus (90gp) sans garanties (d'après mes recherches)
soit changer d'hébergement.

Pas facile d'être spipeur ce soir :frowning:

Jérôme

J'en profite pour poser cette question d'optimisation de la gestion des
ressources...

Il y a-t-il une requête effectuée à la base à chaque boucle du squelette
spip ?

Dans la pratique dans un script, on effectue des jointures et
généralement on a une voir deux requêtes à la base par session et par page..

Dans mes squelettes (mon expérience de spipeur est assez courte), j'ai
parfois une dizaine de boucles, ce qui a forcément des conséquences sur
les ressources de la base de données..

stéphane

jerome ecureuil a écrit :

Bonjour,

cela commence à devenir invivable pour les administrateurs d'un site
d'une ONG pour laquelle je suis bénévole.

Le message "Warning: a technical problem (MySQL server) prevents access
to this part of the site" vient régulièrement interrompre
le travail d'édition du contenu.

Le site est hebergé chez ovh sur un plan 60gp.

J'ai un temps remis en question mes boucles et mon arborescence mais je
pense que cela vient de chez l'hebergeur car en utilisant
sur SPIP la fonction "tout déplier" depuis la page ?exec=articles_tous
mySQL renvoi ce message d'erreur et le site est immobilisé
durant une dizaine de minute avant de reprendre du service.

Il nous faut prendre une décision, soit rester chez ovh et passer à un
cran au dessus (90gp) sans garanties (d'après mes recherches)
soit changer d'hébergement.

Pas facile d'être spipeur ce soir :frowning:

Jérôme
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net

Infos et archives : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

irc://irc.freenode.net/spip ou
http://embed.mibbit.com/?server=irc.freenode.net&channel=%23spip

--
Nouveau single de Michel Sardon : OGM Pas !
_____________________________________________________________________
réseaux d'artistes autoproduits, label autogéré, plateforme de
téléchargement libre, média indépendant
-----------------------
http://www.dadaprod.org
_____________________________________________________________________

sonic steph a écrit :

Il y a-t-il une requête effectuée à la base à chaque boucle du squelette
spip ?

si tu es loggué admin,

tu ajoutes dans l'url de ta page (côté public) :
   &var_profile=1
ou :
   ?var_profile=1

tu affiches ainsi le tableau des requètes sql lancées pour la génération de la page (trié par durée de requète)

sinon, avec :
   &var_mode=debug
ou :
   ?var_mode=debug
tu accèdes à la liste des requètes sql générées par boucle

merci pour l'info, pratique.

Le 9 déc. 08 à 08:11, denisb a écrit :

sonic steph a écrit :

Il y a-t-il une requête effectuée à la base à chaque boucle du squelette
spip ?

si tu es loggué admin,

tu ajoutes dans l'url de ta page (côté public) :
&var_profile=1
ou :
?var_profile=1

tu affiches ainsi le tableau des requètes sql lancées pour la génération de la page (trié par durée de requète)

sinon, avec :
&var_mode=debug
ou :
?var_mode=debug
tu accèdes à la liste des requètes sql générées par boucle

_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net

Infos et archives : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

irc://irc.freenode.net/spip ou http://embed.mibbit.com/?server=irc.freenode.net&channel=%23spip

Merci Stéphane pour cette piste, j'ai un moment pensé à cela car j'ai pas mal de boucles sur le site avec notamment des conditions,
gestion de squelette par mots-clé, langue... mais mySQL décroche sur l'utilisation du back, je pense que le problème est lié à la connexion
à la base, je poursuis mon enquête.

Reste que l'optimisation des boucles est un sujet intéressant.

Jérôme

Le 9 déc. 08 à 07:55, sonic steph a écrit :

J'en profite pour poser cette question d'optimisation de la gestion des
ressources...

Il y a-t-il une requête effectuée à la base à chaque boucle du squelette
spip ?

Dans la pratique dans un script, on effectue des jointures et
généralement on a une voir deux requêtes à la base par session et par page..

Dans mes squelettes (mon expérience de spipeur est assez courte), j'ai
parfois une dizaine de boucles, ce qui a forcément des conséquences sur
les ressources de la base de données..

stéphane

jerome ecureuil a écrit :

Bonjour,

cela commence à devenir invivable pour les administrateurs d'un site
d'une ONG pour laquelle je suis bénévole.

Le message "Warning: a technical problem (MySQL server) prevents access
to this part of the site" vient régulièrement interrompre
le travail d'édition du contenu.

Le site est hebergé chez ovh sur un plan 60gp.

J'ai un temps remis en question mes boucles et mon arborescence mais je
pense que cela vient de chez l'hebergeur car en utilisant
sur SPIP la fonction "tout déplier" depuis la page ?exec=articles_tous
mySQL renvoi ce message d'erreur et le site est immobilisé
durant une dizaine de minute avant de reprendre du service.

Il nous faut prendre une décision, soit rester chez ovh et passer à un
cran au dessus (90gp) sans garanties (d'après mes recherches)
soit changer d'hébergement.

Pas facile d'être spipeur ce soir :frowning:

Jérôme
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net

Infos et archives : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

irc://irc.freenode.net/spip ou
http://embed.mibbit.com/?server=irc.freenode.net&channel=%23spip

--
Nouveau single de Michel Sardon : OGM Pas !
_____________________________________________________________________
réseaux d'artistes autoproduits, label autogéré, plateforme de
téléchargement libre, média indépendant
-----------------------
http://www.dadaprod.org
_____________________________________________________________________
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net

Infos et archives : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

irc://irc.freenode.net/spip ou http://embed.mibbit.com/?server=irc.freenode.net&channel=%23spip

Bonjour,

> jerome ecureuil a écrit :
>> Bonjour,
>>
>> cela commence à devenir invivable pour les administrateurs d'un site
>> d'une ONG pour laquelle je suis bénévole.
>>
>> Le message "Warning: a technical problem (MySQL server) prevents
>> access
>> to this part of the site" vient régulièrement interrompre
>> le travail d'édition du contenu.
>>
>> Le site est hebergé chez ovh sur un plan 60gp.
>>
>> J'ai un temps remis en question mes boucles et mon arborescence
>> mais je
>> pense que cela vient de chez l'hebergeur car en utilisant
>> sur SPIP la fonction "tout déplier" depuis la page ?
>> exec=articles_tous
>> mySQL renvoi ce message d'erreur et le site est immobilisé
>> durant une dizaine de minute avant de reprendre du service.
>>
>> Il nous faut prendre une décision, soit rester chez ovh et passer à
>> un
>> cran au dessus (90gp) sans garanties (d'après mes recherches)
>> soit changer d'hébergement.
>>
>> Pas facile d'être spipeur ce soir
>>
>> Jérôme
>> _______________________________________________

Je serai curieux de savoir comment évolue votre situation ...

A ce jour j'ai mis à jour 2 sites SPIP en v2, chacun 2 fois (local et distant).

- sur mon serveur local, pas de soucis (MAMP Mac 8 cores 6gb ...)
- pour un premier site 240plan OVH, pas de soucis
- pour un second sur 60GP, exactement le problème que vous décrivez.

Surtout pour moi dans les pages de configuration admin.

En particulier j'ai du m'y reprendre à au moins 10 fois pour
- valider GD2
- pour mettre en place la ré-écriture en arbo.

Mon premier diagnostic est un problème connexions mysql trop nombreuses:
- sur 60GP c'est 3 connexions simultanées max
- sur 240plan c'est 10 ... (90plan: 10 aussi).

Ces sites étaient depuis longtemps en v2dev ...

Pierre