Comment déterminer le probleme d'un dédié ( chez ovh)

[Neptune]

Salut

J'ais actuellement des (gros) problemes avec un dédié chez OVH qui mets parfois plusieurs secondes pour afficher les pages.
Je clic sur un lien... il se passe rien pendant plusieurs secondes et hop il charge la page :/

Existe t-il un add on a webmin par exemple qui permettrais d'analyser le serveur ( CPU , RAM , DD , etc ) pour essayer de trouver pourquoi ca ram ?
Ou si quelqu'un à n'importe quoi qui pourrais m'aider hésitez pas.

 

[Mü]

Quel est le site? (histoire de tester, quoi)
Tes membres se plaignent?

Quelles sont tes configurations hard et soft? (c'est ptèt juste chez toi, le prob)

Le meilleur 'add_on' (pour reprendre ton terme) est le MRTG de base...

 

[ActuCritique]

Slt,

il faut que tu installes MRTG si ce n'est pas encore fait:
http://guides.ovh.net/InstallMRTGSys/

Après essaies de visualiser le ou les graphes qui saturent. Reste plus qu'a agir en fonction :roll:.

Courage :roll:.

 

[Neptune]

salut

mu > le dédié c est un superplan chez ovh


actu > merci beaucoup pour l'url

j'ais installé exactement de la facon du guide mais il n'y a aucun graph qui s'affichent

j'ais rajouter la tache cron pourtant mais apparement aucune images n'est généré :/

 

[Dr DLP]

Je remonte un peu le sujet car je suis exactement dans la même situation, mon site était beaucoup plus rapide en mutualisé. Avant d'y retourner et d'annuler mon paiement chez OVH, je serai très intéressé par votre avis.
Quand je reboote ou relance les services, le site va très vite environ 1 minute puis retombe dans une catalepsie complète.

Je suis sur un "superplan". Voici mes graphs (qui ont été générées à l'instant, après installation de MRTG) :
http://php-tools.org/temp/ovh_graph_1.jpg
http://php-tools.org/temp/ovh_graph_2.jpg

En regardant les résultats d'un lsof j'ai beaucoup de connexions mySQL (certaines distantes de façon temporaire, je crois que cela correspond à la majorité des connexions TCP sur les graphs) et je viens d'avoir des erreurs de connexion mysql typiques (can't connect, too many connections...).

Comment puis-je être sûr d'identifier la source de cette escargoterie?
Merci

EDIT : le site est celui de mon profil.

 

[Francois0607]

C'est vrai que là c'est lent.. j'espère que tu vas vite trouver la solution :idea:

 

[Dr DLP]

Super réponse, merci beaucoup...

 

[oberon]

j'ai une erreur 500 en arrivant dessus

 

[shrom]

Je suis sur un "superplan". Voici mes graphs (qui ont été générées à l'instant, après installation de MRTG) :
http://php-tools.org/temp/ovh_graph_1.jpg
http://php-tools.org/temp/ovh_graph_2.jpg

En regardant les résultats d'un lsof j'ai beaucoup de connexions mySQL (certaines distantes de façon temporaire, je crois que cela correspond à la majorité des connexions TCP sur les graphs) et je viens d'avoir des erreurs de connexion mysql typiques (can't connect, too many connections...).

Tu utilises mysql_pconnect et tu n'as pas configuré mysql et apache en conséquence.

2 solutions:

1) virer les pconnect ( la mailleure selon moi )
2) effectuer un test de monté en charge de ton serveur pour déterminer le nombre de connexions mysql nécessaires et le nombre d'instances d'Apache qui vont avec. Ca peut être un boulot assez difficile à faire.

 

[Dr DLP]

Je n'utilise pas de connexions persistantes.
J'ai supprimé les connexions distantes pour voir, ça ne change rien, il y a 10 utilisateurs en même temps ça rame, 20 utilisateurs ça bugue.
Ce sont des grosses requêtes que je ne peux changer... Ce n'est même pas la peine d'imaginer ce que ça pourrait donner dans les heures de pointe :?

 

[shrom]

Si tu n'utilises pas les connexions persistantes et que le nombre de connexions vers mysql est important, c'est qu'il doit y avoir une requete SQL qui bloque quelque part ( elle dure trop longtemps ou alors elle boucle ).

Si MySQL et Apache sont sur le même serveur, il ne faut pas utiliser la connexions via TCP, mais les socket Unix qui sont bien plus rapides et consomment moins de ressources.

Combien de connexions simultanées as-tu configuré pour MySQL ?

 

[Dr DLP]

Si tu parles de mysql_real_connect() j'ai essayé aussi...
C'est insuffisant. Néanmoins je vais l'adopter

 

[shrom]

Si tu parles de mysql_real_connect() j'ai essayé aussi...
C'est insuffisant. Néanmoins je vais l'adopter

Non, je ne connais pas cette fonction.

Je parle de mysql_connect('chemin_vers_le_socket_unix'[] ).

Mais ton problème ne vient de toute façon pas de là.

Tu dis voir un nombre important de connexions mysql avec lsof, ce n'est pas normal. Tu dois avoir des requêtes SQL bloquantes pour que les connexions ne soient pas relachées.

Avec 20 utilisateurs simultanés, il ne devrait pas y avoir plus de 2 ou 3 connexions par secondes, pas de quoi affoler le serveur.

 

[Dr DLP]

Il y en a beaucoup avec lsof car mes scripts en utilisent beaucoup (en moyenne 20 pour afficher une page.... c'est vraiment un minimum) et qui plus est, des lourds, du type bonne grosse sélection conditionelle de champs sur des tables de plusieurs MO avec tri et parfois des requêtes un peu plus complexes.
L'éxécution des pages prend du temps, les requêtes sont dispersées dans le script.

J'ai déjà optimisé plusieurs fois les pages, mais bien que ce ne soit pas encore au top, je ne peux plus optimiser encore beaucoup.

 

[shrom]

Il y en a beaucoup avec lsof car mes scripts en utilisent beaucoup (en moyenne 20 pour afficher une page.... c'est vraiment un minimum) et qui plus est, des lourds, du type bonne grosse sélection conditionelle de champs sur des tables de plusieurs MO avec tri et parfois des requêtes un peu plus complexes.
L'éxécution des pages prend du temps, les requêtes sont dispersées dans le script.

J'ai déjà optimisé plusieurs fois les pages, mais bien que ce ne soit pas encore au top, je ne peux plus optimiser encore beaucoup.

a )Tu dois relacher les résultats quand tu n'en as plus besoins
b ) une seule connexion est nécessaire pour l'exécution d'un script ( rien à voir avec le nombre de requêtes)
c) ce ne sont pas des tables de quelques Mo qui font peur à MySQL. Je l'utilise pour des BDD de plusieurs Giga
d) Faudrait peut être réétudier la structure de ta BDD notament au niveau des index

 

[Dr DLP]

a) je le fais déjà, et j'utilise de préférence mysql_unbuffered_query()
b) merci pour l'info
c) très bonne nouvelle, merci pour celle là aussi
d) yep, surement. Je vais m'y atteler.

Merci pour tes conseils shrom
Mais penses-tu qu'avec ces modifs le serveur puisse rester fluide avec 4x plus de connectés alors que là il bloque carrément?
Ce qui me dérange le plus c'est qu'en mutualisé ça tourne correctement (pas très vite certes) et que ça bloque sur le dédié avec 1/4 des utilisateurs.
En tout cas je vais revoir mes requêtes

 

[oberon]

J'ai quelques pages d'aide à ce sujet ici :

http://www.chevrel.org/fr/optimiser/phpmysql/

La partie sur l'utilisation de EXPLAIN SELECT et les index sur la base pourrrait t'être utile.