Problèmes de serveur depuis passage à IPB 3.0.5

[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-enseignants-du-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 :

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) :

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 :

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.andrejorge.info/divers/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,

Modifié 10 Mars 2010 par André Jorge

[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 !

Modifié 10 Mars 2010 par André Jorge

[Chamz]

Bonjour !

J'ai publié les informations que j'ai pu obtenir à cette adresse :
/>http://www.andrejorge.info/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.andrejorge.info/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.

Modifié 13 Mars 2010 par André Jorge

[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]

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

5 fois, depuis 2003.

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-hub.com/topic/48955-mod-rewrite-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.andrejorge.info/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.andrejorge.info/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.

Modifié 19 Mars 2010 par culturec

[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.

[Dan]

Perso, je ne crois pas à un "bug" d'Invision.

Ou alors il se serait déjà rencontré chez d'autres utilisateurs.

Que la version 3.0.5 consomme plus de ressources que la 2.3.6 est un fait ! Je l'ai remarqué aussi lorsque j'ai changé de version. Mais de là à mettre un serveur HG "sur le cul" tu n'as pas le dixième de visiteurs qu'il te faudrait pour cela.

Certains de mes clients ont bien plus de visiteurs que toi, une base plus grosse et tournent Invision 3.0.5 sans souci sur une bécane qui n'a rien à voir avec ton monstre.

Tu nous dit utiliser PRM... mais tu ne nous dit pas quelle distrib Linux tu tournes.

Parce que Apache 2.0.63 me semble déjà bien ancien et php n'est pas non plus à la dernière version.

Tu tournes quel noyau ? As-tu changé récemment ?

[Chamz]

Il y a eu des discussions sur le forum d'IPS à propos d'un bug d'IPB que certains rencontreraient en fonction de l'environnement dans lequel IPB tourne.

J'ai contacté ceux qui ont eu des problèmes apparemment identiques aux miens, mais pas de réponse pour l'instant.

En ce qui concerne mon serveur :

CentOS release 5.4

Kernel : 2.6.27.10-grsec-xxxx-grs-ipv4-64

Apache 2.0.63

PHP 5.2.9

MySQL 5.0.89

eAccelerator 0.9.6-rc1

Je vais voir donc si je peux mettre à jour eAccelerator et sinon installer xCache à la place. Et demander à ce qu'Apache soit mis à jour.

Modifié 20 Mars 2010 par André Jorge

[Chamz]

Bonjour !

Je me suis aperçu que my.cnf et httpd.conf n'avaient pas été optimisés... Je m'en suis occupé (en demandant de l'aide pour httpd.conf) et depuis le serveur tourne sans problème, avec deux ou trois surcharges par moments le soir (la charge monte à 4 puis redescend à 1.50 à peu près).

Par contre, la valeur %ni reste constamment élevée (entre 2 et 9 et monte parfois à 17, alors que %us est entre 0 et 0.4 et %sy entre 0.2 et 2).

Un ps aux >liste.txt me donne des résultats tels que celui-ci :

root 19601 0.0 0.1 127812 25104 ? Ss 00:00 0:17 lfd - sleeping
nobody 21546 0.7 0.1 241512 28000 ? SN 18:32 0:06 /usr/local/apache/bin/httpd -k start -DSSL
root 21974 0.0 0.0 90176 3368 ? Ss 18:34 0:00 sshd: root_AT_pts/0
root 21997 0.0 0.0 68116 1580 pts/0 Ss 18:34 0:00 -bash
nobody 22239 0.8 0.1 236056 24960 ? SN 18:35 0:05 /usr/local/apache/bin/httpd -k start -DSSL
nobody 22294 0.5 0.1 241592 26432 ? SN 18:35 0:03 /usr/local/apache/bin/httpd -k start -DSSL
root 23106 0.0 0.0 177024 10100 ? SNs Mar23 0:23 /usr/local/apache/bin/httpd -k start -DSSL
root 24759 0.0 0.0 74804 1180 ? Ss Jan22 0:58 crond
root 26317 0.0 0.0 0 0 ? S 13:05 0:02 [pdflush]
root 29157 0.0 0.0 62624 1212 ? Ss Mar12 0:00 /usr/sbin/sshd
root 29604 0.0 0.0 43384 7156 ? SN 18:01 0:00 /usr/local/cpanel/bin/leechprotect
root 29610 0.0 0.0 109336 3964 ? SN 18:01 0:00 /usr/local/apache/bin/httpd -k start -DSSL
root 30442 0.0 0.0 64324 2040 ? S 18:23 0:00 /usr/sbin/exim -q
root 30535 0.0 0.0 28724 4060 ? S Mar09 0:00 /etc/authlib/authProg
root 30651 0.0 0.0 0 0 ? S 05:14 0:00 [pdflush]
root 31698 0.9 0.0 12880 1312 pts/0 S+ 18:36 0:05 top -d 1
nobody 31776 0.7 0.1 240656 26172 ? SN 18:37 0:03 /usr/local/apache/bin/httpd -k start -DSSL
nobody 31777 0.5 0.1 241776 29628 ? SN 18:37 0:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 31790 0.4 0.1 240756 27008 ? SN 18:37 0:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 31808 0.6 0.1 241756 30844 ? SN 18:37 0:03 /usr/local/apache/bin/httpd -k start -DSSL
nobody 31881 1.0 0.1 240996 29656 ? SN 18:38 0:04 /usr/local/apache/bin/httpd -k start -DSSL
nobody 31900 0.3 0.1 241516 27840 ? SN 18:38 0:01 /usr/local/apache/bin/httpd -k start -DSSL
nobody 31903 0.6 0.1 235660 21244 ? SN 18:38 0:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 31904 0.5 0.1 234304 20948 ? SN 18:38 0:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 31927 0.6 0.1 241080 28464 ? SN 18:38 0:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 31943 0.6 0.1 237376 23136 ? SN 18:38 0:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 31947 0.5 0.1 234864 20644 ? SN 18:38 0:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 32163 0.6 0.1 234912 23964 ? SN 18:39 0:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 32176 0.4 0.1 235660 21732 ? SN 18:39 0:01 /usr/local/apache/bin/httpd -k start -DSSL
nobody 32187 0.7 0.1 234608 19344 ? SN 18:39 0:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 32190 0.8 0.1 240484 26836 ? SN 18:39 0:03 /usr/local/apache/bin/httpd -k start -DSSL
nobody 32198 0.5 0.1 240644 25940 ? SN 18:39 0:01 /usr/local/apache/bin/httpd -k start -DSSL
nobody 32207 0.8 0.1 234296 21680 ? SN 18:39 0:02 /usr/local/apache/bin/httpd -k start -DSSL
nobody 32210 0.6 0.1 239492 27936 ? SN 18:39 0:02 /usr/local/apache/bin/httpd -k start -DSSL
root 32491 0.0 0.0 28724 4060 ? S Mar09 0:00 /etc/authlib/authProg 

Il y a beaucoup de lignes nobody 31776 0.7 0.1 240656 26172 ? SN 18:37 0:03 /usr/local/apache/bin/httpd -k start -DSSL

Que peut-on en conclure ?

Merci !

[jcaron]

Qu'il y a beaucoup de processus httpd (Apache), ce qui est normal (cf MaxClients dans ton httpd.conf) et qu'on savait déjà.

Jacques.

[Dan]

Par contre, la valeur %ni reste constamment élevée (entre 2 et 9 et monte parfois à 17, alors que %us est entre 0 et 0.4 et %sy entre 0.2 et 2).

../..

Que peut-on en conclure ?

<kidding>Moi j'en conclurais que tu ne comprends pas grand-chose aux valeurs reportées par "top".</kidding>

Les chiffres en regard de %ni, %us et %sy sont les pourcentages pour les process en mode NIce, en mode USer et en mode SYstème

Il te manque "IDle", "WAit (attente d'I/O)", "Hardware Interrupts", "Software Interrupts", "STolen (temps 'volé' par l'hyperviseur pour d'autres tâches)" ...

Donc on peut dire que de 2 à 17% de tes processus tournent en mode "Nice" (ont une priorité changée en + ou - par rapport au défaut) ... que ton cpu ne sert pas à grand-chose pour les process Utilisateurs vu le % affiché, et que le système ne mouline pas dans le noyau.

Une valeur qu'il m'aurait intéressé de voir est "WA" ... cela aurait permis de voir si ton serveur ramait au niveau des disques.

Le reste on s'en fiche un peu

PS: pour info, une charge de 4 n'est pas une surcharge pour un serveur HG. Tant que ça reste inférieur au nombre de coeurs c'est bon. Dans ton cas c'est 8 !