|
Ca fait un bout de temps que j'ai rien posté mais la comme c'est dimanche et que je viens de résoudre un problème récurant (qui en amènera d'autres mais bon...)..
Comme le sujet du post l'indique, je vais essayer de répondre ici à un problème souvent évoqué mais jamais résolu, le freez des dediboxes.
Pour commencer, même si le titre est clinquant, cette solution a marché pour moi, et j'espère qu'elle vous permettra d'avancer un peu plus dans votre quête ultime de la stabilité de vos serveurs et que vous pourrez ainsi prendre quelques week-end bien mérités.
Les symptomes :
La box freeze sans raison, d'une maniére aléatoire, souvent quand la charge augmente. Le serveur ping mais impossible de se loguer en ssh. Le reboot obligatoire...
Ben en fait le problème vient du swap.
Globalement un système unix à cour de mémoire freeze en quelques secondes....
Et quand je dis freeze c'est définitivement freeze : mêm le watchdog se ramasse.
Voici le scénario classique :
- vous configurez votre architecture LAMP Linux Apache Mysql PHP.
Puis un jour votre client vous appelle, vous expliquant que son serveur est down : en fait c'est juste apache qui ne veux plus accepter de connections.
Vous éditez la config apache et augmentez le nombre de connections et hop, ça c'est fait...
C'est à ce moment que vos ennuis commencent, régulièrement quand le serveur monte en charge, il plante.
Les chiffres :
Personnellement je tourne en fcgi, donc les processus impliqués sont : apache2, php5-cgi et mysql.
Pour moi ça donnerai :
- Apache : 20M par process
- php5-cgi : 5M minimum, variable en fonction de ce qu'on lui demande
- mysql : 60M
Le serveur a 3 Go de RAM soit
- 100 x Apache : 2Go
- 100 x php5-cgi : 500Mo
- 1 x mysql : 200M
A ce stade on a donc 2.7Go utilisés plus le systéme et quelques services, il ne reste plus grand chose ...
Afin d'être tranquille avec le client évoqué plus haut, lors de la reconfiguration d'apache vous avez mis 'à la louche' MaxClients = 200...
Du coup avec notre petit calcul du jour on arrive à
- 200 x apache : 4Go
- 200 x php5-cgi : 1Go
- 1 x mysql : 200M
soit plus de 5Go.....
La Constatation des Faits
Par défaut, il me semble que l'installeur des dediboxes met 500Mo par disque de swap soit 1Go en RAID1.
Donc avec la configuration par défaut, il vous manque 1 bon Giga de mémoire.
Fort de cette constatation (c'est nettement plus sympa de connaitre la nature d'un problème qui vous pourri la vie), arrive maintenant l'angoisse :
- Faut réinstaller la box ?
- Virer apache et mettre lighty (lighttpd pour les puriste),
- Dire au client qu'il lui faut un autre serveur
- Mettre en place un cluster pour faire du load balancing,
- Coder un robot qui redémmarre apache lorsque la mémoire est en dessous d'un seuil.
La Solution :
La solution toute bête : rajouter du swap.
J'entends déjà ceux qui disent :
- Oui donc faut réinstaller !
- Jamais de la vie je fait un repartitionnage à chaud sur un serveur en production
.. a ceux la je répond : ayez la foi, Linux est votre ami...
Les autres Solutions :
Avant de continuer, et donner l'ultime solution, bien que à ce stade les plus vifs auront déjà soit sauté en bas de page ou alors tapoté sur Google pour trouver la commande magique qui fait ça....
Donc avant de continuer, étudions un peu plus les solutions évoquées plus haut :
- Reinstaller la box : en théorie c'est le mieux, toutefois si la charge monte, c'est que le serveur est utilisé donc la réinstallation me semble délicate sans couper le serveur.
- Virer apache et mettre lighty : moui..... Lighty est Beau, il est Fort, il est Sexy mais pas compatible avec apache , donc se retaper tout les htaccess, remettre les vhosts.... De suite la je dirais : mauvaise idée. En même temps ça peut être le début de quelque chose en installant lighty sur une IP/port à part pour tester et avec quelques htaccess rediriger images, CSS, javascript vers lighty. Bah, ça se tente à 4h00 du mat pour voir... Et c'est assez impressionnant : il est 10 fois plus rapide, prend moins de RAM... Mais apache reste Apache et il propose des centaines de modules tès utiles.
- Dire au client qu'il lui faut un autre serveur : avant d'en arriver la il faut déja comprendre d'ou vienne les connections sur le serveur web : spiders/robots, flood, probléme de code, taches cron via wget. De toutes facons, lui proposer un autre serveur n'est viable que si le serveur actuel ne plante pas.
- Mettre en place un cluster pour faire du load balancing : Ca c'est top, en plus ça fait cool dans une discussion de geeks : "J'ai deployé une solution HA/LB avec un IP FailOver, ça pète......Quoi!!?? Tu connais pas HA/LB ?? Pfff, High Availability, Load Balancing, et en français ça donne, Haute Disponibilté avec Repartission de charge...". Moui, ce que le gars dit pas c'est qu'il a galéré pendant des mois pour que son truc soit stable et exploitable en production. Donc c'est un bonne solution, complexe et qui ne correspond pas à la situation ou vous avez un client au téléphone qui râle (à juste titre) parce que son serveur est planté.
- Coder un robot qui redémmarre apache lorsque la mémoire est en dessous d'un seuil : Alors ça c'est pas mal, je dirais même que c'est la base, je l'ai fait, le seul reproche est que actuellement c'est lancé par un cron chaque minute (ou 2 ca dépend). Du coup quand la machine est chargée, cron met du temps a se lancer et le moniteur aussi du coup, ce qui, en plus, prend encore un peu de mémoire à une machine qui en avait déja plus..... La solution serait un démon qui resterai en mémoire et qui d'ailleurs pourait scruter le constantes vitales de la machine plus frequement... Work in progress.
La solution Ultime (ou pas...) :
Bon, revenons à nos moutons (qui freezent  ), créer un swap sans toucher aux partitions :
Ici on créé un swap de 2Go (2 millions de blocks de 1024 octets chacun)
mkdir /var/swap chown root.root /var/swap chmod 700 /var/swap dd if=/dev/zero of=/var/swap/01.swp bs=1024 count=2M chown root.root /var/swap/01.swp chmod 600 /var/swap/* mkswap /var/swap/01.swp
Ensuite on ajoute ce swap au /etc/fstab
/var/swap/01.swp none swap sw 0 0
Puis on l'active
swapon -av
Pour vérifier :
swapon -s
Elle est pas belle la vie ?
Bon, j'en entends encore raler:
- mettre un swap sur une partiton ext3 ca va ramer : oui
- le ficher swap va être fragmenté : oui
En même temps à la base, votre serveur plantait. Toutefois même si en théorie c'est géré il est possible de définir une priorité a ce fichier swap afin que le serveur utilise ce swap qu'en dernier recours en mettant ceci dans /etc/fstab
/var/swap/01.swp none swap sw,pri=2 0 0
Pour finir, il est evident que si vous faites un bête copier-coller de ce que j'ai ecris ici, vous allez au devant de problèmes et que je vous prédit prochainement un 'mode rescue'. Toutefois, en comprenant un minimum de quoi on parle, cette astuce vous permettra de faire un peu plus la bringue le week-end  .
|