Nous traiterons avec les régulateurs du sous-système de stockage de données et verrons ce qu'ils vous permettent de faire dans le sens d'E / S de bloc.
Ce qui est particulièrement intéressant ici, c'est que nous entrons dans un territoire où les modifications des paramètres qui sont apportées après le lancement du système sont beaucoup moins importantes que les décisions qui sont prises avant même son déploiement.
Jetez un oeil à l'image ci-dessous.
Il présente quatre ressources principales dont un ordinateur moderne a besoin pour fonctionner correctement. L'optimisation des performances est l'art de répartir de manière optimale ces ressources entre les processus d'application. De plus, toutes ces ressources ne sont pas illimitées et ne sont pas équivalentes en termes d'impact sur la productivité.
Les performances du sous-système de stockage sont réduites aux performances des technologies de stockage qui y sont utilisées: disques durs, SSD, SAN, NAS - leur vitesse d'accès et leur débit peuvent varier considérablement. Et un processeur puissant et beaucoup de mémoire ne sauvera pas la situation si les périphériques de stockage ne répondent pas aux exigences des tâches à résoudre.
Si vous, en tant que spécialiste Linux, pouvez influencer les décisions matérielles, essayez de vous assurer que votre organisation dispose d'une plate-forme de stockage adéquate (ou supérieure). Cela évitera de nombreux problèmes à l'avenir.
Voyons maintenant ce qui peut être fait à l'aide des contrôles d'entrée / sortie (E / S).
Il s'agit de périphériques de stockage
Officiellement, le contrôleur d'E / S s'appelle blkio, mais de bonne humeur, il répond à Blocky. Comme le contrôleur CPU, Blocky a deux modes de fonctionnement:
- Ajustement à l'aide de boules d'E / S relatives (partages), qui vous permettent de contrôler les performances au niveau de tous ou des périphériques de stockage de blocs sélectionnés en définissant des valeurs dans la plage de 10 à 1000. Par défaut, 1000 est utilisé, donc toute modification ne fait que réduire les boules d'E / S L'utilisateur ou le service sélectionné. Pourquoi 1000, pas 1024, comme dans le cas du CPU? Bonne question. Apparemment, c'est le cas lorsque la nature ouverte de Linux n'est pas bonne pour lui.
- Réglage absolu de la bande passante pour limiter la vitesse de lecture et / ou d'écriture pour un utilisateur ou un service donné. Par défaut, ce mode est désactivé.
La capture d'écran ci-dessous montre les paramètres qui peuvent être ajustés à l'aide de la commande systemctl. Ici, nous avons utilisé la magie des invites automatiques sur la touche Tab pour afficher une liste d'options. Cela s'appelle bash-complètement, et si vous n'utilisez toujours pas cette fonction, il est temps d'installer le PRM approprié.
Les billes d'E / S relatives sont contrôlées par les paramètres BlockIODeviceWeight et BlockIOWeight. Avant de jouer avec ces contrôleurs, vous devez comprendre ceci: ils ne fonctionnent que si le planificateur d'E / S CFQ est activé pour le périphérique de stockage.
Qu'est-ce qu'un planificateur d'E / S? Commençons de loin et rappelons que le noyau Linux est chargé de s'assurer que tous les composants matériels de l'ordinateur communiquent correctement entre eux. Et puisque tous ces composants en même temps veulent des choses différentes, on ne peut pas se passer de commande. Eh bien, comment pouvons-nous, par exemple, organiser notre vie, la structurer pour le travail, le repos, le sommeil, etc.
Si nous parlons de périphériques de stockage, le planificateur d'E / S est responsable de l'organisation de leur travail au sein du noyau. Ce n'est qu'un code de programme qui définit un moyen de contrôler le flux de données pour les périphériques de bloc, allant des lecteurs flash USB et des disques durs aux disques virtuels, qui sont en fait des fichiers quelque part sur les périphériques ISCI dans un SAN.
Et en plus de tous ces appareils qui peuvent être utilisés sous Linux, il y a diverses tâches qu'un ordinateur doit effectuer. De plus, dans la vraie vie, il y a ce que nous appelons chez Red Hat des «cas d'utilisation». C'est pourquoi il existe différents planificateurs axés sur différents scénarios. Ces ordonnanceurs sont appelés noop, date limite et cfq. En bref, chacun d'eux peut être décrit comme suit:
- Noop - bien adapté pour les périphériques de stockage en bloc qui n'ont pas de pièces rotatives (flash, ssd, etc.).
- Deadline est un planificateur léger axé sur la réduction des retards. Par défaut, il donne la priorité à la lecture au détriment de l'écriture, car la plupart des applications trébuchent sur la lecture.
- Cfq - axé sur la répartition équitable de la bande passante d'E / S à l'échelle du système. Et comme nous l'avons dit ci-dessus, c'est le seul planificateur qui prend en charge les options d'E / S relatives pour les groupes de contrôle.
Pour plus d'informations sur les planificateurs , consultez le Guide de réglage des performances de Red Hat Enterprise Linux 7.
Quelle était toute cette discussion sur les planificateurs? De plus, sur la plupart des ordinateurs, cfq n'est PAS UTILISÉ par défaut s'ils n'ont pas de disques SATA. Sans le savoir, vous pouvez modifier BlockIOWeight jusqu'à ce que vous deveniez bleu sans aucun effet. Malheureusement, systemd ne vous dira pas: «Désolé, vous essayez en vain de modifier ce paramètre. Cela ne fonctionnera pas car l'appareil utilise le mauvais programmateur. "
Alors, comment pouvez-vous découvrir cette fonctionnalité «intéressante»? Comme d'habitude, à partir de la documentation de cgroups dont nous avons parlé dans un article précédent. Il est toujours utile de vous familiariser avec celui-ci avant d'utiliser tel ou tel régulateur.
Nous passons au cas d'utilisation
Encore une fois, nous passons des mots généraux aux détails: permettez-moi de vous présenter M. Kryakin.
Il est engagé dans la restauration, et il a deux bases de données sur le serveur d'applications pour suivre les commandes. M. Kryakin insiste sur le fait que la base de données des commandes de plats de canard est beaucoup plus importante que la base des plats d'oie, car les oies sont des imposteurs sur le trône de la sauvagine.
Les deux bases de données sont configurées en tant que services et leurs fichiers d'unité ressemblent à ceci:
En fait, les scripts qui y sont appelés (duck.sh et goose.sh) ne font aucun travail réel dans la base de données, mais simulent uniquement la lecture et l'écriture à l'aide des boucles de commande dd. Les deux scripts utilisent le système de fichiers / database, qui se trouve sur son disque virtuel.
Lançons canard et oie et voyons où ils atterrissent dans la hiérarchie des groupes de contrôle:
Et maintenant, puisque nous connaissons les PID des processus dd, passons à la commande iotop pour voir ce qui se passe dans le sous-système de stockage:
Eh bien, 12-14 Mo / s ... pas rapide. Il semble que M. Kryakin n'ait pas beaucoup investi dans le système de stockage des données. Bien que nous ayons déjà posé des questions sur son adéquation, il n'y a donc pas grand-chose à surprendre.
Maintenant, nous regardons nos deux tâches: PID 3301 (oie) et PID 3300 (canard). Chacun utilise des E / S quelque part autour de 6 Mo / s. L'écran ci-dessus est un peu différent, mais en réalité, ils sautent constamment et, en moyenne, ces deux tâches partagent également la bande passante du périphérique de stockage.
M. Kryakin veut que le canard ait au moins 5 fois plus de bande passante d'E / S que l'oie, donc les commandes de canard sont toujours traitées en premier. Essayons d'utiliser le paramètre BlockIOWeight pour cela avec les commandes suivantes:
Nous regardons iotop et voyons que cela n'a pas fonctionné:
Vérifions le planificateur d'E / S pour le périphérique / dev / vdb:
Intéressant ... Nous essayons de changer le planificateur en cfq et rien ne vient de lui. Pourquoi?
Le fait est que notre système fonctionne sur une machine virtuelle KVM, et il s'avère qu'à partir de la version 7.1, le
planificateur ne peut plus
être modifié dans Red Hat Enterprise Linux. Et ce n'est pas un bug, mais une fonctionnalité liée à l'amélioration des mécanismes de travail avec les périphériques d'E / S virtualisés.
Mais ne désespérons pas. Nous avons deux autres paramètres qui peuvent être modifiés: BlockIOReadBandwidth et BlockIOWriteBandwidth fonctionnent au niveau du périphérique de bloc et ignorent le planificateur d'E / S. Puisque nous connaissons la bande passante de l'appareil / dev / vdb (quelque part autour de 14 Mo / s pour la réception et pour la sortie), limitant l'oie à 2 Mo / s, nous semblons être en mesure de répondre au souhait de M. Kryakin. Essayons:
Nous regardons: le PID 3426, alias goose, utilise maintenant des E / S quelque part autour de 2 Mo / s, et le PID 3425, c'est-à-dire du canard, pour presque tous les 14!
Hourra, nous avons fait ce que le client voulait, ce qui signifie que nous avons sauvé non seulement un certain nombre d'oies, mais aussi notre réputation de gourou Linux.