Hello all,

bravo pour ce forum vrmt utile !
je lis bcp de choses tres interessante ici et je me permet de poster une question

j ai un prob de stabilite de mon serveur, donc je suis en train d explorer un peu tous les pistes
en gros, le serveur plante 2/3fois /j sans que je comprenne vrmt pourquoi


j aimerai bien comprendre une chose : comment fonctionne la ram et est ce que mes plantage peuvent etre dus a ca :



1:41pm up 2:09, 2 users, load average: 1,22, 0,89, 0,68
99 processes: 97 sleeping, 1 running, 1 zombie, 0 stopped
CPU0 states: 5,4% user, 0,4% system, 0,0% nice, 93,2% idle
CPU1 states: 3,0% user, 2,0% system, 0,0% nice, 95,0% idle

Mem: 497328K av, 480212K used, 17116K free, 0K shrd, 37292K buff
Swap: 522104K av, 0K used, 522104K free 345500K cached


voila ce que me donne mon TOP
donc en fait, j aimerai savoir si c est "normal" ou si c est un vrai probleme d avoir 70-90% de sa RAM utilisé au bout d 1h
j ai bien compris et observé que c lorsque le serveur commence a swapper que cela pose probleme et que ca plante

le site contient pas mal de requette sur une bdd de > 10k annonces avec une 20aine de champs

lorsque je trie par MEM
on peu voir au il n y a pas de process trop mechant
ce sont des mysql et des appache qui prenne 1%


PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND

25483 nobody 9 0 6684 6684 5128 S 0,0 1,3 0:01 httpd
16332 mysql 14 0 6356 6356 1216 R 5,1 1,2 0:00 mysqld
15852 mysql 14 0 6356 6356 1216 R 4,9 1,2 0:00 mysqld
22462 mysql 17 0 6356 6356 1216 R 5,5 1,2 0:00 mysqld
5425 mysql 9 0 6352 6352 1216 S 0,0 1,2 0:01 mysqld
12734 mysql 4 0 6352 6352 1216 S 0,0 1,2 0:01 mysqld
17187 mysql 9 0 6352 6352 1216 S 0,0 1,2 0:01 mysqld
21991 nobody 9 0 6288 6288 5532 S 0,0 1,2 0:01 httpd
17530 nobody 9 0 5984 5984 5152 S 1,9 1,2 0:02 httpd
25128 nobody 9 0 5832 5832 5084 S 0,0 1,1 0:00 httpd

le 25483 est une requette d affichage d image
(vu au travers de ovh-status qui permet de linker les PID )

lorsque je reboot, j ai environ 120m de ram prise et ca monte a 80-90% en 1h environ de charge normal ( 6 K vu / j )

je me demande donc vrmt si c "logik" que les process s alloue de la memoire au fur et a mesure pour tendre vers 100%
ou si au contraire c est un probleme et c est une des raisons de mes plantage

bon il suffisai d en parler pour que ca plante now 14h
enfin c est pqs plante mais les pages de mon site sont ultra lentes


123 processes: 122 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states: 0,4% user, 0,4% system, 0,0% nice, 98,2% idle
CPU1 states: 7,1% user, 1,3% system, 0,0% nice, 90,4% idle
Mem: 497328K av, 462008K used, 35320K free, 0K shrd, 35552K buff
Swap: 522104K av, 0K used, 522104K free 325860K cached


si quelqu un peut m expliquer un peu et me donner quelques piste je le remercie par avance !

Bonjour,

La première piste à explorer est celle de mysql.
Il faut regarder le fichier /var/log/mysql/slow-query.log, et s'il n'existe pas, le créer, lui donner mysql comme propriétaire et groupe et 640 comme permissions.

Ensuite, il faut redémarrer mysql pour que ce fichier soit pris en compte.

Il est possible que tu réalises que certaines requêtes prennent longtemps, et dans ce cas je te suggère de stopper mysql et lancer "myisamchk --force --recover *.MYI" dans chaque répertoire de base de données (/home/mysql/*/) et t'assurer que tous les champs après "WHERE" dans ces requêtes ont bien un index associé.

L'utilisation de 90-99% de la mémoire est normale sous Linux.

Dan

hello dan

thanx pour ta reponse

oui je viens de comprendre ( je voulais etre sur ) que c est normal de prendre 90% de la ram pour linux

( mrtg )
http://91.121.12.165/~focusfra/mrtg/
apparement ce n est vrmt pas la charge propre au trafic qui pose prob



j avais lu une de tes rep et donc j ai deja creer le rep pour les slow-query
en fait il a vrmt pas grand chose dedans au moment ou le site est mega lent





ds la derniere heure jai juste ca :


Time Id Command Argument
# Time: 070108 12:39:25
# User_AT_Host: [] @ localhost []
# Query_time: 5 Lock_time: 0 Rows_sent: 1 Rows_examined: 46001
use focusfra;
SELECT * FROM ANNONCES a,DEPARTEMENT b WHERE a.IDDEPARTEMENT=b.IDDEPARTEMENT
AND a.ACTIF=1 AND a.LOCA!=1 AND a.PHOTO!='' AND b.IDREGION=5 ORDER by rand() DESC Limit 0,1;
/usr/sbin/mysqld, Version: 3.23.58-log, started with:
Tcp port: 0 Unix socket: /var/lib/mysql/mysql.sock
Time Id Command Argument

mes IDDEPART et ACTIF LOCA ont bien des INDEX

mais je pense comme toi que ca vien de SQL


Statistiques sur les requêtes: Depuis son démarrage, 70 991 requêtes ont été envoyées au serveur.
Total ø par heure ø par minute ø par seconde
71 k 64,52 k 1,08 k 17,92

je ne me rends pas compte si c est bcp

je v faire ton "myisamchk --force --recover *.MYI"

car je viens de voir une stat qui me fait peur:

Select_full_join 682 Le nombre de jointures qui n'ont pas utilisé d'index. Si cette valeur est supérieure à 0, vérifiez soigneusement les indexes de vos tables.
Select_full_range_join 28 Le nombre de jointures qui ont utilisé une recherche par plage sur une table de référence.
Select_range 2 k Le nombre de jointures qui ont utilisé des plages sur la première table. (Normalement non critique même si cette valeur est élevée.)
Select_range_check 456 Le nombre de jointures sans clés qui vérifient l'utilisation de clé à chaque enregistrement. (Si ceci est supérieur à 0, vérifiez soigneusement les indexes de vos tables.)
Select_scan 18 k Le nombre de jointures qui ont nécessité le parcours complet de la première table.

est ce un GROS probleme qui pourai expliker les ralentissements ?

autre piste :
les warning quand je relance appache :


Démarrage de httpd : [Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[Mon Jan 8 15:30:24 2007] [warn] NameVirtualHost 91.121.12.165:80 has no VirtualHosts
[ OK ]
[root_AT_ns23345 root]#

cela correspond a une ligne qui s est creer plusieurs fois ds /usr/local/apache/conf/httpd.conf
pendant j essayais de creer des sous domaines et de virtualhost


<VirtualHost 91.121.12.165>
DocumentRoot /home/focus/sd/uk/www
User focus
Group users
ServerName uk.focus.com
CustomLog logs/uk.focus.com-access_log combined
ScriptAlias /cgi-bin/ /home/focus/cgi-bin/
</VirtualHost>

NameVirtualHost 91.121.12.165 <============= cette ligne la qui est presente genre 15 fois


NameVirtualHost 91.121.12.165 <============= je peux l enlenver ?





je ne savais pas au il fallai mettre des INDEX sur chaque champ ki est utilise apres un WHERE
a ce moment la, limite je peux mettre TOUS les champs de mes grosses tables en index ?
cela pose t il un probleme d avoir trop d index ?
les clés primaires sont deja en index ?

merci bcp de tes indics ds tous les cas, je vais faire le myisamchk deja

Il ne faut pas mettre des index partout, parce que le remède risque d'être pire que le mal.

Les lignes excédentaires NameVirtualHost peuvent être supprimées. C'est un bug depuis que OVHM inclut l'IP failover.

Pour Info linux utilise toute la ram dispo donc c'est normal. Tu n'as pas de Swap (cf : Swap: 522104K av, 0K used, 522104K free 345500K cached) donc cela ne vient vraisemblablement de la RAM. Regarde tes logs d'erreur et essaye de déterminer ce qui s'est passé juste avant le plantage. Cela peut te donner une piste (hhpd.conf ou mysql a optimiser peut etre).

merci aussi de ta rep FenX

en fait ca ne plante plus ( c est deja ca )
c est juste que par moment , le site est super lent et now on peut etre sur que ca ne vient pas de la charge en elle meme
vu l extrait de mon TOP / mrtg

il s agit donc vraissemblablement de MYSQL
( a moins que ce ne soit le DNS , mais j y crois vrmt pas trop )

sur le dedie ovh vous conseillez de mettre le dedier comme serveur DNS ?

serveur DNS primaire: nsxxxx.ovh.net
serveur DNS secondaire : ns.ovh.net

ou de laisser dns.ovh.net / ns.ovh.net ?


je pense donc que mes ralentissement sont dus a une mauvaise optimisation de mysql

en suivant le conseil de Dan,
j ai fait le je v faire ton "myisamchk --force --recover *.MYI"

et j ai limite le slow-query a 2
ds my.cnf

set-variable = long_query_time=2
log-slow-queries = /var/log/mysql/slow-query.log

pour avoir le plus de requette possible logged
et ensuite, je vais mettre un index sur chaque champ qui fait l object d un WHERE
( meme si c est en grande partie deja fait )

d autre piste pour resoudre ce :


Select_full_join 682 Le nombre de jointures qui n'ont pas utilisé d'index. Si cette valeur est supérieure à 0, vérifiez soigneusement les indexes de vos tables.

qui vient du (etat serveur sql ds phpmyadmin)

ma base fait 12 tables et c est vrai qu il y q bcp de requette dans tous les sens, mais j ai deja essaye de simplifier le plus possible


ce qui me chagrine un peu, c est que tout ca tournait plutot bien sur un mutualise xxl
mais ca devenait un poil lent, et vu la progression du nombre de visiteurs, nous avons voulu opte pour le dedie
et la c est par moment PLUS lent que le mut.

Statistiques sur les requêtes: Depuis son démarrage,
46 160 requêtes ont été envoyées au serveur.
Total ø par heure ø par minute ø par seconde
46 k 99,39 k 1,66 k 27,61

je ne me rends pas comte si c est bcp ou non ?

Une solution serait de passer mysql en version 4.0.x voire 4.1.x ...
Avec le fichier /etc/my.cnf correctement paramétré, tu aurais au moins l'avantage du cache inhérent à la version 4 de mysql.

Mais je pense que une bonne utilisation des versions 4.x, 512Mb sont "un peu juste".

Que donne la commande "vmstat 1 20" ? Peux-tu poster le résultat ici ?

Dan


PS: merci de faire attention à éviter le SMS dans tes posts

Pardonne moi pour le langage sms, je tape un peu vite et qui plus est, je suis sur un clavier qwerty
bon c'est vrai que ce n'est une excuse




voila pour le vmstat

Désolé, j'avais oublié que la version Redhat 7.2 avait une ancienne version de procps (2.0.7 je pense)
Il te manque la colonne wa tout à droite, qui donne les infos de IO-Wait pour le CPU.

hum
je la recupere comment cette colonne wa IO wait ?

Il faut installer une version plus récente de procps... qui donne aussi une nouvelle version de top, ps, ... etc.

pour les gens qui tomberont sur ce fil depuis google en tapant : maj procps



ok donc j ai maj procps et mon "vmstat 1 20" donne :

Manifestement tu n'as pas de problème de wait, vu que la colonne reste à zéro.
Tu n'as pas non plus de problème de swap.

ok d'accord.
thanx pour cet outil que je ne connaissais pas.

en ce moment tout est vraiment tres rapide.
j ai desactivé un bout de script qui sollicite beaucoup la bdd pour voir ce que cela donne.
J espere que ca va rester comme ca, la période chaude sera cette apres-midi.

je remettrai ensuite le script qui tape dans mes jointures de 10k entrees
mais j ai bien peur que le probleme de ralentissement vienne simplement de la : grosse bdd et requetes trop gourmandes

tu penses que passer en mysql4 pourrait etre une solution ? (on doit pouvoir rajouter 512 de ram )
merci de ton aide pour cette petite review-serveur dans tous les cas.

Pas UNE solution... LA solution ! Pour autant que tes index soient OK...