De temps en temps, des questions se posent ici et là sur les recommandations de Gluster concernant le réglage du noyau et si cela est nécessaire.
Un tel besoin est rare. Le noyau fonctionne très bien sur la plupart des charges de travail. Bien qu'il y ait un inconvénient. Historiquement, le noyau Linux consomme facilement beaucoup de mémoire s'il en a la possibilité, y compris pour la mise en cache comme principal moyen d'améliorer les performances.
La plupart du temps, cela fonctionne bien, mais sous une charge importante, cela peut entraîner des problèmes.
Nous avons beaucoup d'expérience avec des systèmes qui consomment beaucoup de mémoire, tels que la CAO, l'EDA et autres, qui ont commencé à ralentir sous une charge élevée. Et parfois, nous avons rencontré des problèmes avec Gluster. Après avoir soigneusement observé la mémoire utilisée et la latence des disques pendant plusieurs jours, nous avons eu leur surcharge, leur énorme iowait, les oops du noyau, les gels, etc.
Cet article est le résultat de nombreuses expériences de réglage effectuées dans diverses situations. Ces paramètres ont non seulement amélioré la réactivité globale, mais ont également considérablement stabilisé les performances du cluster.
En ce qui concerne le réglage de la mémoire, la première chose à regarder est le sous-système de mémoire virtuelle (VM), qui dispose d'un grand nombre d'options qui peuvent vous dérouter.
vm.swappiness
Le paramètre
vm.swappinessdétermine combien le noyau utilise swap (swap) par rapport à la mémoire principale. Dans le code source, il est également défini comme "tendance à voler la mémoire mappée" (tendance à voler la mémoire mappée). Une valeur de swappiness élevée signifie que le noyau sera plus enclin à décharger les pages rendues. Une valeur de swappiness faible signifie le contraire: le noyau échangera moins de pages de la mémoire. En d'autres termes, plus la valeur est élevée vm.swappiness, plus le système permute.
Une large utilisation de l'échange n'est pas souhaitable car d'énormes blocs de données sont chargés et déchargés dans la RAM. Beaucoup de gens soutiennent que la valeur de swapiness devrait être élevée, mais d'après mon expérience, la mettre à "0" augmentera les performances.
Vous pouvez lire plus de détails ici -lwn.net/Articles/100978
Mais, encore une fois, ces paramètres doivent être appliqués avec prudence et uniquement après avoir testé une application particulière. Pour les applications de streaming très chargées, ce paramètre doit être défini sur "0". Le passage à "0" améliore la réactivité du système.
vm.vfs_cache_pressure
Ce paramètre contrôle la mémoire consommée par le noyau pour la mise en cache des objets d'annuaire et des inodes (dentry et inode).
Avec la valeur par défaut de 100, le noyau essaiera de libérer les caches dentry et inode en toute équité avec le pagecache et le swapcache. La diminution de vfs_cache_pressure oblige le noyau à conserver les caches dentry et inode. Lorsque la valeur est "0", le noyau n'effacera jamais les caches dentry et inode en raison d'un manque de pression mémoire, ce qui peut facilement conduire à une erreur de mémoire insuffisante. L'augmentation de vfs_cache_pressure au-dessus de 100 oblige le noyau à donner la priorité au déchargement des dents et des inodes.
Avec GlusterFS, de nombreux utilisateurs disposant de grandes quantités de données et de nombreux petits fichiers peuvent facilement utiliser une quantité importante de RAM sur le serveur en raison de la mise en cache des inodes / dentry, ce qui peut entraîner une dégradation des performances car le noyau doit traiter les structures de données sur un système avec 40 Go de mémoire ... La définition de ce paramètre au-dessus de 100 a aidé de nombreux utilisateurs à obtenir une mise en cache plus équitable et une meilleure réactivité du noyau.
vm.dirty_background_ratio et vm.dirty_ratio
Le premier paramètre (
vm.dirty_background_ratio) définit le pourcentage de mémoire avec des pages sales, après quoi il est nécessaire de démarrer un vidage d'arrière-plan des pages sales sur le disque. Tant que ce pourcentage n'est pas atteint, aucune page n'est vidée sur le disque. Et lorsque la réinitialisation démarre, elle s'exécute en arrière-plan sans interrompre les processus en cours.
Le deuxième paramètre (
vm.dirty_ratio) définit le pourcentage de mémoire qui peut être occupé par des pages sales avant le début du flash forcé. Lorsque ce seuil est atteint, tous les processus deviennent synchrones (bloqués) et ne sont pas autorisés à continuer à s'exécuter tant que l'opération d'E / S qu'ils ont demandée n'est pas réellement terminée et que les données sont sur le disque. Avec une charge d'E / S élevée, cela pose un problème, car il n'y a pas de mise en cache des données et tous les processus d'E / S sont bloqués en attente d'E / S. Cela conduit à un grand nombre de processus gelés, une charge élevée, un fonctionnement instable du système et des performances médiocres.
La diminution des valeurs de ces paramètres conduit au fait que les données sont plus souvent vidées sur le disque et non stockées dans la RAM. Cela peut aider les systèmes avec beaucoup de mémoire, pour lesquels il est normal de vider le cache de pages de 45 à 90 Go, ce qui entraîne une latence énorme pour les applications frontales, réduisant la réactivité et l'interactivité globales.
"1"> / proc / sys / vm / pagecache
Un cache de page est un cache qui stocke les données des fichiers et des programmes exécutables, c'est-à -dire qu'il s'agit de pages contenant le contenu réel des fichiers ou des périphériques de bloc. Ce cache est utilisé pour réduire le nombre de lectures de disque. Une valeur de «1» signifie que le cache utilise 1% de la RAM et qu'il y aura plus de lectures à partir du disque qu'à partir de la RAM. Il n'est pas nécessaire de modifier ce paramètre, mais si vous êtes paranoïaque sur le contrôle du cache de pages, vous pouvez l'utiliser.
Date limite> / sys / block / sdc / queue / scheduler
Le planificateur d'E / S est le composant du noyau Linux qui gère les files d'attente de lecture et d'écriture. En théorie, il est préférable d'utiliser "noop" pour un contrôleur RAID intelligent, car Linux ne sait rien de la géométrie physique du disque, il est donc plus efficace de laisser un contrôleur ayant une bonne connaissance de la géométrie du disque traiter la requête le plus rapidement possible. Mais le délai semble améliorer les performances. Pour plus d' informations sur ordonnanceurs sont disponibles dans la documentation du code source du noyau Linux:
linux/Documentation/block/*osched.txt. Et j'ai également vu une augmentation du débit de lecture lors d'opérations mixtes (beaucoup d'écritures).
"256"> / sys / block / sdc / queue / nr_requests
Le nombre de demandes d'E / S dans la mémoire tampon avant leur envoi au planificateur. Certains contrôleurs ont une taille de file d'attente interne (queue_depth) qui est plus grande que les nr_requests du planificateur d'E / S, de sorte que le planificateur d'E / S a peu de chance de hiérarchiser et de fusionner correctement les demandes. Pour les planificateurs de délais et CFQ, il est préférable que nr_requests soit égal à 2 fois la file d'attente interne du contrôleur. La combinaison et la réorganisation des requêtes permet au planificateur d'être plus réactif sous une charge importante.
echo "16"> / proc / sys / vm / page-cluster
Le paramètre de cluster de pages contrôle le nombre de pages qui sont écrites dans le swap à la fois. Dans l'exemple ci-dessus, la valeur est définie sur "16" pour correspondre à la taille de bande de 64 Ko du RAID. Cela n'a pas de sens avec swappiness = 0, mais si vous définissez swappiness sur 10 ou 20, l'utilisation de cette valeur vous aidera lorsque la taille de la bande RAID est de 64 Ko.
blockdev --setra 4096 / dev / <devname >(-sdb, hdc ou dev_mapper)
Les paramètres de périphérique de bloc par défaut pour de nombreux contrôleurs RAID entraînent souvent des performances terribles. L'ajout de l'option ci-dessus configure la lecture anticipée pour les secteurs de 4096 * 512 octets. Au moins pour les opérations de streaming, la vitesse est augmentée en remplissant le cache disque intégré avec une lecture anticipée pendant la période nécessaire au noyau pour préparer les E / S. Le cache peut contenir des données qui seront demandées lors de la prochaine lecture. Trop de lecture anticipée peut tuer les E / S aléatoires pour les fichiers volumineux si elle utilise du temps disque potentiellement utile ou si elle charge des données en dehors du cache.
Vous trouverez ci-dessous quelques instructions supplémentaires au niveau du système de fichiers. Mais ils n'ont pas encore été testés. Assurez-vous que votre système de fichiers connaît la taille de bande et le nombre de disques dans la matrice. Par exemple, il s'agit d'une matrice raid5 avec une taille de bande de 64 Ko de six disques (en fait cinq car un disque est utilisé pour la parité). Ces recommandations sont basées sur des hypothèses théoriques et recueillies à partir de divers blogs / articles rédigés par des experts RAID.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=\$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=\$((64*2)) -d swidth=\$((5*64*2))Pour les fichiers volumineux, envisagez d'augmenter les tailles de bande ci-dessus.
ATTENTION! Tout ce qui est décrit ci-dessus est extrêmement subjectif pour certains types d'applications. Cet article ne garantit aucune amélioration sans test utilisateur préalable des applications respectives. Il ne doit être utilisé que s'il est nécessaire d'améliorer la réactivité globale du système ou s'il résout les problèmes actuels.
Matériaux additionnels:
- dom.as/2008/02/05/linux-io-schedulers
- www.nextre.it/oracledocs/oraclemyths.html
- lkml.org/lkml/2006/11/15/40
- misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html
Lire la suite