La traduction de l'article a été préparée en prévision du lancement du cours .
Des questions concernant les recommandations de Gluster sur la configuration du noyau surgissent de temps en temps.
Une telle nécessité se fait rare. Dans la majorité des charges de travail, le noyau fonctionne très bien. Cependant, il y a un revers. Historiquement, le noyau Linux a tendance à consommer beaucoup de mémoire lorsqu'on lui en donne l'occasion, notamment pour le cache, en tant que principale méthode d'amélioration des performances.
Dans la plupart des cas, cela fonctionne parfaitement, mais sous une forte charge, cela peut entraîner des problèmes.
Nous avons une grande expérience avec des systèmes consommant beaucoup de mémoire, comme CAD, EDA et d'autres, qui ont commencé à ralentir sous une forte charge. Et parfois, nous avons rencontré des problèmes avec Gluster. Après avoir observé pendant plusieurs jours la mémoire utilisée et le temps d'attente des disques, nous avons constaté leur surcharge, d'énormes iowait, des erreurs noyau (kernel oops), des gels, etc.
Cet article est le fruit de nombreux expériences de réglage des paramètres, effectuées dans diverses situations. Grâce à ces réglages, non seulement la réactivité globale s'est améliorée, mais le fonctionnement du cluster s'est également stabilisé de manière significative.
Lorsqu'il s'agit de configurer la mémoire, la première chose à examiner est le sous-système de mémoire virtuelle (VM, virtual memory), qui dispose d'un grand nombre d'options susceptibles de vous dérouter.
vm.swappiness
Paramètre vm.swappiness détermine dans quelle mesure le noyau utilise le swap par rapport à la mémoire vive. Dans le code source, il est également défini comme «tendency to steal mapped memory» (tendance à voler de la mémoire mappée). Une valeur élevée de swappiness signifie que le noyau sera plus enclin à décharger les pages mappées. Une faible valeur de swappiness signifie le contraire : le noyau déchargera moins de pages de la mémoire. En d'autres termes, plus la valeur est élevée vm.swappiness, plus le système utilisera de swap.
Une forte utilisation du swap est indésirable, car d'énormes blocs de données sont chargés et déchargés dans la mémoire vive. Beaucoup affirment que la valeur de swapiness doit être élevée, mais d'après mon expérience, un réglage à «0» améliore la performance.
Vous pouvez en lire plus ici —
Cependant, ces réglages doivent être appliqués avec prudence et uniquement après avoir testé l'application spécifique. Pour les applications de streaming à fort trafic, ce paramètre doit être réglé sur «0». En le changeant à «0», la réactivité du système s'améliore.
vm.vfs_cache_pressure
Ce paramètre contrôle la mémoire utilisée par le noyau pour le cache des objets de répertoire et des descripteurs d'index (dentry et inode).
Avec une valeur par défaut de 100, le noyau tentera de libérer le cache dentry et inode de manière «équitable» par rapport à pagecache et swapcache. Réduire vfs_cache_pressure entraîne le noyau à conserver les caches dentry et inode. Lorsque la valeur est à «0», le noyau ne videra jamais le cache dentry et inode en raison d'une pression mémoire, ce qui peut facilement entraîner une erreur de manque de mémoire. Augmenter vfs_cache_pressure au-delà de 100 donne la priorité au noyau pour décharger dentry et inode.
Lors de l'utilisation de GlusterFS, de nombreux utilisateurs avec de grandes quantités de données et de nombreux petits fichiers peuvent facilement consommer une quantité significative de mémoire vive sur le serveur en raison du cache d'inode/dentry, ce qui peut nuire à la performance, car le noyau doit traiter des structures de données dans un système avec 40 Go de mémoire. Réglage de ce paramètre à plus de 100 a aidé de nombreux utilisateurs à obtenir un cache plus équitable et à améliorer la 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, atteignant lequel le vidage en arrière-plan des pages sales sur le disque doit commencer. Tant que ce pourcentage n'est pas atteint, les pages ne sont pas vidées sur le disque. Lorsque le vidage commence, cela se fait 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 pouvant être occupé par des pages sales avant le début d'un vidage forcé (forced flush). Lorsque ce seuil est atteint, tous les processus deviennent synchrones (sont bloqués) et ne sont pas autorisés à continuer leur travail tant que l'opération d'I/O demandée n'est pas effectivement terminée et que les données ne sont pas sur le disque. En cas de forte charge d'I/O, cela pose un problème, car la mise en cache des données est absente et tous les processus effectuant des opérations d'I/O sont bloqués en attendant l'I/O. Cela conduit à un grand nombre de processus suspendus, une forte charge, un fonctionnement instable du système et de mauvaises performances.
La réduction des valeurs de ces paramètres entraîne un vidage plus fréquent des données sur le disque et une moindre conservation dans la RAM. Cela peut aider les systèmes disposant d'une grande quantité de mémoire, pour lesquels il est normal de vider sur le disque un cache de pages de 45 à 90 Go, ce qui entraîne des temps d'attente énormes pour les applications frontend, réduisant la réactivité et l'interactivité globales.
«1» > /proc/sys/vm/pagecache
Le cache de pages (page cache) est un cache qui stocke les données des fichiers et des programmes exécutables, c’est-à-dire des pages contenant le contenu réel des fichiers ou des périphériques de blocs. Ce cache est utilisé pour réduire le nombre de lectures depuis le disque. Une valeur de «1» signifie qu'1 % de la RAM est utilisée pour le cache et qu'il y aura plus d'opérations de lecture depuis le disque que depuis 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 des pages, vous pouvez l'utiliser.
«deadline» > /sys/block/sdc/queue/scheduler
Le planificateur d'I/O (I/O scheduler) est un composant du noyau Linux qui traite les files d'attente de lecture et d'écriture. Théoriquement, pour un contrôleur RAID intelligent, il est préférable d'utiliser «noop», car Linux ne connaît rien sur 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 demande le plus rapidement possible. Mais il semble que «deadline» améliore les performances. Vous pouvez lire davantage sur les planificateurs dans la documentation du code source du noyau Linux : linux/Documentation/block/*osched.txt. Et j'ai également observé une augmentation de la bande passante de lecture lors d'opérations mixtes (beaucoup d'opérations d'écriture).
«256» > /sys/block/sdc/queue/nr_requests
Le nombre de requêtes d'E/S dans le 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 à nr_requests du planificateur d'E/S, ce qui laisse peu de chances au planificateur d'E/S de prioriser correctement et d'effectuer la fusion des requêtes. Pour les planificateurs deadline et CFQ, il est préférable que nr_requests soit deux fois supérieur à la file d'attente interne du contrôleur. La fusion et le réarrangement des requêtes aident le planificateur à être plus réactif sous une forte charge.
echo «16» > /proc/sys/vm/page-cluster
Le paramètre page-cluster contrôle le nombre de pages écrites dans le swap à la fois. Dans l'exemple ci-dessus, la valeur est définie à «16» en fonction de la taille de bande (stripe size) RAID de 64 Ko. Cela n’a pas de sens lorsque swappiness = 0, mais si vous avez défini swappiness à 10 ou 20, l'utilisation de cette valeur vous aidera lorsque la taille de bande RAID est de 64 Ko.
blockdev —setra 4096 /dev/<nom_du_dev> (-sdb, hdc ou dev_mapper)
Les paramètres par défaut des périphériques de bloc 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 4096 * 512 octets de secteurs. Pour les opérations de flux, la vitesse augmente en remplissant le cache intégré du disque grâce à la lecture anticipée pendant la période utilisée par le noyau pour préparer les E/S. Des données peuvent être mises en cache qui seront demandées lors de la prochaine lecture. Une lecture anticipée trop importante peut nuire aux E/S aléatoires pour de gros fichiers si elle utilise potentiellement du temps disque utile ou charge des données au-delà du cache.
Voici quelques autres recommandations au niveau du système de fichiers. Cependant, elles n'ont pas encore été testées. Assurez-vous que votre système de fichiers connaît la taille de bande et le nombre de disques dans l'ensemble. Par exemple, que c'est un ensemble raid5 avec une taille de bande de 64K à partir de six disques (en fait, à partir de cinq, car un disque est utilisé pour la parité). Ces recommandations sont basées sur des hypothèses théoriques et rassemblées à partir de divers blogs/articles d'experts en RAID.
-> fs ext4, 5 disques, bande de 64K, unités en blocs de 4K
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disques, bande de 64K, unités en secteurs de 512 octets
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Pour les gros fichiers, il est possible d'envisager d'augmenter les tailles de bande mentionnées 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 préalable des applications concernées par l'utilisateur. Il ne doit être appliqué que si nécessaire pour améliorer la réactivité globale du système ou si cela résout des problèmes actuels.
Documents supplémentaires :
Lire la suite
Source : habr.com
