La traduction de l'article a été préparée à la veille du début du cours .
Périodiquement, ici et là, des questions se posent sur les recommandations de Gluster concernant le réglage du noyau et sur la nécessité de cela.
Un tel besoin se présente rarement. Sur la plupart des charges de travail, le noyau fonctionne très bien. Bien qu'il y ait un inconvénient. Historiquement, le noyau Linux était prêt à consommer beaucoup de mémoire s'il en avait l'occasion, y compris pour la mise en cache comme principal moyen d'améliorer les performances.
Dans la plupart des cas, cela fonctionne bien, mais sous forte charge, cela peut entraîner des problèmes.
Nous avons beaucoup d'expérience avec les systèmes gourmands en mémoire tels que CAD, EDA et autres, qui ont commencé à ralentir sous une charge importante. Et parfois, nous rencontrions des problèmes dans Gluster. Après avoir observé attentivement l'utilisation de la mémoire et la latence du disque pendant plusieurs jours, nous avons obtenu leur surcharge, un énorme iwait, des erreurs de noyau (kernel oops), des blocages, etc.
Cet article est le résultat de nombreuses expériences de réglage réalisées dans diverses situations. Grâce à ces paramètres, non seulement la réactivité globale s'est améliorée, mais le cluster s'est également nettement stabilisé.
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, mémoire virtuelle), qui possède un grand nombre d'options qui peuvent vous dérouter.
vm.swappiness
Paramètre vm.swappiness détermine combien le noyau utilise le swap (swap, pagination) par rapport à la RAM. Il est également défini dans le code source comme "tendance à voler la mémoire mappée". Une permutation élevée signifie que le noyau sera plus enclin à permuter les pages mappées. Une faible valeur de swap signifie le contraire : le noyau paginera moins depuis la mémoire. Autrement dit, plus la valeur est élevée vm.swappiness, plus le système utilisera swap.
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 grande, mais d'après mon expérience, la définir sur "0" conduit à de meilleures performances.
Vous pouvez lire plus ici -
Mais, encore une fois, ces paramètres doivent être appliqués avec précaution 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". Lorsqu'il est défini sur "0", la réactivité du système s'améliore.
vm.vfs_cache_pression
Ce paramètre contrôle la mémoire consommée par le noyau pour la mise en cache des répertoires et des objets inode (dentry et inode).
Avec une valeur par défaut de 100, le noyau essaiera de libérer les caches dentry et inode sur une base "équitable" pour pagecache et swapcache. La diminution de vfs_cache_pressure oblige le noyau à conserver les caches de dentry et d'inode. Lorsque la valeur est "0", le noyau ne videra jamais le cache de dentry et d'inode en raison de la pression de la mémoire, ce qui peut facilement conduire à une erreur de mémoire insuffisante. Si vous augmentez vfs_cache_pressure au-dessus de 100, le noyau donne la priorité au dentry et au vidage des inodes.
Lors de l'utilisation de 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 inode/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. Définir cette valeur au-dessus de 100 a aidé de nombreux utilisateurs à obtenir une mise en cache plus équitable et à améliorer la réactivité du noyau.
vm.dirty_background_ratio et vm.dirty_ratio
Premier paramètre (vm.dirty_background_ratio) détermine le pourcentage de mémoire avec des pages sales, après avoir atteint lequel il est nécessaire de commencer à vider les pages sales en arrière-plan 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 d'exécution.
Le deuxième paramètre (vm.dirty_ratio) définit le pourcentage de mémoire qui peut être occupé par des pages modifiées avant que le flash forcé ne commence. Une fois ce seuil atteint, tous les processus deviennent synchrones (bloqués) et ne sont pas autorisés à continuer jusqu'à ce que les E/S demandées soient réellement terminées et que les données soient sur le disque. Avec des E/S lourdes, cela pose un problème car il n'y a pas de mise en cache des données et tous les processus effectuant des E/S sont bloqués en attente d'E/S. Cela entraîne un grand nombre de processus bloqués, une charge élevée, une instabilité du système et des performances médiocres.
La diminution de ces paramètres entraîne le vidage plus fréquent des données sur le disque et leur non-stockage dans la RAM. Cela peut aider les systèmes gourmands en mémoire où il est normal de vider les caches de pages de 45 à 90 Go sur le disque, 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 avec 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 1 % de la RAM est utilisée pour le cache et qu'il y aura plus de lectures à partir du disque que de la RAM. Il n'est pas nécessaire de modifier ce paramètre, mais si vous êtes paranoïaque à propos du contrôle du cache de la page, vous pouvez l'utiliser.
"date limite" > /sys/block/sdc/queue/scheduler
Le planificateur d'E/S est un 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 le contrôleur, qui connaît bien la géométrie du disque, traiter la requête aussi rapidement que possible. Mais il semble que "date limite" améliore les performances. Vous pouvez en savoir plus sur les planificateurs dans la documentation du code source du noyau Linux : linux/Documentation/block/*osched.txt. Et j'ai également constaté une augmentation du débit de lecture lors d'opérations mixtes (de nombreuses opérations d'écriture).
"256" > /sys/block/sdc/queue/nr_requests
Le nombre de demandes d'E/S dans la mémoire tampon avant qu'elles ne soient transmises au planificateur. La taille de la file d'attente interne de certains contrôleurs (queue_depth) est supérieure au nr_requests du planificateur d'E/S, de sorte que le planificateur d'E/S a peu de chances de hiérarchiser et de fusionner correctement les demandes. Pour les planificateurs de date limite et CFQ, il est préférable que nr_requests soit égal à 2 fois la file d'attente interne du contrôleur. La fusion et la réorganisation des requêtes aident le planificateur à être plus réactif en cas de forte charge.
echo "16" > /proc/sys/vm/page-cluster
Le paramètre page-cluster contrôle le nombre de pages qui sont écrites dans le swap en une seule fois. Dans l'exemple ci-dessus, la valeur est définie sur "16" en fonction de la taille de bande RAID de 64 Ko. 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/<nom dev> (-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 médiocres. L'ajout de l'option ci-dessus configure la lecture anticipée pour les secteurs de 4096 * 512 octets. À tout le moins, pour les opérations de streaming, la vitesse est augmentée en remplissant le cache disque sur puce avec une lecture anticipée pendant la période utilisée par le 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 prélecture peut tuer les E/S aléatoires pour les fichiers volumineux si cela utilise du temps disque potentiellement utile ou charge des données en dehors du cache.
Vous trouverez ci-dessous quelques recommandations 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 la bande et le nombre de disques dans la matrice. Par exemple, qu'il s'agit d'une matrice RAID5 à bande 64K 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 compilées à partir de divers blogs/articles 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 répertoriées ci-dessus.
ATTENTION! Tout ce qui est décrit ci-dessus est très subjectif pour certains types d'applications. Cet article ne garantit aucune amélioration sans test utilisateur préalable des applications associées. 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 des problèmes actuels.
Matériaux supplémentaires:
Lire la suite
Source: habr.com