[Chamz]

Bonjour !

J'ai un serveur 64 bits chez OVH :
un HG09 BestOf Bi Xeon Quad 8x 2.33+ avec 16GB de RAM et deux disques durs de 1TB.
Apache 2.0.63
PHP 5.2.9
MySQL 5.0.89

J'ai installé eaccelerator pour améliorer les performances et le moteur de recherche Sphinx pour IPB.

J'y fais tourner un forum IPB (http://forums-enseig...u-primaire.com/) dont la base de données est de 8 GB.

Depuis que je suis passé de la version 2.3.6 d'IPB à la version 3.0.5 j'ai un problème avec httpd : la charge du serveur augmente subitement lorsque j'ai autour de 500 utilisateurs en ligne, et le serveur est rapidement hors service (je suis donc loin donc des 900/1000 utilisateurs que j'ai d'habitude d'avoir à cette période de l'année).

J'ai installé PRM pour que httpd soit redémarré en cas de charge du serveur, mais c'est inutile car le serveur redémarre toutes les 5, 10 ou 15 minutes lorsqu'il y a environ 500 utilisateurs en ligne.

Exemple :

Citation

Time: Wed Mar 10 15:33:33 2010 +0100
1 Min Load Avg: 76.61
5 Min Load Avg: 19.75
15 Min Load Avg: 7.22
Running/Total Processes: 223/574

(pour cette fois-là, PRM n'a pas fonctionné...)

Dans les logs de PRM, j'ai ce genre d'infos (tout le temps la même chose, avec un nombre important pour PROCS) :

Citation

USER: nobody
PID : 9330
CMD : /usr/local/apache/bin/httpd
CPU%: 0 (limit: 65)
MEM%: 0 (limit: 25)
PROCS: 181 (limit: 150)

dcpumon me donne :

Citation

76492
1268175301
500=0=0=0=0.002==0.001==0=
68=0=0=0=0.002==0.001==0=
dbus=0=0=0=0.002==0.001==0=
eximstats=0=0=0.443209747424567=0.002==0.001==0=
myforums=0.0549077027663019=0=1.02368875176487=14.0=/bin/gtar -c -f - -X /home/f$
mailman=0=0=0=0.002==0.001==0=
mailnull=0=0=0=0.002==0.001==0=
mysql=3.7=2.99408565601631=0=3.7=/usr/sbin/mysqld --basedir/ --datadir/var/lib/$
named=0.1=0=0=0.1=/usr/sbin/named -u named -t /var/named/chroot
nobody=21.8681796789204=3.81444987711129=0=24.0=/usr/local/apache/bin/httpd -k $
root=4.28408461015528=3.71176593630701=1.99610416775609=96.5=gzip=95.5=gzip=94.$
sshd=0=0=0=0.002==0.001==0=
unauthenticated=0=0=0.0078439575380432=0.002==0.001==0=

Mon httpd.conf est ici : http://www.andrejorg.../httpd.conf.txt

En mode "Performance" (pas de moteur de recherche, pas de profil des membres, pas d'affichage de photos, pas d'affichage des membres qui visitent les forums, etc.), j'ai également les mêmes problèmes (moins cependant).

Le support technique m'affirme que mon serveur gère trop de trafic et que je dois y mettre une limite sinon je continuerai à avoir des problèmes de charge.

J'ai du mal à le croire... Dans le manager d'OVH, j'ai "Trafic mois en cours : 199 GiB (informatif)". 199 GiB correspond à ce que je fais en 31 jours, mais on n'est que le 10 mars... et j'ai moins de visiteurs qu'avant sur le site.

Qu'en pensez-vous ?
Avez-vous eu des problèmes de ce genre ?
Quelles sont les solutions maintenant ?

Merci pour votre aide,

Ce message a été modifié par André Jorge - 10 mars 2010 - 16:52.

[jcaron]

On commence par les habituels top, ps axl, server-status, histoire de confirmer que c'est bien un problème de CPU de httpd et qu'il n'y a pas d'autre problème dans les parages.

Tu as activé le cache de IPB?

Jacques.

[Chamz]

Oui, le cache d'IPB est activé.

[jcaron]

Et top, ps axl, server-status?

Jacques.

[Chamz]

Je tente de bannir (momentanément) les Google bots et les autres moteurs de recherche pour voir ce que ça donne : je n'ai eu qu'un redémarrage de httpd, mais je n'ai pas réussi a obtenir des informations à ce moment là...

Avec environ 450 utilisateurs en ligne en ce moment, la charge du serveur tourne autour de 0.80 et pas de surcharge du serveur pour le moment...

Je vais devoir attendre demain soir pour essayer d'avoir d'autres informations.

Y a-t-il un moyen de savoir si les Google bots sont la cause de mes problèmes ?

Merci !

Ce message a été modifié par André Jorge - 10 mars 2010 - 20:09.

[Chamz]

Bonjour !

J'ai publié les informations que j'ai pu obtenir à cette adresse :
http://www.andrejorg...o/divers/11-03/

Qu'en pensez-vous ?

Merci pour votre aide,

[jcaron]

Que le vmstat n'a pas été capturé au même moment que le reste :-)

Le problème est effectivement visiblement au niveau des scripts php. Le premier point c'est que toutes les requêtes dynamiques consomment au moins 100 ms de CPU chacune, donc si tu dépasses 80 requêtes dynamiques/seconde (un peu moins en fait), tu satures tes CPUs. A partir de là, si tu maintiens le rythme, Apache continue à ajouter des processus, ce qui ne sert à rien, à part à consommer du temps à faire du context switch, mais c'est le moindre de tes soucis.

Tu as combien de pages vues par jour? Je suppose que c'est assez concentré en termes d'horaires, non?

Le problème est peut-être tout bêtement que la nouvelle version consomme plus de CPU que la précédente (plus de fonctions, plus de CPU), et ce qui passait avant ne passe maintenant plus... Tu as des graphes de l'utilisation CPU avant/après le changement de version?

Jacques.

[Chamz]

Non, je n'ai pas de graphes de l'utilisation CPU avant le changement de version...

C'est en soirée que j'ai le plus de visiteurs : en moyenne 200 la journée et 600 le soir (sauf le mercredi ou j'ai 500/600 utilisateurs toute la journée).
Pour aujourd'hui, j'ai 56 940 pages vues pour le moment (contre 151 299 hier, et 93 078 mardi).

La solution est donc de prendre un serveur plus puissant ?...

[jcaron]

Normalement avec ce nombre de pages vues, même en comptant un trafic très concentré (genre en comptant tout ton trafic de mardi en une heure), ça devrait largement tenir, à moins qu'il y ait des requêtes qui prennent réellement beaucoup plus de CPU que les autres.

Bref, il s'agit de tracer qui bouffe du CPU et pourquoi, un sale boulot... Tu peux commencer par mettre dans chaque script (éventuellement via un include) un truc du genre:
- au début:

$save_getrusage = getrusage();

- à la fin:

$final_getrusage = getrusage();
error_log("CPU for ".$_SERVER['REQUEST_URI'].": ". ($final_getrusage['ru_utime.tv_sec']*1000000+ $final_getrusage['ru_utme.tv_usec']- ($save_getrusage['ru_utime.tv_sec']*1000000+ $save_getrusage['ru_utme.tv_usec'])));

Tu devrais alors te retrouver avec une ligne pour chaque requête qui te dit le CPU utilisé. A partir de là tu peux commencer à chercher les pages/scripts qui bouffent le plus. Une fois que tu les as trouvés, tu peux ajouter des traces comme celles ci-dessus autour de différentes parties du script pour voir combien chacune consomme. On trouve quelquefois des choses toutes bêtes qui bouffent beaucoup pour pas grand chose.

Tu n'utilises pas bbclone au moins j'espère? C'est un CPU-hog assez sauvage dès que tu as un petit peu de trafic...

Jacques.

[Chamz]

Non, je n'ai pas bbclone.

J'ai eu un autre problème hier, alors que je n'avais que 400 membres en ligne et que je ne m'y attendais pas. j'ai pu enregistrer quelques tops :
http://www.andrejorg...o/divers/12-03/
Il y a toute une série de httpd utilisant 25% du CPU...

Dans mysql-slow.log il n'y a rien qui corresponde à ce problème.

Le script donné ci-dessus pour tracer ce qui utilise toute la CPU peut-il être utilisé tel quel ? Ou dois-je le modifier ? (ce dont je ne suis pas capable en fait, pour le moment).

Merci.

Ce message a été modifié par André Jorge - 13 mars 2010 - 06:37.

[jcaron]

Normal qu'il n'y ait rien de suspect côté mysql, c'est vraiment dans l'exécution des scripts php que le problème se situe a priori. Les deux bouts de scripts donnés ci-dessus devraient être utilisables tels quels, mais je ne les ai pas testés, et je ne programme même jamais en php en fait. Ceci dit, à part une coquille de syntaxe qui pourrait empêcher l'exécution du script, ils ne devraient pas avoir d'effet retors. Teste-les sur une copie d'un des fichiers php IPB d'abord avant de mettre en ligne...

Par contre si tu n'as pas l'habitude grep, sed, awk, sort ou perl, tu risques d'avoir du mal à extraire quoi que ce soit de bien intéressant des logs que ça va générer...

Jacques.

[culturec]

Ton forum est souvent inaccessible. On dirait même qu'il y a un problème de DNS parfois.
Tu ne crois pas qu'au lieu de changer de machine tous les 6 mois, ce qui ne résous en rien tes problèmes, tu ferais mieux de t'offrir une infogérance ?

C'est ce que j'ai fait depuis 1 an et demi, et à part le moment difficile de la facture, c'est aucune panne et un serveur qui tient bien la charge.

[Chamz]

culturec, le 14 mars 2010 - 05:56, dit :

Tu ne crois pas qu'au lieu de changer de machine tous les 6 mois,

5 fois, depuis 2003.

culturec, le 14 mars 2010 - 05:56, dit :

tu ferais mieux de t'offrir une infogérance ?

Oui, c'est sûr. Les sociétés françaises que j'ai contacté ont refusé : trop de clients. Tu peux m'envoyer une adresse par MP s'il te plaît ?

[Chamz]

Hello !

Mon problème est en fait un problème de configuration du serveur...

Pour ce qui est d'Apache, j'ai mis MaxRequestsPerChild à 15000 (au lieu de 10000) et du coup le nombre de processus reste autour de 350 (au lieu de monter jusqu'à plus de 500, suivi d'un plantage). Je vais encore tenter d'améliorer les choses de ce côté là.

Pour régler le problème de la charge du serveur, j'ai remplacé le fichier .htaccess de IPB par un autre fourni par un client d'IPS, voir ici : http://www.webmaster...write-et-ipb-3/

[jcaron]

Perso, ça me paraît douteux. Le changement de MaxRequestsPerChild doit avoir un effet vraiment très très négligeable (genre 0.02% de CPU en moins). Pour le .htaccess je suis dubitatif, mais ça dépend vraiment de la sauce interne de IPB.

Le problème c'est vraiment que tu satures en CPU. Ce qui est bizarre c'est que ça semble passer de très calme à super saturé en peu de temps, ce qui veut probablement dire qu'il y a un bug quelque part dans IPB qui se déclenche dans certaines circonstances.

Moi je serais toi, la première chose à faire c'est superviser (grapher) l'utilisation CPU. Histoire de voir si c'est tout calme et que ça monte d'un coup, si c'est souvent à la limite de la saturation, si ça augmente progressivement...

Jacques.

[Chamz]

Je vais m'occuper de superviser l'utilisation CPU ce soir.

Les techniciens de Platinum Server Management pensent eux que ma base de données faisant 8 GB, ce sont les opérations effectuées sur cette base de données qui consomment le plus de ressources et sont la cause du problème...
MySQL utilise entre 10 et 30% du CPU et il est arrivé, rarement, que cela monte à 80% et même 100%.

J'ai enregistré quelques TOP (d'avant les changements effectués sur MaxRequestsPerChild ) et je les ai publiés ici :
http://www.andrejorg...o/divers/16-03/

Ce sont 3 courtes vidéos qui correspondent aux moment ou j'avais environ 500 utilisateurs en ligne et qui montrent que la charge du server est autour de 1,5%, puis il y a une augmentation subite (et à peine visible car l'affichage ne dure pas longtemps) de %sy, et imédiatement après, PRM arrête Apache.

Le fait d'avoir fait passer MaxRequestsPerChild à 15000 à fait que je n'ai plus cette augmentation subite de %sy.
Par contre, maintenant,c'est la valeur %ni qui est plus élevée qu'avant.

[jcaron]

Les données collectées précédemment montrent clairement que le problème vient des processus Apache qui exécutent les requêtes dynamiques (pages php). Mysql consomme peut-être, mais ce n'est pas lui le fautif (en tous cas dans les cas de figure que tu nous a montrés).

Je ne connais pas prm, et j'ai quand même l'impression qu'il réagit "un peu vite", et pas forcément de façon justifiée... C'est quoi ses paramètres de déclenchement? Dans les enregistrements de top, je ne vois aucune raison valable qu'il se déclenche, tu n'aurais pas un truc genre "si httpd a plus de 300 process, kill" alors que tu as un MaxClients beaucoup plus élevé?

Sur tes top, on voit bien que l'essentiel du temps ça consomme très peu de CPU (d'ailleurs tu devrais taper "i" pour n'afficher que les processus actifs et "s" puis 1 et return pour avoir un affichage plus "rapide"). Si c'est comme ça tout le temps et soudainement ça part en flèche (plutôt que d'être pas loin de saturer les CPU, puis de les saturer), c'est qu'il doit y avoir un problème dans le code IPB qui fait que soudainement les requêtes mettent beaucoup plus de temps à s'exécuter (temps CPU, donc php, pas mysql), ou alors un problème de nombre de requêtes/seconde qui explose (soit parce que quelqu'un t'en balance soudainement beaucoup plus, soit parce qu'il y aurait par exemple une boucle de redirections ou un truc du genre).

Jacques.

[Chamz]

Bonjour !

La charge du serveur a augmenté brusquement hier et je l'ai enregistrée : http://www.andrejorg...o/divers/18-03/
J'y ai mis également deux fichiers vidéo qui montrent le top quand j'ai 450 et 590 utilisateurs en ligne.

[culturec]

Tu as essayé MaxRequestsPerChild 0

de réduire aussi KeepAliveTimeout 3

de réduire également à de plus petites valeurs :
<IfModule prefork.c>
StartServers 10
MinSpareServers 25
MaxSpareServers 30

au point ou tu en est, fait le test une journée.

sur mon serveur, avec seulement 4 Go de mémoire et un serveur 3 fois moins puissant que le tien, j'ai ces valeurs :
<IfModule prefork.c>
StartServers 5
MinSpareServers 10
MaxSpareServers 15
ServerLimit 450
MaxClients 450
MaxRequestsPerChild 0

et je tiens en forum SMF jusqu'à 1000 connectés.

Ce message a été modifié par culturec - 19 mars 2010 - 22:42.

[jcaron]

Donc ta machine ne glande rien ou presque l'essentiel du temps, et puis tout d'un coup il se passe un truc qui fait que tout plein de processus httpd se mettent à consommer du CPU à tour de bras. Comme ça concerne tout plein de processus, deux solutions:
- il y a quelqu'un qui te balance tout d'un coup énormément de requêtes "lourdes" (une DoS ou DDoS volontaire ou involontaire)
- il y a un bug dans IPB qui fait qu'il part en vrille quand il se produit un événement précis (et ça affecte tout plein de processus).

Le premier cas de figure ne me paraît pas spécialement vraisemblable au vu des server-status, mais on ne sait jamais.

Le deuxième serait dans un bout de code qui fait appel à un "état" commun, par exemple l'affichage de la liste des connectés ou des derniers messages ou un truc du genre (je ne connais pas assez IPB pour savoir s'il y a d'autres choses comme ça).

Que s'est-il passé entre 21:37:01 et 21:37:02? La liste des requêtes dynamiques vers cette heure-là pourrait aider à trouver le coupable, mais je pense qu'il faut vraiment rentrer dans le code IPB et l'instrumenter (mesurer le CPU consommé par les différentes parties du code) pour trouver le problème exact. Et comme le source n'est pas dispo librement, pfff...

Jacques.