Rendre vos systèmes stables sous Linux
Un article de LaPageDuJour.
Sommaire |
[modifier] De quoi parle-t-on
On est d'accord le noyau de Linux est excessivement stable. Cependant, les problèmes induits par les applications que vous utilisez peuvent paralyser vos applications. Pour les prevenir, voici quelques astuces.
[modifier] Languages utilisés
[modifier] Serveurs web
Pour les serveurs web, tous les langages sont bons. La mémoire est de toute façon normalement libérée à la fin de l'éxécution du programme (même pour les CGI).
[modifier] Autre applications
Pour les autres application comme les services réseaux, qui sont amenées à tourner sur de longues période sans interruption, l'utilisation de langages dits managés est conseillée. Ces langages ont la propriété d'automatiser la gestion de la mémoire. Ainsi, les fuites de mémoire n'existent plus (un espace mémoire est forcément référencé par une variable).
Les langages managés disponibles sous Linux sont :
- Java : Historique
- .Net avec Mono : Récent, mais très stable. Les performances sont un peu moins bonnes mais la facilité de développement meilleure.
[modifier] Outils systèmes
[modifier] Gestion des priorités
Mettez vos applications à différents niveaux de priorité. Par exemple dans la plupart des cas, on ne souhaite pas que les tâches périodiques ralentissent la bonne execution du système. Vous pouvez ainsi choisir de tous les mettre en priorité faible en modifiant le fichier crontab comme suit :
17 * * * * root nice -n 20 run-parts --report /etc/cron.hourly 25 6 * * * root nice -n 20 run-parts --report /etc/cron.daily 47 6 * * 7 root nice -n 20 run-parts --report /etc/cron.weekly 52 6 1 * * root nice -n 20 run-parts --report /etc/cron.monthly
[modifier] Amélioration des accès disques
Pour coupler une bonne gestion des priorité avec une bonne gestion des priorités au disque dur. Utilisez l'algorithme d'ordonnancement CFQ (Complete Fair Queuing) :
echo cfq >/sys/block/sda/queue/scheduler
[modifier] Pas besoin de swap
La swap ne sert pas à grand chose. Si votre machine en temps normal n'utilise que 3/4 de la RAM, n'utilisez pas de swap. En effet, lorsqu'un serveur voit ses applications passer en swap, il est de toute façon extrêmement ralenti. Il vaut souvent mieux que les applications sautent plutôt que le serveur se fige progressivement.
Par ailleurs, vous pourrez ensuite recréer de la swap dimensionnée selon vos besoins en utilisant des fichiers. Par exemple, pour une swap de 1 Go, vous ferrez :
dd if=/dev/zero of=/var/swapfile bs=1048576 count=1024 mkswap /var/swapfile swapon /var/swapfile
et dans votre fichier fstab, vous ajouterez :
/var/swapfile swap swap defaults 0 0
[modifier] Limiter /tmp
Si une application déborde sur le répertoire "/tmp", elle risque d'affecter le reste du système. Pour cela évitez de laisser "/tmp" sur une partition commune.
Pour votre répertoire "/tmp", utilisez une partition chargée en RAM de type tmpfs, limitez par exemple à 100M.
Dans votre fichier fstab, il suffit d'utiliser :
tmpfs /tmp tmpfs size=100m 0 0
D'autre part, si vous avez des applications qui ne nettoient pas correctement votre répertoire "/tmp", ajouter une tâche de nettoyage. Vous pouvez par exemple ajouter dans /etc/crontab une petite ligne :
10 * * * * root find /tmp -atime +1 -exec rm -Rf {} \;
[modifier] Utilisation de quotas
Utilisez des quota pour vos applications "à risque". C'est à dire les applications qui risquent de prendre trop d'espace disque et de perturber le bon fonctionnement du système. C'est une situation qui peut arriver plus rapidement que vous ne le croyez, notamment avec les fichiers de logs qui pourraient paralyser votre serveur.
Pour activer les quotas, mettez la première ligne :
/dev/sda1 / xfs defaults,usrquota 0 2
Puis tapez les commandes :
quotacheck -vagum quotaon -a
Ensuite, vous utilisez les quota en allouant de l'espace par utilisateur :
edquota <utilisateur>
Un éditeur se lance alors en affichant :
Quotas disque pour user <utilisateur> (uid <uid>) : Système de fichiers blocs souple stricte inodes souple stricte /dev/sda1 51602 0 0 44 0 0
Vous pouvez alors spécifier une limite en Ko pour la limite "souple" et la limite "stricte". Pour fixer une limite d'à peu près 50 Mo, vous mettez "50000". La colonne "blocs" contient le nombre de blocs déjà utilisés.
[modifier] xinetd
xinetd est un formidable outil pour permettre aux applications réseaux de n'être exécutées que lorsqu'on les demande. Et il permet (en plus de son précédcesseur inetd) de spécifier un grand nombre de paramètres donc vous pouvez (et devriez) tirer parti :
- only_from : Limite les sources autorisées de demandes
- instances : Limite le nombre d'instances du processus exécuté
- nice : Fixe la priorté
- cps : Nombre de connexions par seconde max
- max_load : Charge maximum pour laquelle accepter des connexions
- rlimit_cpu : Limite le nombre de secondes CPU (rarement utilisable en fait, ce n'est pas un pourcentage mais un temps absolu)
- rlimit_(as/data/rss/stack) : Limite la mémoire autorisée à être allouée
[modifier] Système de fichiers fiable
Un système de fichiers de qualité est nécessaire pour garantir une bonne performance d'accès aux fichiers sur le temps ou récupérer rapidement une machine qui aurait été éteinte brusquement. Nous avons par exemple :
- ext3fs est journalisé et efficace. Cependant, il amène une certaine fragmentation. Passé une dizaine de milliers de fichiers dans un répertoire, les temps d'accès aux fichiers s'allongent dramatiquement.
- reiserfs est performant dans toutes les situations mais n'est plus vraiment supporté étant donné que son créateur (Hans Reiser) a été emprissoné comme principal suspect du meurtre de sa femme.
- xfs est performant dans toutes les situation sauf la suppression de petits fichiers. Il est particulièrement efficace contre la fragmentation des fichiers.
[modifier] Base de données fiables
Sous Linux, vous avez :
- Oracle, c'est gros, c'est fiable
- MySQL, c'est plutôt léger, c'est fiable avec le moteur de base de données InnoDB (pas MyISAM)
- PostgreSQL, c'est un peu lourd et pas extrèmement performant, c'est fiable