Aller au contenu

Sujets conseillés

Posté

:o

bonjour,

en train de tester mon serveur dedié qui a l'air de bien fonctionner, j ai transféré un gros site vers celui-ci... ce site ayant une architecture surement des moins bonnes, et des pages très lourdes...et, oh malheur, avec une dizaine de visiteurs seulement, une lenteur certaine apparait... je vois que 95 % du processeur sont pris par mysql, je rediriges donc les visiteurs vers le vieux mutualisé qui est plus rapide....

En visitant seul le site, il marche parfaitement...

Que puis-je faire pour regler cela ?

je précise que c'est un petit serveur OVH, avec 128 Mo de RAM seulement, mais quand meme

Posté

Hello Berberer :)

Pour qu'on puisse t'aider, il faudrait que tu donnes plus d'informations concernant ta base mysql.

A priori, tu as un de ces deux problèmes :

- soit ton site génère trop de requêtes mysql et qui occupe donc toutes les ressources de ton dédié.

- soit tes bases mysql sont trop grosses et/ou mal optimisés.

Le but serait donc d'économiser tes requêtes sql soit en optimisant le format de ta base de données pour que les requêtes soient plus légères à l'exécution, soit en essayant de gérer au mieux les différentes requêtes (et donc script) dans tes pages de ton site.

Une info qui pourrait nous servir aussi est le nb d'user simultanées que tu as sur ton site (ce qui expliquerait peut être la charge de requêtes sql qui est fonction du nb d'user connecté sur ton site). Pour cà, sur ton dédié : # ps -edf | grep httpd | wc -l

++

Posté

Salut, Sid, le probleme, est qu'il s'agit d'un script qui n'est pas de moi (4homepages.com est le créateur du script), et que je n'avais pas pensé qu'en passant de mutualisé en dedié il faille que je retraivailles ce script...qui fonctionne par ailleurs très bien

au moment ou la lenteur était visible (j'ai redirigé vers le mutu maintenant), il y avais 7 utilisateurs connectés...

des deux possibiltés que tu cites, je ne serai pas surpris que ce soient les deux, mais bon, ce script est tres utilsé dans le monde est n'en est pas à sa premiere version, il me parrait donc pas normal qu'il ne fonctionne pas bien sur un serveur ou le site est seul...

Posté

Salut Berberber,

Entres la commande "uptime" dans une fenêtre putty, et donnes-nous les résultats ici (toute la ligne)

Si la "run queue" (nombre de processus attendant d'être servis dépasse 1, tu as plus que probablement un programme qui consomme trop de ressources.

Tu peux ensuite voir lequel, en entrant "top" (toujours en ligne de commande sous putty) et voir si l'un des process reste au sommet de la liste.

As-tu fait des modifications au niveau du fichier /etc/my.cnf ?

Dan

Posté
Salut Berberber,

Entres la commande "uptime" dans une fenêtre putty, et donnes-nous les résultats ici (toute la ligne)

Si la "run queue" (nombre de processus attendant d'être servis dépasse 1, tu as plus que probablement un programme qui consomme trop de ressources.

Tu peux ensuite voir lequel, en entrant "top" (toujours en ligne de commande sous putty) et voir si l'un des process reste au sommet de la liste.

As-tu fait des modifications au niveau du fichier /etc/my.cnf ?

Dan

le probleme, et que comme j'ai redirigé vers le vieux, en faisant uptime j' ai

  6:33pm  up 4 days,  8:28,  1 user,  load average: 0.16, 0.13, 0.14

<_<

non, le conf mysql est original

Posté

Salut,

Je connais 4homepages, un script de galerie d'images, j'ai travaillé sur ce script pour quelques modifs.

Ce que je peux dire c'est que normalement ton serveur devrait supporter la charge. Celui qui a opté pour ce script, l'a installé sur un superplan et il a installé 3 ou 4 galeries, il devait en creer d'autres ...

Maintenant les experts de l'administration réseau te donneront sans doute plus d'infos :)

Posté

en mettant quelques tabulations sur la page d'acceuil avec un refresh toutes les 5 s, j'obtiens les resutats suivants:

7:34pm up 4 days, 9:30, 2 users, load average: 3.18, 1.17, 0.56

sid, ta commande me donne "1"

en regardant les processus depuis webmin (c'est plus facile pour copier), j'ai cela en debut de liste

6596 mysql 4.0 % /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/v ...

13481 mysql 3.0 % /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/v ...

13422 mysql 1.8 % /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/v ...

20853 mysql 1.5 % /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/v ...

724 mysql 1.0 % /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/v ...

1798 mysql 0.8 % /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/v ...

19596 mysql 0.8 % /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/v ...

18771 mysql 0.7 % /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/v ...

18999 mysql 0.6 % /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql

et maintenant le uptime me donne

7:44pm up 4 days, 9:39, 2 users, load average: 11.23, 12.60, 7.21

Voila=== auraiss-je chosi le mauvais serveur ?

Posté
7:44pm up 4 days, 9:39, 2 users, load average: 11.23, 12.60, 7.21

Oula !

les moyennes des loads averages sont trés mauvaises .. au dela de 5 normalement, le serveur ne doit quasi plus répondre ..

Meme ces chiffres ne sont pas bon :

7:34pm up 4 days, 9:30, 2 users, load average: 3.18, 1.17, 0.56

Apparemment, d'aprés tes process, c'est bien le daemon mysql qui chie mais pourquoi, j'en ai aucune idée, a part peut être un problème de configuration.

(Autre piste, as tu des sessions sur ces scripts ?)

Notre grand maître Unix ici présent, j'ai nommé Dan, pourra surement plus t'aider que moi sur ce coup encore une fois ;)

Posté

Bonjour berberber,

- Soit c'est un pb sur ton script mais vu qu'il fonctionne sur un serveur mutualisé ...

- Soit c'est un pb de configuration de ton serveur (et p-e plus particulièrement le serveur MYSQL)

- Soit c'est un pb de perf (ca marchait sur ton mutualisé mais le serveur devait être beaucoup plus costaud).

AMA c'est un pb de perfs (d'après les données que tu m'as fourni sur le chat (nb de visiteurs / jour, taille des pages, visiteurs simultanés ...). Avec 128Mo ca doit swapper à mort !!

Mais il faut en être certain avant de changer de serveur :lol:

Posté

Berberber,

Que ta commande retourne 1 signifierait qu'il n'y a qu'un seul process httpd .... :whistling: Cela me semble très étonnant.

relances: "ps -alx | grep httpd | wc -l " (WC -L en minuscules) et donnes-moi le résultat.

A mon avis tu dois avoir au contraire un paramètre trop élevé pour le nombre de process Apache (httpd) et toute ta mémoire doit être utilisée, ce qui fait utiliser le "swap" (mémoire virtuelle)

Vérifies le fichier de configuration Apache, qui devait être correct à la livraison du serveur. Il a probablement été modifié depuis, il est probable que les paramètres de configuration ne sont pas adaptés à la taille mémoire de ta machine.

Dan

Posté

En toute honnéteté bernhard il semblerait primo que tu exécutes des scripts comme phpdig en tache de fond (qui consomment des ressources).

Ensuite je propose que tu tapes les commandes

/etc/init.d/mysql stop

puis

/etc/init.d/mysql start

(entre parenthèses je l'ai essayé et ça ne pose pas de problèmes)

Ensuite je doute qu'il s'agisse d'apache étant donné que les process mysql qui sont lancés par la commande php (c'est phpdig), qui comme chacun sait ne passe pas par apache, font lagger la machine.

sinon le serveur a l'air de fonctionner maintenant.

Evite de faire fonctionner ton phpdig lorsque les visiteurs sont connectés.

Essaie de le faire fonctionner a une heure tardive ou diminue la priorité de cet outil.

EDIT: Non décidément cela a l'air d'étre plutot un problème entre php et mysql: il semblerait qu'en updatant la page le serveur mysql et le serveur apache augmentent brusquement la part de CPU. C'est assez bizarre. peut-être qu'une recompilation ou une verification du fichier config s'impose en effet ?

Laurent.

Posté

dan la commande affiche maintenant 0 ??

euh dans httpd.conf, je vérifie quoi ?,

j'ai trouvé un httpd.conf.ovh, dois-je remplacer le .conf par celui d'OVH ?

Posté

J'ai verifié, plus de phpdig ne fonctionne en fond depuis longtemps....et comme je l'ai dis, le serveur fonctionne bien, s'il n'y a pas une dizaine d'utilisateurs sur le site qui pose probleme

Posté

Si ce n'est pas bizarre que le serveur MySQL prenne 95 % du proc tout de même.

Doit y avoir un truc.

Laurent.

Posté

Fais un copier/coller de cette commande et donnes-moi le résultat ;)

 ps -auwx | grep httpd | wc -l

Ne remplaces pas le fichier httpd.conf par celui d'origine, sinon tu perdras toutes les infos des virtual hosts que tu as créé. Il faut vérifier les paramètres tels que

Dan

PS: donnes-moi les valeurs que tu as dans le httpd.conf pour:

MaxKeepAliveRequests

MinSpareServers

MaxSpareServers

StartServers

MaxClients

MaxRequestsPerChild

Posté (modifié)

Attendez avant de faire des modifs je relance le script de Dan.

Laurent.

EDIT:

Pour Dan:

MaxKeepAliveRequests 100

KeepAliveTimeout 15

MinSpareServers 10

MaxSpareServers 20

StartServers 15

MaxClients 150

MaxRequestsPerChild 60

Dan, penses-tu vraiment que ces directives soient en cause ?

Ah oui je vois le deal.

Tu as oublié de dire qu'il fallit rajouter sudo, car sinon wc ne trouve qu'une seule ligne:

sudo ps -auxc|grep httpd|wc -l retourne 16 soit 15 processus

Ceci expliquant cela je pense qu'il y a directment un probème avec Apache.

de plus quand je tapes sudo /etc/init.d restart il me mets parfois des erreurs.

Modifié par valdo
Posté

euh l'incoveniant en editant le dernier message est que dan ne recoit pas l'email lui disant que quelque chose a changé....voila...

Posté (modifié)

Comment ça ?

Dan fait quoi ?

EDIT:Envoie lui un message privé.

Modifié par valdo
Posté
de plus quand je tapes sudo /etc/init.d restart il me mets parfois des erreurs.

J'imagine que tu parles de "sudo /etc/init.d/httpd restart"

Quelles erreurs as-tu au démarrage d'Apache ?

Il était évident -du moins dans mon esprit- qu'une commande système se lance en tant que root. J'aurais peut-être dû le préciser ;)

Le MaxRequestPerChild peut convenir mais j'essaierais avec une valeur plus faible si les requêtes http sont un peu "lourdes" (par exemple 20)

Posté

en esperant que cela ne depende pas de ma connexion, j'ai refait le meme test qu'hier, et ai apres le changement de 60 à 20 les loads suivants

6:15pm up 5 days, 8:11, 1 user, load average: 0.88, 0.59, 0.28

Ce qui me parait meilleurs (d'apres ce que j'ai compris), mais peut etre que cela depend de ma connexion.....

Posté (modifié)

En simulant 9 connexions, j'arrive aux chiffres suivant

7:30pm up 5 days, 9:25, 2 users, load average: 4.50, 2.98, 1.33

et mysql qui prend 69% du CPU...

apres quelques minutes, à ce rythme, j'ai

7:37pm up 5 days, 9:33, 2 users, load average: 16.58, 9.34, 4.48

:(:blink:

Modifié par Berberber
Posté

Berberber,

Comme tu t'en doutes, ce n'est pas bon du tout. :down:

Quels sont les process qui font appel à mysql ? Utilises-tu des connexions persistentes ?

Que font les scripts ? As-tu des requêtes croisées en pagaille ?

Dan

Posté

comme precise avant, ce n est pas mon script perso, et je pense qu il y a des appels mysql en pagaille, j avoue ne pas comprendre entierement tes deux premieres questions, les scripts generent, par mysql, les emplacements des differentes images, tout cela melanges a des templates (je t epargne l URL), sauf si tu la veux bien en mp, Nicolas ne la voulait pas vu le sujet

tu as ici de nombreux exemples de pages utilisant ce script

http://www.4homepages.de/resources/

le mien est pareil, a part une bonne 20inne de gifs animes en plus (emplacement non generes par mysql, mais specifies dans les templates)

voila....en peut pas booster mysql ?

Bernhard

Posté (modifié)

Tiens j'ai vu du marseilles sur le serveur.

dan serait-il passé par là ? :-)

EDIT: berberber tu les simule avec quoi tes connexions ?

laurent.

Modifié par valdo

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...