{"id":95783,"date":"2020-10-03T13:42:02","date_gmt":"2020-10-03T11:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs"},"modified":"2020-10-03T13:42:02","modified_gmt":"2020-10-03T11:42:02","slug":"nastrojka-yadra-linux-dlya-glusterfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"Configuration du noyau Linux pour GlusterFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La traduction de l'article a \u00e9t\u00e9 pr\u00e9par\u00e9e en pr\u00e9vision du lancement du cours \u00abAdministrateur Linux. Professionnel\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Configuration<\/p>\n

Des questions concernant les recommandations de Gluster sur la configuration du noyau surgissent de temps en temps.<\/p>\n

Une telle n\u00e9cessit\u00e9 se fait rare. Dans la majorit\u00e9 des charges de travail, le noyau fonctionne tr\u00e8s bien. Cependant, il y a un revers. Historiquement, le noyau Linux a tendance \u00e0 consommer beaucoup de m\u00e9moire lorsqu'on lui en donne l'occasion, notamment pour le cache, en tant que principale m\u00e9thode d'am\u00e9lioration des performances.<\/a><\/noindex><\/p>\n

Dans la plupart des cas, cela fonctionne parfaitement, mais sous une forte charge, cela peut entra\u00eener des probl\u00e8mes. <\/p>\n

Nous avons une grande exp\u00e9rience avec des syst\u00e8mes consommant beaucoup de m\u00e9moire, comme CAD, EDA et d'autres, qui ont commenc\u00e9 \u00e0 ralentir sous une forte charge. Et parfois, nous avons rencontr\u00e9 des probl\u00e8mes avec Gluster. Apr\u00e8s avoir observ\u00e9 pendant plusieurs jours la m\u00e9moire utilis\u00e9e et le temps d'attente des disques, nous avons constat\u00e9 leur surcharge, d'\u00e9normes iowait, des erreurs noyau (kernel oops), des gels, etc. <\/p>\n

Cet article est le fruit de nombreux exp\u00e9riences de r\u00e9glage des param\u00e8tres, effectu\u00e9es dans diverses situations. Gr\u00e2ce \u00e0 ces r\u00e9glages, non seulement la r\u00e9activit\u00e9 globale s'est am\u00e9lior\u00e9e, mais le fonctionnement du cluster s'est \u00e9galement stabilis\u00e9 de mani\u00e8re significative.<\/p>\n

Lorsqu'il s'agit de configurer la m\u00e9moire, la premi\u00e8re chose \u00e0 examiner est le sous-syst\u00e8me de m\u00e9moire virtuelle (VM, virtual memory), qui dispose d'un grand nombre d'options susceptibles de vous d\u00e9router.<\/p>\n

vm.swappiness<\/h4>\n

\nParam\u00e8tre vm.swappiness<\/code> d\u00e9termine dans quelle mesure le noyau utilise le swap par rapport \u00e0 la m\u00e9moire vive. Dans le code source, il est \u00e9galement d\u00e9fini comme \u00abtendency to steal mapped memory\u00bb (tendance \u00e0 voler de la m\u00e9moire mapp\u00e9e). Une valeur \u00e9lev\u00e9e de swappiness signifie que le noyau sera plus enclin \u00e0 d\u00e9charger les pages mapp\u00e9es. Une faible valeur de swappiness signifie le contraire : le noyau d\u00e9chargera moins de pages de la m\u00e9moire. En d'autres termes, plus la valeur est \u00e9lev\u00e9e vm.swappiness<\/code>, plus le syst\u00e8me utilisera de swap.<\/p>\n

Une forte utilisation du swap est ind\u00e9sirable, car d'\u00e9normes blocs de donn\u00e9es sont charg\u00e9s et d\u00e9charg\u00e9s dans la m\u00e9moire vive. Beaucoup affirment que la valeur de swapiness doit \u00eatre \u00e9lev\u00e9e, mais d'apr\u00e8s mon exp\u00e9rience, un r\u00e9glage \u00e0 \u00ab0\u00bb am\u00e9liore la performance.<\/p>\n

Vous pouvez en lire plus ici \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

Cependant, ces r\u00e9glages doivent \u00eatre appliqu\u00e9s avec prudence et uniquement apr\u00e8s avoir test\u00e9 l'application sp\u00e9cifique. Pour les applications de streaming \u00e0 fort trafic, ce param\u00e8tre doit \u00eatre r\u00e9gl\u00e9 sur \u00ab0\u00bb. En le changeant \u00e0 \u00ab0\u00bb, la r\u00e9activit\u00e9 du syst\u00e8me s'am\u00e9liore.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nCe param\u00e8tre contr\u00f4le la m\u00e9moire utilis\u00e9e par le noyau pour le cache des objets de r\u00e9pertoire et des descripteurs d'index (dentry et inode).<\/p>\n

Avec une valeur par d\u00e9faut de 100, le noyau tentera de lib\u00e9rer le cache dentry et inode de mani\u00e8re \u00ab\u00e9quitable\u00bb par rapport \u00e0 pagecache et swapcache. R\u00e9duire vfs_cache_pressure entra\u00eene le noyau \u00e0 conserver les caches dentry et inode. Lorsque la valeur est \u00e0 \u00ab0\u00bb, le noyau ne videra jamais le cache dentry et inode en raison d'une pression m\u00e9moire, ce qui peut facilement entra\u00eener une erreur de manque de m\u00e9moire. Augmenter vfs_cache_pressure au-del\u00e0 de 100 donne la priorit\u00e9 au noyau pour d\u00e9charger dentry et inode.<\/p>\n

Lors de l'utilisation de GlusterFS, de nombreux utilisateurs avec de grandes quantit\u00e9s de donn\u00e9es et de nombreux petits fichiers peuvent facilement consommer une quantit\u00e9 significative de m\u00e9moire vive sur le serveur en raison du cache d'inode\/dentry, ce qui peut nuire \u00e0 la performance, car le noyau doit traiter des structures de donn\u00e9es dans un syst\u00e8me avec 40 Go de m\u00e9moire. R\u00e9glage de ce param\u00e8tre \u00e0 plus de 100 a aid\u00e9 de nombreux utilisateurs \u00e0 obtenir un cache plus \u00e9quitable et \u00e0 am\u00e9liorer la r\u00e9activit\u00e9 du noyau.<\/p>\n

vm.dirty_background_ratio et vm.dirty_ratio<\/h4>\n

\nLe premier param\u00e8tre (vm.dirty_background_ratio<\/code>) d\u00e9finit le pourcentage de m\u00e9moire avec des pages sales, atteignant lequel le vidage en arri\u00e8re-plan des pages sales sur le disque doit commencer. Tant que ce pourcentage n'est pas atteint, les pages ne sont pas vid\u00e9es sur le disque. Lorsque le vidage commence, cela se fait en arri\u00e8re-plan, sans interrompre les processus en cours. <\/p>\n

Le deuxi\u00e8me param\u00e8tre (vm.dirty_ratio<\/code>) d\u00e9finit le pourcentage de m\u00e9moire pouvant \u00eatre occup\u00e9 par des pages sales avant le d\u00e9but d'un vidage forc\u00e9 (forced flush). Lorsque ce seuil est atteint, tous les processus deviennent synchrones (sont bloqu\u00e9s) et ne sont pas autoris\u00e9s \u00e0 continuer leur travail tant que l'op\u00e9ration d'I\/O demand\u00e9e n'est pas effectivement termin\u00e9e et que les donn\u00e9es ne sont pas sur le disque. En cas de forte charge d'I\/O, cela pose un probl\u00e8me, car la mise en cache des donn\u00e9es est absente et tous les processus effectuant des op\u00e9rations d'I\/O sont bloqu\u00e9s en attendant l'I\/O. Cela conduit \u00e0 un grand nombre de processus suspendus, une forte charge, un fonctionnement instable du syst\u00e8me et de mauvaises performances.<\/p>\n

La r\u00e9duction des valeurs de ces param\u00e8tres entra\u00eene un vidage plus fr\u00e9quent des donn\u00e9es sur le disque et une moindre conservation dans la RAM. Cela peut aider les syst\u00e8mes disposant d'une grande quantit\u00e9 de m\u00e9moire, pour lesquels il est normal de vider sur le disque un cache de pages de 45 \u00e0 90 Go, ce qui entra\u00eene des temps d'attente \u00e9normes pour les applications frontend, r\u00e9duisant la r\u00e9activit\u00e9 et l'interactivit\u00e9 globales.<\/p>\n

\u00ab1\u00bb > \/proc\/sys\/vm\/pagecache<\/h4>\n

\nLe cache de pages (page cache) est un cache qui stocke les donn\u00e9es des fichiers et des programmes ex\u00e9cutables, c\u2019est-\u00e0-dire des pages contenant le contenu r\u00e9el des fichiers ou des p\u00e9riph\u00e9riques de blocs. Ce cache est utilis\u00e9 pour r\u00e9duire le nombre de lectures depuis le disque. Une valeur de \u00ab1\u00bb signifie qu'1 % de la RAM est utilis\u00e9e pour le cache et qu'il y aura plus d'op\u00e9rations de lecture depuis le disque que depuis la RAM. Il n'est pas n\u00e9cessaire de modifier ce param\u00e8tre, mais si vous \u00eates parano\u00efaque \u00e0 propos du contr\u00f4le du cache des pages, vous pouvez l'utiliser.<\/p>\n

\u00abdeadline\u00bb > \/sys\/block\/sdc\/queue\/scheduler<\/h4>\n

\nLe planificateur d'I\/O (I\/O scheduler) est un composant du noyau Linux qui traite les files d'attente de lecture et d'\u00e9criture. Th\u00e9oriquement, pour un contr\u00f4leur RAID intelligent, il est pr\u00e9f\u00e9rable d'utiliser \u00abnoop\u00bb, car Linux ne conna\u00eet rien sur la g\u00e9om\u00e9trie physique du disque, il est donc plus efficace de laisser le contr\u00f4leur, qui conna\u00eet bien la g\u00e9om\u00e9trie du disque, traiter la demande le plus rapidement possible. Mais il semble que \u00abdeadline\u00bb am\u00e9liore les performances. Vous pouvez lire davantage sur les planificateurs dans la documentation du code source du noyau Linux : linux\/Documentation\/block\/*osched.txt<\/code>. Et j'ai \u00e9galement observ\u00e9 une augmentation de la bande passante de lecture lors d'op\u00e9rations mixtes (beaucoup d'op\u00e9rations d'\u00e9criture).<\/p>\n

\u00ab256\u00bb > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nLe nombre de requ\u00eates 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\u00f4leurs (queue_depth) est sup\u00e9rieure \u00e0 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\u00eates. Pour les planificateurs deadline et CFQ, il est pr\u00e9f\u00e9rable que nr_requests soit deux fois sup\u00e9rieur \u00e0 la file d'attente interne du contr\u00f4leur. La fusion et le r\u00e9arrangement des requ\u00eates aident le planificateur \u00e0 \u00eatre plus r\u00e9actif sous une forte charge.<\/p>\n

echo \u00ab16\u00bb > \/proc\/sys\/vm\/page-cluster<\/h4>\n

\nLe param\u00e8tre page-cluster contr\u00f4le le nombre de pages \u00e9crites dans le swap \u00e0 la fois. Dans l'exemple ci-dessus, la valeur est d\u00e9finie \u00e0 \u00ab16\u00bb en fonction de la taille de bande (stripe size) RAID de 64 Ko. Cela n\u2019a pas de sens lorsque swappiness = 0, mais si vous avez d\u00e9fini swappiness \u00e0 10 ou 20, l'utilisation de cette valeur vous aidera lorsque la taille de bande RAID est de 64 Ko.<\/p>\n

blockdev \u2014setra 4096 \/dev\/<<\/code>nom_du_dev><\/code> (-sdb, hdc ou dev_mapper)<\/h4>\n

\nLes param\u00e8tres par d\u00e9faut des p\u00e9riph\u00e9riques de bloc pour de nombreux contr\u00f4leurs RAID entra\u00eenent souvent des performances m\u00e9diocres. L'ajout de l'option ci-dessus configure la lecture anticip\u00e9e pour 4096 * 512 octets de secteurs. Pour les op\u00e9rations de flux, la vitesse augmente en remplissant le cache int\u00e9gr\u00e9 du disque gr\u00e2ce \u00e0 la lecture anticip\u00e9e pendant la p\u00e9riode utilis\u00e9e par le noyau pour pr\u00e9parer les E\/S. Des donn\u00e9es peuvent \u00eatre mises en cache qui seront demand\u00e9es lors de la prochaine lecture. Une lecture anticip\u00e9e trop importante peut nuire aux E\/S al\u00e9atoires pour de gros fichiers si elle utilise potentiellement du temps disque utile ou charge des donn\u00e9es au-del\u00e0 du cache.<\/p>\n

Voici quelques autres recommandations au niveau du syst\u00e8me de fichiers. Cependant, elles n'ont pas encore \u00e9t\u00e9 test\u00e9es. Assurez-vous que votre syst\u00e8me de fichiers conna\u00eet 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 \u00e0 partir de six disques (en fait, \u00e0 partir de cinq, car un disque est utilis\u00e9 pour la parit\u00e9). Ces recommandations sont bas\u00e9es sur des hypoth\u00e8ses th\u00e9oriques et rassembl\u00e9es \u00e0 partir de divers blogs\/articles d'experts en RAID.<\/p>\n

-> fs ext4, 5 disques, bande de 64K, unit\u00e9s en blocs de 4K\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 disques, bande de 64K, unit\u00e9s en secteurs de 512 octets\nmkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nPour les gros fichiers, il est possible d'envisager d'augmenter les tailles de bande mentionn\u00e9es ci-dessus.<\/p>\n
ATTENTION !<\/b> Tout ce qui est d\u00e9crit ci-dessus est extr\u00eamement subjectif pour certains types d'applications. Cet article ne garantit aucune am\u00e9lioration sans test pr\u00e9alable des applications concern\u00e9es par l'utilisateur. Il ne doit \u00eatre appliqu\u00e9 que si n\u00e9cessaire pour am\u00e9liorer la r\u00e9activit\u00e9 globale du syst\u00e8me ou si cela r\u00e9sout des probl\u00e8mes actuels.<\/p>\n
Documents suppl\u00e9mentaires :<\/h4>\n
<\/p>\n