Server Intel Xeon Quad surchargé: optimiser ou changer?

[supatony]

Salut à tous,

Je viens de passer un site qui fait 30 000 VU/jour d'un mutu (ovh xxlplan) ou il commençait à être à l'étroit vers un dédié : intel Xeon quad avec 8Go de RAM (http://www.ovh.com/fr/particulier/produits/eg_max.xml).

Problème: alors que je pensais être large avec ce type de server, il est complètement surchargé niveau CPU (la RAM est quasiment inutilisée) si bien que le load monte a plus de 100. J'ai passé 2 jours à essayer d'optimiser la config apache (MaxClients, MaxRequestPerChild, SpareServers ..etc) ça améliore un peu mais dès que apache dépasse les 40 requètes/sec, le load explose.

Ci-dessous les graphs mrtg:

Je precise que le serveur est sous OVH release 2, c'est a dire une gentoo avec php en cgi.

cochez la bonne réponse:

1- ça rame à cause de gentoo/php-cgi: prends une autre distrib, ça passera les doigts dans le nez

2- Un xeon quad c'est trop léger pour 30 000 VU/jour, prends un truc plus gros

3- t'es naze t'as foiré tes valeurs d'optimisation apache: essaie avec ...

4- autre idée miraculeuse

merci pour votre aide d'experts

Modifié 21 Février 2009 par supatony

[Kioob]

Bonsoir,

en tous cas pour moi ce n'est pas l'option 2, ce type de serveur est capable d'encaisser un trafic bien supérieur à cela... à condition d'adapter la configuration d'Apache, PHP et MySQL.

As tu regardé avec un "mytop" pour voir ce qui se passe coté MySQL ?

Et pour y voir un peu plus clair sur les graphs, essayes "renice 1 -u nobody", sur le graph CPU la consommation liée à Apache/PHP devrait passer en vert.

Dans un premier temps tu peux aussi désactiver le KeepAlive d'Apache. Mais bon, trifouiller "au pif" des paramètres n'est pas forcément la bonne approche. L'idéal est d'identifier la cause des problèmes.

[bubbagic]

1- ça rame à cause de gentoo/php-cgi: prends une autre distrib, ça passera les doigts dans le nez

Yep, je sais pas si "ca passera pas les doigts dans le nez" mais ca sera mieux déjà, après il faut voir comment est codé le site....

Si y a beaucoup de requêtes SQL ca vaut peut etre le coup de passer la bdd sur une machine a part...

Voir a essayé d'optimiser le code, bien mettre les index dans MySQL et pourquoi pas un système de cache etc ....

Mais PHP en CGI c bcp plus lent.

Modifié 21 Février 2009 par bubbagic

[Kioob]

Si ce n'est pas du fastCGI c'est clair que ça doit mouliner sévère... sans oublier qu'aucun cache d'opcode n'est utilisable dans ces conditions.

[supatony]

Hé hé, je suis justement en train d'installer fastCGI et APC pour voir ce que ça donne. On verra le résultat demain, là, le nombre de requêtes est tombé en dessous du seuil critique.

Je pense pas que le problème soit du coté de mysql. Quand je surveille top, mysql ne prend jamais plus de 15% du cpu par contre j'ai 60 à 80 process php qui prennent chacun 1-3% de cpu ..

Je vais aussi passer le KeepAlive à Off mais de toute façon j'avais déjà baissé le KeepAliveTimeOut à 15.

Modifié 21 Février 2009 par supatony

[supatony]

Bon finalement j'ai réussi à installer fastCGI et APC. ça oblige à recompiler php et donc à sortir de la release OVH mais finalement ça vaut le coup: A pleine charge (90 requetes/secondes) j'ai un load à 6, le CPU tourne à peine à 50%.

En regardant un top on voit l'explication: les process php prennent beaucoup plus de cpu mais mettent 2 fois moins de temps, du coup il y a beaucoup moins de process actifs et le cpu n'est pas engorgé.

Merci pour les conseils !

[Kioob]

Un load à 6 sur un core2quad, y a encore du boulot pour réduire tout ça

[destroyedlolo]

Comme il est dit, un PHP en CGI est tres mauvais pour les perfs.

Ensuite, tu as beaucoup de memoire libre et ton utilisation n'est pas tres dynamique : peut etre devrais-tu rajouter du cache au niveau de la bdd.

Quel est l'utilisation disque : est-ce que l'usage est haut aussi ? Dans ce ca la, rajoute a nouveau du cache pour les disques.

Si tu as beaucoup de d'acces disque due a la Bdd, je te conseille de la mettre sur 1 disque separe, voir sur du RAID (attention, pas uniquement sur un autre slice du meme disque physique, mais sur un autre disque, voir meme avec un autre controleur si tu es en ATA ou IDE).

Enfin, si les problemes persistent, une bonne revue du code ne pourra que faire du bien, en particulier en supprimant autant se faire se peu tous les acces BDD inutiles (la grosse majorite des sites actuels usent et abusent des acces bdd alors qu'ils servent des fichiers qui pourraient facilement etre des fichiers statiques.

Bonne chance.

[supatony]

La fin de l'histoire au cas ou ça pourrait en inspirer d'autres:

J'avais parlé un peu trop vite, je me suis pris +15% de visites le WE dernier et le load à nouveau explosé à 30-40.

- Je me suis tapé une bonne relecture de code sur les scripts les plus gourmands (repérés par serveur-status), j'ai pu pas mal dégraisser tout ça

- J'ai collé dans le cache APC le résultat des requètes SQL les plus appelées (pas mises en cache mySQL pour cause de champs TEXT)

- J'ai revu ma config mySQL (via tuning-primer).

Résultat: 150 req/sec, load à 2.3 ouf! Le site est maintenant super rapide et je vois plein de visiteurs en plus que je voyais pas avant pour cause de lenteurs.

Merci pour les conseils...

Modifié 4 Mars 2009 par supatony

[Patrick]

Merci de ce feedback très appréciable.

Cela certainement utile à d'autres membres du Hub.

++

Patrick