RuSSe_91 Posté 1 Mars 2006 Posté 1 Mars 2006 (modifié) Bonjour, Notre site tourne sous Joomla avec environ 3500 visites/jour. Lorsque nous publions un dossier, nous sommes relayés par d'autres sites et on se retrouve avec environ 400 connectés simultanés ; et la le serveur plante. Nous sommes donc obligés de demander le reboot directement chez iKoula (notre hébergeur). Configuration : AMD Sempron 2600+ 512 Mo Fedora 3.0 Plesk 7.5 Reloaded 80Go IDE 10Mb/s 1mois Nous pensons que c'est la mémoire qui n'est pas suffisante pour notre utilisation... Qu'en pensez vous ? Merci Modifié 1 Mars 2006 par RuSSe_91
Dan Posté 1 Mars 2006 Posté 1 Mars 2006 As-tu regardé le résultat d'un "top" à ces moments ? Il est possible que la RAM manque, et que le serveur swappe "à donf" Mais sans ces infos, difficile de dire quoi que ce soit. Tu peux essayer de lancer la commande "sar" pour la période du plantage, et voir ce qui a coincé à ce moment. Dan
quenting Posté 1 Mars 2006 Posté 1 Mars 2006 essayes de lancer la commande "free" et donne nous ce qui en sort.
RuSSe_91 Posté 3 Mars 2006 Auteur Posté 3 Mars 2006 Salut Je n'ai pas pu lancer les processus au moment quand serveur rame puisque ca arrive pas tous les jours... Voici ce que donne free à l'instant quand tout va bien : http://img207.imageshack.us/my.php?image=s...nshot0010ih.jpg J'ai pas reussi à lancer sar Sinon nous avons déjà changé de serveur il y a quelques mois, le problème persiste... Les deux serveurs, avaient 512 Mo de ram. Nous avons une personne de Kamino.fr qui s'est occupé des réglages du serveur/optimisation, donc il a fait un max de son coté, le serveur est déjà plus rapide, mais lorsque nous dépassons les 400-500 connectés, le serveur rame à fond et il est inaccessible, obligé de reboot. Donc la personne nous a dit qu'il fallait ajouter de la ram...
RuSSe_91 Posté 6 Mars 2006 Auteur Posté 6 Mars 2006 (modifié) La par example, j'ai un peu de monde sur le site, mysql monte jusqu'à 15% contre environ 10% pour apache... Modifié 6 Mars 2006 par RuSSe_91
AvenueDuWeb Posté 6 Mars 2006 Posté 6 Mars 2006 Sur le screen que tu montres apache consomme plus que mysql. Mais sinon il me semble que Plesk n'a qu'un process MySQL donc ça me paraitrait normal qu'il consomme pas mal de ressources. @+
benxico Posté 6 Mars 2006 Posté 6 Mars 2006 (modifié) Bonjour, L'infogérance d'un serveur passe parfois par une simple optimisation des scripts qu'il héberge, par exemple en regardant si les requêtes sql sont écrites correctement. Pour faire plusieurs select de suite par exemple, il vaut mieux commencer par le select qui va donner le moins de réponse pour faire ensuite un select dans ce qui reste. Cela peut paraitre bête mais on trouve malheureusement trés souvent ce type "d'erreur" dans les scripts php. Il faut également regarder si les bases mysql sont correctement indexés, commande mysqlcheck ça peut parfois faire des miracles. Sinon pour pouvoir réellement déterminer d'où vient le problème, il faut d'une part mettre votre serveur sous monitoring, d'autre part faire une interprétation de vos logs, et également bien connaitre les scripts que vous hébergez. Si vous avez besoin d'une mise sous monito y a moyen de faire ça Bien amicalement, Benxico Ps : essaye de faire un screen avec un peu d'uptime que 2 min Modifié 6 Mars 2006 par benxico
RuSSe_91 Posté 8 Mars 2006 Auteur Posté 8 Mars 2006 La mon serveur vient de planter (enfin lag). Le site est donc inaccessible, voici ce que donne top : Root monte jusqu'à 80% et apache jusqu'à 30-40... Voici le screenshot du TOP
dièse Posté 8 Mars 2006 Posté 8 Mars 2006 Bonjour, Ton problème de ralentissement vient certainement du swap. Tu utilises plus de swap que ce que tu as de mémoire vive , même en doublant la mémoire de ton serveur tu auras encore des problèmes... Mysql consomme beaucoup, mais optimiser tes requêtes ne suffira pas, va falloir penser à investir
Dan Posté 8 Mars 2006 Posté 8 Mars 2006 Ce qui importe sur le screenshot du top que tu donnes est le "run-queue"... il ne devrait pas dépasser le nombre de CPUs (voire deux fois ce nombre pour les CPU avec hyperthreading, ou 4 fois pour dual-core+hyperthreading) Là tu as une moyenne de 27, ou de 25 sur les 5 dernières minutes, ou encore 14 pour les 15 dernières minutes... c'est beaucoup trop. En regardant la ligne en dessous, on voit que le CPU passe 55.2% de son temps à faire du "wait"... c'est à dire qu'il attend des IO , dans ce cas le disque. C'est logique parce que tu utilises 500Mb de swap, et que pour y accéder il faut automatiquement passer par le disque. On voit d'ailleurs que le daemon gérant le swap (kswapd) occupe 39.9% du CPU à lui seul. Si on ajoute ces 39.9% aux 55.2% de wait, il ne te reste effectivement pas grand chose pour exécuter des process. Regarde la colonne se trouvant juste avant le % de CPU, les process marqués "D" son en "Disk Wait"... Donc il faut au moins doubler ta mémoire... ou alors diminuer sérieusement le nombre de threads sous mysql, et de process httpd par la même occasion. Par la même occasion, fais un essai sans spamd, il est aussi plutôt gourmand en ressources. Dan PS: c'est quoi ce process drwebd ?
RuSSe_91 Posté 8 Mars 2006 Auteur Posté 8 Mars 2006 Je m'y connais pas super bien, mais drwebd est le processur qui gère le courrier je crois... Donc il faut au moins doubler ta mémoire... Nous avons fait la demande pour ajouter de la mémoire, on attends une réponse d'iKoula. ou alors diminuer sérieusement le nombre de threads sous mysql, et de process httpd par la même occasion. Ca marche comment ? Par la même occasion, fais un essai sans spamd, il est aussi plutôt gourmand en ressources. Même question. Merci d'avance.
AvenueDuWeb Posté 8 Mars 2006 Posté 8 Mars 2006 Je m'y connais pas super bien, mais drwebd est le processur qui gère le courrier je crois... Dr Web. sur Plesk c'est l'antivirus. Le pop est géré par le processus Courier-Imap et le smtp par qmail. Tu as activé le firewall sur Plesk au cas où y'aurait du filtrage de port ? (c'est super simple à mettre en place sur Plesk c'est pour ça que je demande ça) En tout cas tu swappes sévère ;o). @+
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant