Par la force du barbu à poils drus !
le 13 novembre 2009 à 09:49 par mrbooBon je commence à pédaler dans la choucroute avec ma part Gandi.
Résumé de la situation :
Ce blog, http://newea.fr et http://autoff.com sont installés sur une part Gandi depuis quelques jours, cela représente environ 1000 VU/jour.
Rien à redire sur le support Gandi : réactifs, attentionnés même.
Sur le papier le principe est de permettre une flexibilité des ressources disponibles pour un serveur: besoin de plus de ressource ? hop! on ajoute des « parts » de serveurs (de manière automatique ou planifié et tout doit rouler) en réalité c’est un peu plus compliqué.
Je suis parti de la distribution GandiAI (une Ubuntu) et j’ai pris la main en « root ».
Comme expliqué dans ce billet, j’ai mis en place un cache Wordpress sur memcache pour ce blog, ainsi que pour newea.fr
Résultat quand le cache est appelé, les pages s’affichent en une fraction de secondes.
Mais malgré tout il arrive régulièrement (~une fois par jour / 2 jours) que le serveur se noie: Les instances d’Apache s’accumulent jusqu’à saturation du serveur.
J’ai beau ajouter des parts Gandi rien n’y fait :
Le pire, c’est que ce matin cela a eu lieu de nouveau après un reboot…
Voici la conf de mpm_peruser_module :
MinSpareProcessors 1
MaxProcessors 20
Au cas où j’ai ajouté le module mod_evasive (pour limiter les rush de la part d’une seule IP)
La distrib Gandi est livrée avec une tripotée de scripts dans le répertoire /etc/gandi (pour le monitoring j’imagine)
Bref, j’ai une distrib et une conf Apache qui semble poser problème et surtout ne semble pas me permettre de profiter de la flexibilité du système Gandi…
Le problème c’est que je n’ai pas trop le temps de faire joujou en ce moment : J’aurai préféré passer une heure sur la finalisation de la gestion des groupes de Newea ce matin…
J’hésite entre 2 options :
- Repartir sur une part Gandi avec une Debian « propre »
- M’offrir un Kimsufi
Sauf si ce type de problème parle à quelqu’un dans la salle ? (ou ils sont tous au forum PHP 
?)
Sinon aujourd’hui c’est la journée mondiale de la politesse :
hâte de
13 novembre 2009 à 10:34
T’as installé mod_status pour voir ce qui faisait vraiment monter ton Apache ?
http://httpd.apache.org/docs/trunk/mod/mod_status.html
C’est peut être l’install WP qui charge le serveur, pas le serveur lui même.
Ceci dit, une Debian nue sera toujours mieux qu’une Ubuntu avec pleins de trucs installés par défaut qui servent à rien
13 novembre 2009 à 10:42
Ton load average est énorme ! Avec un RPS IV et près de 3 500 VU / jour pour 42 000 pages vues sur weesk.com j’avais un load average de 0,12 au max. Je pense que tu fais trop travailler le serveur via apache, un système de cache php / html conviendrait mieux, moins rapide certes mais moins gourmand en ressource.
Enfin je dis ça avec une toute petite expérience en la matière … Mais c’est sûr qu’avec un load average à 52 il peut que mouliner ton serveur.
13 novembre 2009 à 10:46
sid> thx je vais tester
Julien> les instances d’Apache semblent s’accumuler à l’infini malgré des timout courts, c’est bien là le problème. Le CPU et la RAM d’un RPS IV n’ont absolument rien à voir
13 novembre 2009 à 10:51
Ok bon … J’attends la bonne réponse avec impatience alors
13 novembre 2009 à 11:33
T’aurais pas un problème de keepAlive dans la conf apache…
Avec une mauvaise config (j’ai eu le même pb avec une dedibox sur unbuntu il y a 2/3 ans) Les param sont nickel pour faire du dev : des connexion qui restent longtemps ouvertes…
Mais pausent de sérieux problème quand il y a de nombreux visiteurs. Logique, car une connexion qui reste ouverte n’est pas repris par quelqu’un d’autre et donc, tu te retrouve avec 100 process apache ouverts a ne rien faire (par contre, ca n’explique pas ton load average) pendant que les autres visiteurs attendent d’avoir une connexion.
essai avec un
MaxKeepAliveRequests 100
KeepAliveTimeout 3
diminue aussi le MaxRequestsPerChild pour avoir des cycle plus court
MaxRequestsPerChild 10
Bizare aussi que le user affecté aux process apache soit adminftp ? C’est bien lui dans ta conf apache ? tu ne serais pas attaqué ?
13 novembre 2009 à 11:39
Jérémy> je viens de découvrir un fichier de conf Gandi avec un keepalive à On (alors que je l’avais désactivé dans la apache.conf) ….
je vais voir ce que ça donne.
Sinon pour l’adminftp c’est une pirouette de Gandi pour donner accès au compte non root qu’ils configurent par défaut.
13 novembre 2009 à 11:43
le keepalive est très utile (évite d’avoir 50 connexion par utilisateur pour afficher les images/css de chaque page) mais avec un timeout assez bas.
13 novembre 2009 à 11:49
Jérémy> ok je viens de changer la conf de cette manière, on verra bien si ça tient
13 novembre 2009 à 11:50
j’avais le même souci sur un bon gros Kimsufi , les 3 Go de ram morflaient puis ça attaquait le Swap et le load montait montait montait et boom adieu serveur
13 novembre 2009 à 11:54
My 2 cents : Pourquoi ne pas prendre un abonnement typepad (même un abo business) et ne plus se soucier de tout cela ? C’est une plateforme utilisée par plein de bloggers pro, qui tient la charge et semble tout aussi efficace que wordpress.
Tout le temps dégagé par ces tracas techniques pourraient ainsi être affectés a ton business ? Parce que au final, le visiteur il ne voit qu’un blog et se fout de savoir que derrière il y a gandi et des apaches
Bon après c’est vrai que par pur exercice intellectuel et si il y a rien d’autre d’urgent à traiter avant, je comprend le challenge…
13 novembre 2009 à 11:58
mathias> franchement Typepad ne me tente pas du tout pour le blogging + je développe pas mal d’autres choses (Newea et AutoFF) qui demandent un vrai serveur + c’est toujours plus intéressant d’apprendre
13 novembre 2009 à 12:29
D’après le screenshot:
- une seule part active sur la VM
- tous les process apache bossent en CPU (essayent, du moins)
- pas d’iowait, pas de system, que du steal contre le cpu: c’est vraiment 100% cpu, le syndrome wordpress
Ca vaut sa cacahuette de tester une debian récente avec un mpm prefork (un peu plus léger que peruser, qui sert a gérer quelques vhosts en les séparant par uid).
C’est là que je comprends pas tout, pourquoi 54 avec cette config peruser ? 104 processus, mais surtout 60 running ? Ce stade atteint, c’est dur à tenir même sur une machine dédiée.
Diminuer RequestPerChild à 10 va te faire grimper le %sys, il y aura un ratio d’exit/fork par requete haut, et peut-etre moins de charge tenue. KeepAlive donne beaucoup de process effectivement, mais sleeping.
Avec une unique part comme ici, je recommanderais de pas dépasser une dizaine de processus simultanés gavés sur le CPU, et de bencher ça en montant lentement le nombre de processes. Ca ira un peu moins vite lors des pics, mais le but est de remplir le cache sans écrouler la machine pour qu’elle revienne rapidement. Avec 60 processus simultanés, ça devient presque impossible.
Et vraiment de passer à prefork si tu n’as pas besoin de séparer les vhosts.
13 novembre 2009 à 14:20
pascal>
merci pour les infos, je vais essayer de tuner ça au mieux.
Par contre, j’ai un peu de mal avec le fichier de conf de GandiAI
(/etc/apache2/conf.d/gandiai) qui me parle de ProcessorWaitTimeout, MinMultiplexers… sans que je trouve beaucoup de doc sur le sujet sur Google.
Si j’ai le courage je passerai clairement sur une Debian.
14 novembre 2009 à 0:14
moi je dis : essaye movable type
(alors que je suis un avocat de wordpress haha)
6 janvier 2010 à 17:49
Sinon htop c’est beaucoup mieux que top