Rechercher

Surveillance et gestion de l'état et des performances du système

download PDF
Red Hat Enterprise Linux 9

Optimisation du débit, de la latence et de la consommation d'énergie du système

Red Hat Customer Content Services

Résumé

Surveiller et optimiser le débit, la latence et la consommation d'énergie de Red Hat Enterprise Linux 9 dans différents scénarios.

Rendre l'open source plus inclusif

Red Hat s'engage à remplacer les termes problématiques dans son code, sa documentation et ses propriétés Web. Nous commençons par ces quatre termes : master, slave, blacklist et whitelist. En raison de l'ampleur de cette entreprise, ces changements seront mis en œuvre progressivement au cours de plusieurs versions à venir. Pour plus de détails, voir le message de notre directeur technique Chris Wright.

Fournir un retour d'information sur la documentation de Red Hat

Nous apprécions vos commentaires sur notre documentation. Faites-nous savoir comment nous pouvons l'améliorer.

Soumettre des commentaires sur des passages spécifiques

  1. Consultez la documentation au format Multi-page HTML et assurez-vous que le bouton Feedback apparaît dans le coin supérieur droit après le chargement complet de la page.
  2. Utilisez votre curseur pour mettre en évidence la partie du texte que vous souhaitez commenter.
  3. Cliquez sur le bouton Add Feedback qui apparaît près du texte en surbrillance.
  4. Ajoutez vos commentaires et cliquez sur Submit.

Soumettre des commentaires via Bugzilla (compte requis)

  1. Connectez-vous au site Web de Bugzilla.
  2. Sélectionnez la version correcte dans le menu Version.
  3. Saisissez un titre descriptif dans le champ Summary.
  4. Saisissez votre suggestion d'amélioration dans le champ Description. Incluez des liens vers les parties pertinentes de la documentation.
  5. Cliquez sur Submit Bug.

Chapitre 1. Démarrer avec TuneD

En tant qu'administrateur système, vous pouvez utiliser l'application TuneD pour optimiser le profil de performance de votre système pour une variété de cas d'utilisation.

1.1. L'objectif de TuneD

TuneD est un service qui surveille votre système et optimise les performances sous certaines charges de travail. Le cœur de TuneD est profiles, qui adapte votre système à différents cas d'utilisation.

TuneD est distribué avec un certain nombre de profils prédéfinis pour des cas d'utilisation tels que :

  • Haut débit
  • Faible latence
  • Économie d'énergie

Il est possible de modifier les règles définies pour chaque profil et de personnaliser le réglage d'un appareil particulier. Lorsque vous passez à un autre profil ou que vous désactivez TuneD, toutes les modifications apportées aux paramètres du système par le profil précédent reviennent à leur état d'origine.

Vous pouvez également configurer TuneD pour qu'il réagisse aux changements d'utilisation des appareils et ajuste les paramètres afin d'améliorer les performances des appareils actifs et de réduire la consommation d'énergie des appareils inactifs.

1.2. Profils TuneD

L'analyse détaillée d'un système peut prendre beaucoup de temps. TuneD fournit un certain nombre de profils prédéfinis pour des cas d'utilisation typiques. Vous pouvez également créer, modifier et supprimer des profils.

Les profils fournis par TuneD sont répartis dans les catégories suivantes :

  • Profils d'économie d'énergie
  • Profils d'amélioration des performances

Les profils d'amélioration des performances comprennent des profils qui se concentrent sur les aspects suivants :

  • Faible latence pour le stockage et le réseau
  • Débit élevé pour le stockage et le réseau
  • Performances de la machine virtuelle
  • Performances des hôtes de virtualisation
Syntaxe de la configuration du profil

Le fichier tuned.conf peut contenir une section [main] et d'autres sections pour configurer les instances du plug-in. Cependant, toutes les sections sont facultatives.

Les lignes commençant par le signe dièse (#) sont des commentaires.

Ressources supplémentaires

  • tuned.conf(5) page de manuel.

1.3. Le profil TuneD par défaut

Lors de l'installation, le profil le mieux adapté à votre système est sélectionné automatiquement. Actuellement, le profil par défaut est sélectionné en fonction des règles personnalisables suivantes :

EnvironnementProfil par défautObjectif

Nœuds de calcul

throughput-performance

La meilleure performance en termes de débit

Machines virtuelles

virtual-guest

La meilleure performance. Si vous n'êtes pas intéressé par les meilleures performances, vous pouvez choisir le profil balanced ou powersave.

Autres cas

balanced

Performances et consommation d'énergie équilibrées

Ressources supplémentaires

  • tuned.conf(5) page de manuel.

1.4. Profils TuneD fusionnés

À titre expérimental, il est possible de sélectionner plusieurs profils à la fois. TuneD essaiera de les fusionner pendant le chargement.

En cas de conflit, les paramètres du dernier profil spécifié sont prioritaires.

Exemple 1.1. Faible consommation d'énergie dans un invité virtuel

L'exemple suivant optimise le système pour qu'il fonctionne dans une machine virtuelle afin d'obtenir les meilleures performances et le règle simultanément pour qu'il consomme peu d'énergie, la priorité étant la faible consommation d'énergie :

# tuned-adm profile virtual-guest powersave
Avertissement

La fusion est effectuée automatiquement sans vérifier si la combinaison de paramètres qui en résulte a un sens. Par conséquent, la fonction peut régler certains paramètres de manière opposée, ce qui peut être contre-productif : par exemple, régler le disque pour un débit élevé en utilisant le profil throughput-performance et régler simultanément le spindown du disque à la valeur basse par le profil spindown-disk.

Ressources supplémentaires

*tuned-adm man page. * tuned.conf(5) man page.

1.5. Emplacement des profils TuneD

TuneD stocke les profils dans les répertoires suivants :

/usr/lib/tuned/
Les profils spécifiques à la distribution sont stockés dans le répertoire. Chaque profil a son propre répertoire. Le profil consiste en un fichier de configuration principal appelé tuned.conf, et éventuellement d'autres fichiers, par exemple des scripts d'aide.
/etc/tuned/
Si vous devez personnaliser un profil, copiez le répertoire du profil dans le répertoire utilisé pour les profils personnalisés. S'il existe deux profils portant le même nom, c'est le profil personnalisé situé dans /etc/tuned/ qui est utilisé.

Ressources supplémentaires

  • tuned.conf(5) page de manuel.

1.6. Profils TuneD distribués avec RHEL

La liste suivante est une liste de profils qui sont installés avec TuneD sur Red Hat Enterprise Linux.

Note

Il peut y avoir des profils plus spécifiques à un produit ou des profils de tierce partie TuneD disponibles. Ces profils sont généralement fournis par des paquets RPM distincts.

balanced

Le profil d'économie d'énergie par défaut. Il se veut un compromis entre les performances et la consommation d'énergie. Il utilise l'auto-scaling et l'auto-tuning dans la mesure du possible. Le seul inconvénient est l'augmentation de la latence. Dans la version actuelle de TuneD, il active les plugins CPU, disque, audio et vidéo, et active le gouverneur de CPU conservative. L'option radeon_powersave utilise la valeur dpm-balanced si elle est prise en charge, sinon elle prend la valeur auto.

Il remplace l'attribut energy_performance_preference par le paramètre d'énergie normal. Il modifie également l'attribut scaling_governor policy en conservative ou powersave CPU governor.

powersave

Un profil pour des performances maximales en matière d'économie d'énergie. Il peut limiter les performances afin de minimiser la consommation d'énergie réelle. Dans la version actuelle de TuneD, il permet l'autosuspend USB, l'économie d'énergie WiFi et l'économie d'énergie Aggressive Link Power Management (ALPM) pour les adaptateurs hôtes SATA. Il planifie également l'économie d'énergie multicœur pour les systèmes à faible taux de réveil et active le gouverneur ondemand. Il active l'économie d'énergie audio AC97 ou, selon votre système, l'économie d'énergie HDA-Intel avec un délai de 10 secondes. Si votre système contient une carte graphique Radeon prise en charge avec KMS activé, le profil la configure en économie d'énergie automatique. Sur les ASUS Eee PC, un moteur Super Hybrid dynamique est activé.

Il remplace l'attribut energy_performance_preference par le paramètre d'énergie powersave ou power. Il modifie également l'attribut scaling_governor policy en ondemand ou powersave CPU governor.

Note

Dans certains cas, le profil balanced est plus efficace que le profil powersave.

Considérons qu'il y a une quantité définie de travail à effectuer, par exemple un fichier vidéo qui doit être transcodé. Votre machine peut consommer moins d'énergie si le transcodage est effectué à pleine puissance, car la tâche est terminée rapidement, la machine commence à tourner au ralenti et elle peut automatiquement passer à des modes d'économie d'énergie très efficaces. En revanche, si vous transcodez le fichier avec une machine bridée, la machine consomme moins d'énergie pendant le transcodage, mais le processus prend plus de temps et l'énergie totale consommée peut être plus élevée.

C'est pourquoi le profil balanced peut être une meilleure option.

throughput-performance

Profil de serveur optimisé pour un débit élevé. Il désactive les mécanismes d'économie d'énergie et active les paramètres sysctl qui améliorent le débit des disques et des entrées-sorties réseau. Le gouverneur de CPU est réglé sur performance.

Il transforme les attributs energy_performance_preference et scaling_governor en profil performance.

accelerator-performance
Le profil accelerator-performance contient les mêmes réglages que le profil throughput-performance. En outre, il verrouille le processeur sur des états C faibles afin que la latence soit inférieure à 100us. Cela permet d'améliorer les performances de certains accélérateurs, tels que les GPU.
latency-performance

Profil de serveur optimisé pour une faible latence. Il désactive les mécanismes d'économie d'énergie et active les paramètres sysctl qui améliorent la latence. Le gouverneur de CPU est réglé sur performance et le CPU est verrouillé sur les états de faible C (par PM QoS).

Il transforme les attributs energy_performance_preference et scaling_governor en profil performance.

network-latency

Un profil pour l'optimisation des réseaux à faible latence. Il est basé sur le profil latency-performance. Il désactive en outre les pages énormes transparentes et l'équilibrage NUMA, et règle plusieurs autres paramètres liés au réseau sur sysctl.

Il hérite du profil latency-performance qui transforme les attributs energy_performance_preference et scaling_governor en profil performance.

hpc-compute
Un profil optimisé pour le calcul à haute performance. Il est basé sur le profil latency-performance.
network-throughput

Un profil pour l'optimisation du débit des réseaux. Il est basé sur le profil throughput-performance. Il augmente en outre les tampons réseau du noyau.

Il hérite du profil latency-performance ou throughput-performance et transforme les attributs energy_performance_preference et scaling_governor en profil performance.

virtual-guest

Un profil conçu pour les machines virtuelles Red Hat Enterprise Linux 9 et les invités VMWare basé sur le profil throughput-performance qui, entre autres tâches, diminue l'échange de mémoire virtuelle et augmente les valeurs d'avance de lecture des disques. Il ne désactive pas les barrières de disque.

Il hérite du profil throughput-performance et remplace les attributs energy_performance_preference et scaling_governor par le profil performance.

virtual-host

Profil conçu pour les hôtes virtuels sur la base du profil throughput-performance qui, entre autres tâches, diminue la permutation de la mémoire virtuelle, augmente les valeurs d'avance de lecture des disques et permet une valeur plus agressive de l'écriture des pages sales.

Il hérite du profil throughput-performance et remplace les attributs energy_performance_preference et scaling_governor par le profil performance.

oracle
Un profil optimisé pour les chargements de bases de données Oracle basé sur le profil throughput-performance. Il désactive en outre les pages énormes transparentes et modifie d'autres paramètres du noyau liés aux performances. Ce profil est fourni par le paquetage tuned-profiles-oracle.
desktop
Profil optimisé pour les ordinateurs de bureau, basé sur le profil balanced. Il permet en outre des autogroupes de planificateurs pour une meilleure réponse des applications interactives.
optimize-serial-console

Un profil qui réduit l'activité des E/S vers la console série en réduisant la valeur de printk. Cela devrait rendre la console série plus réactive. Ce profil est destiné à être utilisé en superposition à d'autres profils. Par exemple :

# tuned-adm profile throughput-performance optimize-serial-console
mssql
Un profil fourni pour Microsoft SQL Server. Il est basé sur le profil throughput-performance.
intel-sst

Profil optimisé pour les systèmes avec des configurations Intel Speed Select Technology définies par l'utilisateur. Ce profil est destiné à être utilisé en superposition à d'autres profils. Par exemple :

# tuned-adm profile cpu-partitioning intel-sst

1.7. Profil de partitionnement du processeur TuneD

Pour régler Red Hat Enterprise Linux 9 pour les charges de travail sensibles à la latence, Red Hat recommande d'utiliser le profil cpu-partitioning TuneD.

Avant Red Hat Enterprise Linux 9, la documentation Red Hat sur les faibles temps de latence décrivait les nombreuses étapes de bas niveau nécessaires à l'obtention d'un réglage des faibles temps de latence. Dans Red Hat Enterprise Linux 9, vous pouvez effectuer un réglage de faible latence plus efficacement en utilisant le profil cpu-partitioning TuneD. Ce profil est facilement personnalisable en fonction des exigences des applications individuelles à faible latence.

La figure suivante est un exemple d'utilisation du profil cpu-partitioning. Cet exemple utilise la disposition de l'unité centrale et des nœuds.

Figure 1.1. Figure partitionnement du processeur

cpu partitioning

Vous pouvez configurer le profil de partitionnement du processeur dans le fichier /etc/tuned/cpu-partitioning-variables.conf à l'aide des options de configuration suivantes :

CPU isolés avec répartition de la charge

Dans la figure de partitionnement des processeurs, les blocs numérotés de 4 à 23 sont les processeurs isolés par défaut. L'équilibrage de la charge des processus de l'ordonnanceur du noyau est activé sur ces CPU. Il est conçu pour les processus à faible latence avec plusieurs threads qui ont besoin de l'équilibrage de la charge du planificateur du noyau.

Vous pouvez configurer le profil de partitionnement des processeurs dans le fichier /etc/tuned/cpu-partitioning-variables.conf à l'aide de l'option isolated_cores=cpu-list, qui répertorie les processeurs à isoler qui utiliseront l'équilibrage de charge de l'ordonnanceur du noyau.

La liste des unités centrales isolées est séparée par des virgules ou vous pouvez spécifier une plage à l'aide d'un tiret, comme 3-5. Cette option est obligatoire. Toute unité centrale absente de cette liste est automatiquement considérée comme une unité centrale de maintenance.

CPU isolés sans répartition de la charge

Dans la figure de partitionnement des CPU, les blocs numérotés 2 et 3 sont les CPU isolés qui ne fournissent pas d'équilibrage supplémentaire de la charge des processus de l'ordonnanceur du noyau.

Vous pouvez configurer le profil de partitionnement des processeurs dans le fichier /etc/tuned/cpu-partitioning-variables.conf à l'aide de l'option no_balance_cores=cpu-list, qui répertorie les processeurs à isoler qui n'utiliseront pas l'équilibrage de charge de l'ordonnanceur du noyau.

La spécification de l'option no_balance_cores est facultative, mais tous les processeurs de cette liste doivent être un sous-ensemble des processeurs figurant dans la liste isolated_cores.

Les threads d'application qui utilisent ces CPU doivent être épinglés individuellement à chaque CPU.

Unité centrale d'entretien
Toute unité centrale qui n'est pas isolée dans le fichier cpu-partitioning-variables.conf est automatiquement considérée comme une unité centrale de maintenance. Sur ces unités centrales, tous les services, démons, processus utilisateur, threads mobiles du noyau, gestionnaires d'interruption et temporisateurs du noyau sont autorisés à s'exécuter.

Ressources supplémentaires

  • tuned-profiles-cpu-partitioning(7) page de manuel

1.8. Utilisation du profil de partitionnement du processeur TuneD pour un réglage à faible latence

Cette procédure décrit comment régler un système pour une faible latence en utilisant le profil cpu-partitioning de TuneD. Elle utilise l'exemple d'une application à faible latence qui peut utiliser cpu-partitioning et la disposition du processeur comme indiqué dans la figure de partitionnement du processeur.

Dans ce cas, l'application utilise :

  • Un thread de lecture dédié, qui lit les données du réseau, sera placé sur l'unité centrale 2.
  • Un grand nombre de threads qui traitent ces données réseau seront épinglés sur les CPU 4-23.
  • Un thread d'écriture dédié qui écrit les données traitées sur le réseau sera placé sur l'unité centrale 3.

Conditions préalables

  • Vous avez installé le profil TuneD cpu-partitioning en utilisant la commande dnf install tuned-profiles-cpu-partitioning en tant que root.

Procédure

  1. Modifiez le fichier /etc/tuned/cpu-partitioning-variables.conf et ajoutez les informations suivantes :

    # Isolated CPUs with the kernel’s scheduler load balancing:
    isolated_cores=2-23
    # Isolated CPUs without the kernel’s scheduler load balancing:
    no_balance_cores=2,3
  2. Définir le profil cpu-partitioning TuneD :

    # tuned-adm profile cpu-partitioning
  3. Reboot

    Après le redémarrage, le système est réglé pour une faible latence, conformément à l'isolation dans la figure de partitionnement des processeurs. L'application peut utiliser taskset pour affecter les threads de lecture et d'écriture aux CPU 2 et 3, et les threads d'application restants aux CPU 4 à 23.

Ressources supplémentaires

  • tuned-profiles-cpu-partitioning(7) page de manuel

1.9. Personnalisation du profil TuneD de partitionnement du processeur

Vous pouvez étendre le profil TuneD pour apporter des modifications supplémentaires à l'accord.

Par exemple, le profil cpu-partitioning configure les unités centrales pour qu'elles utilisent cstate=1. Afin d'utiliser le profil cpu-partitioning mais de changer en plus l'état c du CPU de cstate1 à cstate0, la procédure suivante décrit un nouveau profil TuneD nommé my_profile, qui hérite du profil cpu-partitioning et définit ensuite l'état C-0.

Procédure

  1. Créez le répertoire /etc/tuned/my_profile:

    # mkdir /etc/tuned/my_profile
  2. Créez un fichier tuned.conf dans ce répertoire et ajoutez-y le contenu suivant :

    # vi /etc/tuned/my_profile/tuned.conf
    [main]
    summary=Customized tuning on top of cpu-partitioning
    include=cpu-partitioning
    [cpu]
    force_latency=cstate.id:0|1
  3. Utiliser le nouveau profil :

    # tuned-adm profile my_profile
Note

Dans l'exemple partagé, un redémarrage n'est pas nécessaire. Toutefois, si les modifications apportées au profil my_profile nécessitent un redémarrage pour être prises en compte, redémarrez votre machine.

Ressources supplémentaires

  • tuned-profiles-cpu-partitioning(7) page de manuel

1.10. Profils TuneD en temps réel distribués avec RHEL

Les profils temps réel sont destinés aux systèmes utilisant le noyau temps réel. Sans une compilation spéciale du noyau, ils ne configurent pas le système pour qu'il soit en temps réel. Sur RHEL, les profils sont disponibles dans des dépôts supplémentaires.

Les profils en temps réel suivants sont disponibles :

realtime

Utilisation sur des systèmes temps réel nus.

Fourni par le paquetage tuned-profiles-realtime, qui est disponible dans les dépôts RT ou NFV.

realtime-virtual-host

Utilisation dans un hôte de virtualisation configuré pour le temps réel.

Fourni par le paquetage tuned-profiles-nfv-host, qui est disponible dans le référentiel NFV.

realtime-virtual-guest

Utilisation dans un invité de virtualisation configuré pour le temps réel.

Fourni par le paquetage tuned-profiles-nfv-guest, qui est disponible dans le référentiel NFV.

1.11. Accord statique et dynamique dans TuneD

Il est important de comprendre la différence entre les deux catégories de réglage de système que TuneD applique, static et dynamic, pour déterminer laquelle utiliser pour une situation ou un objectif donné.

Accord statique
Il s'agit principalement de l'application de paramètres prédéfinis sysctl et sysfs et de l'activation ponctuelle de plusieurs outils de configuration tels que ethtool.
Accord dynamique

Surveille la façon dont les différents composants du système sont utilisés tout au long de la durée de fonctionnement de votre système. TuneD ajuste les paramètres du système de façon dynamique sur la base de ces informations de surveillance.

Par exemple, le disque dur est fortement sollicité lors du démarrage et de la connexion, mais il est à peine utilisé par la suite, lorsque l'utilisateur travaille principalement avec des applications telles que des navigateurs web ou des clients de messagerie. De même, l'unité centrale et les périphériques réseau sont utilisés différemment selon les moments. TuneD surveille l'activité de ces composants et réagit aux changements dans leur utilisation.

Par défaut, l'optimisation dynamique est désactivée. Pour l'activer, modifiez le fichier /etc/tuned/tuned-main.conf et remplacez l'option dynamic_tuning par 1. TuneD analyse alors périodiquement les statistiques du système et les utilise pour mettre à jour les paramètres de réglage de votre système. Pour configurer l'intervalle de temps en secondes entre ces mises à jour, utilisez l'option update_interval.

Les algorithmes de réglage dynamique actuellement mis en œuvre tentent d'équilibrer les performances et l'économie d'énergie, et sont donc désactivés dans les profils de performance. L'accord dynamique pour les plug-ins individuels peut être activé ou désactivé dans les profils TuneD.

Exemple 1.2. Accord statique et dynamique sur un poste de travail

Sur un poste de travail de bureau classique, l'interface réseau Ethernet est inactive la plupart du temps. Seuls quelques courriers électroniques entrent et sortent ou quelques pages web peuvent être chargées.

Pour ce type de charge, l'interface réseau n'a pas besoin de tourner à plein régime en permanence, comme c'est le cas par défaut. TuneD dispose d'un plug-in de surveillance et de réglage pour les périphériques réseau qui peut détecter cette faible activité et réduire automatiquement la vitesse de l'interface, ce qui se traduit généralement par une réduction de la consommation d'énergie.

Si l'activité sur l'interface augmente pendant une période prolongée, par exemple parce qu'une image de DVD est téléchargée ou qu'un e-mail contenant une pièce jointe volumineuse est ouvert, TuneD le détecte et règle la vitesse de l'interface au maximum afin d'offrir les meilleures performances lorsque le niveau d'activité est élevé.

Ce principe est également utilisé pour d'autres plug-ins pour l'unité centrale et les disques.

1.12. Mode TuneD sans démon

Vous pouvez exécuter TuneD en mode no-daemon, qui ne nécessite pas de mémoire résidente. Dans ce mode, TuneD applique les paramètres et se termine.

Par défaut, le mode no-daemon est désactivé car de nombreuses fonctionnalités de TuneD sont absentes dans ce mode, notamment :

  • Support D-Bus
  • Prise en charge de la connexion à chaud
  • Prise en charge du retour en arrière pour les paramètres

Pour activer le mode no-daemon, incluez la ligne suivante dans le fichier /etc/tuned/tuned-main.conf:

daemon = 0

1.13. Installation et activation de TuneD

Cette procédure permet d'installer et d'activer l'application TuneD, d'installer les profils TuneD et de prédéfinir un profil TuneD par défaut pour votre système.

Procédure

  1. Installez le paquetage TuneD:

    # dnf install tuned
  2. Activez et démarrez le service TuneD:

    # systemctl enable --now tuned
  3. En option, installez les profils TuneD pour les systèmes en temps réel :

    Pour les profils TuneD pour les systèmes en temps réel, activez le référentiel rhel-9.

    # subscription-manager repos --enable=rhel-9-for-x86_64-nfv-beta-rpms

    Installez-le.

    # dnf install tuned-profiles-realtime tuned-profiles-nfv
  4. Vérifiez qu'un profil TuneD est actif et appliqué :

    $ tuned-adm active
    
    Current active profile: throughput-performance
    Note

    Le profil actif présélectionné automatiquement par TuneD diffère selon le type de machine et les paramètres du système.

    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

1.14. Liste des profils TuneD disponibles

Cette procédure dresse la liste de tous les profils TuneD actuellement disponibles sur votre système.

Procédure

  • Pour dresser la liste de tous les profils TuneD disponibles sur votre système, utilisez la touche

    $ tuned-adm list
    
    Available profiles:
    - accelerator-performance - Throughput performance based tuning with disabled higher latency STOP states
    - balanced                - General non-specialized TuneD profile
    - desktop                 - Optimize for the desktop use-case
    - latency-performance     - Optimize for deterministic performance at the cost of increased power consumption
    - network-latency         - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
    - network-throughput      - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
    - powersave               - Optimize for low power consumption
    - throughput-performance  - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
    - virtual-guest           - Optimize for running inside a virtual guest
    - virtual-host            - Optimize for running KVM guests
    Current active profile: balanced
  • Pour n'afficher que le profil actuellement actif, utilisez :

    $ tuned-adm active
    
    Current active profile: throughput-performance

Ressources supplémentaires

  • tuned-adm(8) page de manuel.

1.15. Définition d'un profil TuneD

Cette procédure permet d'activer un profil TuneD sélectionné sur votre système.

Conditions préalables

Procédure

  1. En option, vous pouvez laisser TuneD vous recommander le profil le plus adapté à votre système :

    # tuned-adm recommend
    
    throughput-performance
  2. Activer un profil :

    # tuned-adm profile selected-profile

    Vous pouvez également activer une combinaison de plusieurs profils :

    # tuned-adm profile selected-profile1 selected-profile2

    Exemple 1.3. Une machine virtuelle optimisée pour une faible consommation d'énergie

    L'exemple suivant permet d'optimiser le système pour qu'il fonctionne dans une machine virtuelle offrant les meilleures performances et de le régler simultanément pour qu'il consomme peu d'énergie, la priorité étant de consommer peu d'énergie :

    # tuned-adm profile virtual-guest powersave
  3. Affichez le profil TuneD actuellement actif sur votre système :

    # tuned-adm active
    
    Current active profile: selected-profile
  4. Redémarrer le système :

    # reboot

Verification steps

  • Vérifiez que le profil TuneD est actif et appliqué :

    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

Ressources supplémentaires

  • tuned-adm(8) page de manuel

1.16. Désactivation de TuneD

Cette procédure désactive TuneD et réinitialise tous les paramètres système concernés à leur état d'origine avant que TuneD ne les modifie.

Procédure

  • Pour désactiver temporairement tous les réglages :

    # tuned-adm off

    Les réglages sont de nouveau appliqués après le redémarrage du service TuneD.

  • Il est également possible d'arrêter et de désactiver définitivement le service TuneD:

    # systemctl disable --now tuned

Ressources supplémentaires

  • tuned-adm(8) page de manuel

Chapitre 2. Personnalisation des profils TuneD

Vous pouvez créer ou modifier les profils TuneD afin d'optimiser les performances du système en fonction de l'utilisation que vous souhaitez en faire.

Conditions préalables

2.1. Profils TuneD

L'analyse détaillée d'un système peut prendre beaucoup de temps. TuneD fournit un certain nombre de profils prédéfinis pour des cas d'utilisation typiques. Vous pouvez également créer, modifier et supprimer des profils.

Les profils fournis par TuneD sont répartis dans les catégories suivantes :

  • Profils d'économie d'énergie
  • Profils d'amélioration des performances

Les profils d'amélioration des performances comprennent des profils qui se concentrent sur les aspects suivants :

  • Faible latence pour le stockage et le réseau
  • Débit élevé pour le stockage et le réseau
  • Performances de la machine virtuelle
  • Performances des hôtes de virtualisation
Syntaxe de la configuration du profil

Le fichier tuned.conf peut contenir une section [main] et d'autres sections pour configurer les instances du plug-in. Cependant, toutes les sections sont facultatives.

Les lignes commençant par le signe dièse (#) sont des commentaires.

Ressources supplémentaires

  • tuned.conf(5) page de manuel.

2.2. Le profil TuneD par défaut

Lors de l'installation, le profil le mieux adapté à votre système est sélectionné automatiquement. Actuellement, le profil par défaut est sélectionné en fonction des règles personnalisables suivantes :

EnvironnementProfil par défautObjectif

Nœuds de calcul

throughput-performance

La meilleure performance en termes de débit

Machines virtuelles

virtual-guest

La meilleure performance. Si vous n'êtes pas intéressé par les meilleures performances, vous pouvez choisir le profil balanced ou powersave.

Autres cas

balanced

Performances et consommation d'énergie équilibrées

Ressources supplémentaires

  • tuned.conf(5) page de manuel.

2.3. Profils TuneD fusionnés

À titre expérimental, il est possible de sélectionner plusieurs profils à la fois. TuneD essaiera de les fusionner pendant le chargement.

En cas de conflit, les paramètres du dernier profil spécifié sont prioritaires.

Exemple 2.1. Faible consommation d'énergie dans un invité virtuel

L'exemple suivant optimise le système pour qu'il fonctionne dans une machine virtuelle afin d'obtenir les meilleures performances et le règle simultanément pour qu'il consomme peu d'énergie, la priorité étant la faible consommation d'énergie :

# tuned-adm profile virtual-guest powersave
Avertissement

La fusion est effectuée automatiquement sans vérifier si la combinaison de paramètres qui en résulte a un sens. Par conséquent, la fonction peut régler certains paramètres de manière opposée, ce qui peut être contre-productif : par exemple, régler le disque pour un débit élevé en utilisant le profil throughput-performance et régler simultanément le spindown du disque à la valeur basse par le profil spindown-disk.

Ressources supplémentaires

*tuned-adm man page. * tuned.conf(5) man page.

2.4. Emplacement des profils TuneD

TuneD stocke les profils dans les répertoires suivants :

/usr/lib/tuned/
Les profils spécifiques à la distribution sont stockés dans le répertoire. Chaque profil a son propre répertoire. Le profil consiste en un fichier de configuration principal appelé tuned.conf, et éventuellement d'autres fichiers, par exemple des scripts d'aide.
/etc/tuned/
Si vous devez personnaliser un profil, copiez le répertoire du profil dans le répertoire utilisé pour les profils personnalisés. S'il existe deux profils portant le même nom, c'est le profil personnalisé situé dans /etc/tuned/ qui est utilisé.

Ressources supplémentaires

  • tuned.conf(5) page de manuel.

2.5. Héritage entre les profils TuneD

TuneD les profils peuvent être basés sur d'autres profils et ne modifier que certains aspects de leur profil parent.

La section [main] des profils TuneD reconnaît l'option include:

[main]
include=parent

Tous les paramètres du profil parent sont chargés dans le profil child. Dans les sections suivantes, le profil child peut remplacer certains paramètres hérités du profil parent ou ajouter de nouveaux paramètres qui ne sont pas présents dans le parent ou ajouter de nouveaux paramètres qui ne sont pas présents dans le profil.

Vous pouvez créer votre propre profil child dans le répertoire /etc/tuned/ sur la base d'un profil préinstallé dans /usr/lib/tuned/ avec seulement quelques paramètres ajustés.

Si le profil parent est mis à jour, par exemple après une mise à niveau de TuneD, les modifications sont répercutées dans le profil child.

Exemple 2.2. Un profil d'économie d'énergie basé sur un équilibre

Voici un exemple de profil personnalisé qui étend le profil balanced et définit la gestion agressive de l'alimentation des liens (ALPM) pour tous les appareils sur l'économie d'énergie maximale.

[main]
include=balanced

[scsi_host]
alpm=min_power

Ressources supplémentaires

  • tuned.conf(5) page de manuel

2.6. Accord statique et dynamique dans TuneD

Il est important de comprendre la différence entre les deux catégories de réglage de système que TuneD applique, static et dynamic, pour déterminer laquelle utiliser pour une situation ou un objectif donné.

Accord statique
Il s'agit principalement de l'application de paramètres prédéfinis sysctl et sysfs et de l'activation ponctuelle de plusieurs outils de configuration tels que ethtool.
Accord dynamique

Surveille la façon dont les différents composants du système sont utilisés tout au long de la durée de fonctionnement de votre système. TuneD ajuste les paramètres du système de façon dynamique sur la base de ces informations de surveillance.

Par exemple, le disque dur est fortement sollicité lors du démarrage et de la connexion, mais il est à peine utilisé par la suite, lorsque l'utilisateur travaille principalement avec des applications telles que des navigateurs web ou des clients de messagerie. De même, l'unité centrale et les périphériques réseau sont utilisés différemment selon les moments. TuneD surveille l'activité de ces composants et réagit aux changements dans leur utilisation.

Par défaut, l'optimisation dynamique est désactivée. Pour l'activer, modifiez le fichier /etc/tuned/tuned-main.conf et remplacez l'option dynamic_tuning par 1. TuneD analyse alors périodiquement les statistiques du système et les utilise pour mettre à jour les paramètres de réglage de votre système. Pour configurer l'intervalle de temps en secondes entre ces mises à jour, utilisez l'option update_interval.

Les algorithmes de réglage dynamique actuellement mis en œuvre tentent d'équilibrer les performances et l'économie d'énergie, et sont donc désactivés dans les profils de performance. L'accord dynamique pour les plug-ins individuels peut être activé ou désactivé dans les profils TuneD.

Exemple 2.3. Accord statique et dynamique sur un poste de travail

Sur un poste de travail de bureau classique, l'interface réseau Ethernet est inactive la plupart du temps. Seuls quelques courriers électroniques entrent et sortent ou quelques pages web peuvent être chargées.

Pour ce type de charge, l'interface réseau n'a pas besoin de tourner à plein régime en permanence, comme c'est le cas par défaut. TuneD dispose d'un plug-in de surveillance et de réglage pour les périphériques réseau qui peut détecter cette faible activité et réduire automatiquement la vitesse de l'interface, ce qui se traduit généralement par une réduction de la consommation d'énergie.

Si l'activité sur l'interface augmente pendant une période prolongée, par exemple parce qu'une image de DVD est téléchargée ou qu'un e-mail contenant une pièce jointe volumineuse est ouvert, TuneD le détecte et règle la vitesse de l'interface au maximum afin d'offrir les meilleures performances lorsque le niveau d'activité est élevé.

Ce principe est également utilisé pour d'autres plug-ins pour l'unité centrale et les disques.

2.7. Plug-ins TuneD

Les plug-ins sont des modules dans les profils TuneD que TuneD utilise pour surveiller ou optimiser différents dispositifs sur le système.

TuneD utilise deux types de plug-ins :

Surveillance des plug-ins

Les modules d'extension de surveillance sont utilisés pour obtenir des informations sur un système en cours d'exécution. La sortie des plug-ins de surveillance peut être utilisée par les plug-ins de réglage pour le réglage dynamique.

Les plug-ins de surveillance sont automatiquement instanciés chaque fois que leurs métriques sont nécessaires à l'un des plug-ins d'optimisation activés. Si deux plug-ins de réglage ont besoin des mêmes données, une seule instance du plug-in de surveillance est créée et les données sont partagées.

Plug-ins d'accordage
Chaque plug-in de réglage règle un sous-système individuel et prend plusieurs paramètres issus des profils TuneD. Chaque sous-système peut avoir plusieurs périphériques, tels que plusieurs CPU ou cartes réseau, qui sont gérés par des instances individuelles des plug-ins de réglage. Des paramètres spécifiques pour des périphériques individuels sont également pris en charge.
Syntaxe pour les plug-ins dans les profils TuneD

Les sections décrivant les instances de plug-in sont formatées de la manière suivante :

[NAME]
type=TYPE
devices=DEVICES
NAME
est le nom de l'instance du plug-in tel qu'il est utilisé dans les journaux. Il peut s'agir d'une chaîne arbitraire.
TYPE
est le type de plug-in d'accord.
DEVICES

est la liste des dispositifs gérés par cette instance de plug-in.

La ligne devices peut contenir une liste, un caractère de remplacement (*) et une négation (!). S'il n'y a pas de ligne devices, tous les dispositifs présents ou connectés ultérieurement sur le système de l'instance de plug-in sont pris en charge par l'instance de plug-in TYPE sont pris en charge par l'instance de plug-in. Cela revient à utiliser l'option devices=*.

Exemple 2.4. Correspondance entre les dispositifs de blocage et un plug-in

L'exemple suivant correspond à tous les périphériques de bloc commençant par sd, tels que sda ou sdb, et ne désactive pas les barrières sur ces périphériques :

[data_disk]
type=disk
devices=sd*
disable_barriers=false

L'exemple suivant fait correspondre tous les blocs à l'exception de sda1 et sda2:

[data_disk]
type=disk
devices=!sda1, !sda2
disable_barriers=false

Si aucune instance d'un plug-in n'est spécifiée, le plug-in n'est pas activé.

Si le plug-in prend en charge d'autres options, celles-ci peuvent également être spécifiées dans la section du plug-in. Si l'option n'est pas spécifiée et qu'elle n'a pas été spécifiée précédemment dans le plug-in inclus, la valeur par défaut est utilisée.

Syntaxe courte du plug-in

Si vous n'avez pas besoin de noms personnalisés pour l'instance du plug-in et qu'il n'y a qu'une seule définition de l'instance dans votre fichier de configuration, TuneD prend en charge la syntaxe courte suivante :

[TYPE]
devices=DEVICES

Dans ce cas, il est possible d'omettre la ligne type. L'instance est alors désignée par un nom, identique à celui du type. L'exemple précédent pourrait alors être réécrit en :

Exemple 2.5. Correspondance entre les dispositifs de blocage à l'aide de la syntaxe courte

[disk]
devices=sdb*
disable_barriers=false
Définitions contradictoires de plug-ins dans un profil

Si la même section est spécifiée plusieurs fois à l'aide de l'option include, les paramètres sont fusionnés. S'ils ne peuvent pas être fusionnés en raison d'un conflit, la dernière définition conflictuelle remplace les paramètres précédents. Si vous ne savez pas ce qui a été défini précédemment, vous pouvez utiliser l'option booléenne replace et lui attribuer la valeur true. Toutes les définitions précédentes portant le même nom sont alors écrasées et la fusion n'a pas lieu.

Vous pouvez également désactiver le plug-in en spécifiant l'option enabled=false. L'effet est le même que si l'instance n'avait jamais été définie. La désactivation du plug-in est utile si vous redéfinissez la définition précédente à partir de l'option include et que vous ne souhaitez pas que le plug-in soit actif dans votre profil personnalisé.

NOTE

TuneD inclut la possibilité d'exécuter n'importe quelle commande shell dans le cadre de l'activation ou de la désactivation d'un profil d'accord. Cela vous permet d'étendre les profils TuneD avec des fonctionnalités qui n'ont pas encore été intégrées dans TuneD.

Vous pouvez spécifier des commandes shell arbitraires à l'aide du plug-in script.

Ressources supplémentaires

  • tuned.conf(5) page de manuel

2.8. Plug-ins TuneD disponibles

Surveillance des plug-ins

Actuellement, les plug-ins de surveillance suivants sont mis en œuvre :

disk
Obtient la charge du disque (nombre d'opérations d'E/S) par périphérique et par intervalle de mesure.
net
Obtient la charge du réseau (nombre de paquets transférés) par carte réseau et par intervalle de mesure.
load
Obtient la charge de l'unité centrale par unité centrale et l'intervalle de mesure.
Plug-ins d'accordage

Actuellement, les plug-ins d'accord suivants sont mis en œuvre. Seuls certains de ces plug-ins mettent en œuvre l'accord dynamique. Les options prises en charge par les plug-ins sont également répertoriées :

cpu

Définit le gouverneur de CPU à la valeur spécifiée par l'option governor et modifie dynamiquement la latence d'accès direct à la mémoire (DMA) du CPU dans le cadre de la qualité de service de la gestion de l'énergie (PM QoS) en fonction de la charge du CPU.

Si la charge du CPU est inférieure à la valeur spécifiée par l'option load_threshold, la latence est fixée à la valeur spécifiée par l'option latency_high, sinon elle est fixée à la valeur spécifiée par latency_low.

Vous pouvez également forcer la latence à une valeur spécifique et l'empêcher de changer dynamiquement. Pour ce faire, réglez l'option force_latency sur la valeur de latence requise.

eeepc_she

Définit dynamiquement la vitesse du bus frontal (FSB) en fonction de la charge du processeur.

Cette fonction, que l'on retrouve sur certains netbooks, est également connue sous le nom de Super Hybrid Engine (SHE) d'ASUS.

Si la charge du CPU est inférieure ou égale à la valeur spécifiée par l'option load_threshold_powersave, le plug-in fixe la vitesse du FSB à la valeur spécifiée par l'option she_powersave. Si la charge du CPU est supérieure ou égale à la valeur spécifiée par l'option load_threshold_normal, il fixe la vitesse du FSB à la valeur spécifiée par l'option she_normal.

L'accord statique n'est pas pris en charge et le plug-in est désactivé de manière transparente si TuneD ne détecte pas la prise en charge matérielle de cette fonctionnalité.

net
Configure la fonctionnalité Wake-on-LAN aux valeurs spécifiées par l'option wake_on_lan. Il utilise la même syntaxe que l'utilitaire ethtool. Il modifie aussi dynamiquement la vitesse de l'interface en fonction de son utilisation.
sysctl

Définit divers paramètres sysctl spécifiés par les options du plug-in.

La syntaxe est la suivante name=valuename est identique au nom fourni par l'utilitaire sysctl.

Utilisez le plug-in sysctl si vous devez modifier des paramètres du système qui ne sont pas couverts par d'autres plug-ins disponibles dans TuneD. Si les paramètres sont couverts par certains plug-ins spécifiques, préférez ces plug-ins.

usb

Définit le délai de suspension automatique des périphériques USB à la valeur spécifiée par le paramètre autosuspend.

La valeur 0 signifie que la suspension automatique est désactivée.

vm

Active ou désactive les grandes pages transparentes en fonction de la valeur de l'option transparent_hugepages.

Les valeurs valides de l'option transparent_hugepages sont les suivantes :

  • \toujours"
  • \Jamais
  • "madvise"
audio

Définit le délai de suspension automatique pour les codecs audio à la valeur spécifiée par l'option timeout.

Actuellement, les codecs snd_hda_intel et snd_ac97_codec sont pris en charge. La valeur 0 signifie que la suspension automatique est désactivée. Vous pouvez également imposer la réinitialisation du contrôleur en définissant l'option booléenne reset_controller sur true.

disk

Définit l'ascenseur de disque à la valeur spécifiée par l'option elevator.

Il fixe également :

  • APM à la valeur spécifiée par l'option apm
  • Quantum de l'ordonnanceur à la valeur spécifiée par l'option scheduler_quantum
  • Délai d'attente du disque à la valeur spécifiée par l'option spindown
  • La valeur de l'avance de lecture du disque est fixée à la valeur spécifiée par le paramètre readahead
  • L'avance de lecture actuelle du disque à une valeur multipliée par la constante spécifiée par l'option readahead_multiply

En outre, ce plug-in modifie dynamiquement les paramètres de gestion avancée de l'énergie et de temporisation du variateur en fonction de l'utilisation actuelle du variateur. Le réglage dynamique peut être contrôlé par l'option booléenne dynamic et est activé par défaut.

scsi_host

Ajuste les options pour les hôtes SCSI.

Il définit la gestion agressive de l'alimentation de la liaison (ALPM) à la valeur spécifiée par l'option alpm.

mounts
Active ou désactive les barrières pour les montages en fonction de la valeur booléenne de l'option disable_barriers.
script

Exécute un script ou un binaire externe lorsque le profil est chargé ou déchargé. Vous pouvez choisir un exécutable arbitraire.

Important

Le plug-in script est fourni principalement à des fins de compatibilité avec les versions antérieures. Préférez d'autres plug-ins TuneD s'ils couvrent les fonctionnalités requises.

TuneD appelle l'exécutable avec l'un des arguments suivants :

  • start lors du chargement du profil
  • stop lors du déchargement du profil

Vous devez mettre en œuvre correctement l'action stop dans votre exécutable et annuler tous les paramètres que vous avez modifiés au cours de l'action start. Sinon, l'étape de retour en arrière après avoir modifié votre profil TuneD ne fonctionnera pas.

Les scripts Bash peuvent importer la bibliothèque Bash /usr/lib/tuned/functions et utiliser les fonctions qui y sont définies. N'utilisez ces fonctions que pour des fonctionnalités qui ne sont pas fournies de manière native par TuneD. Si le nom d'une fonction commence par un trait de soulignement, comme _wifi_set_power_level, considérez la fonction comme privée et ne l'utilisez pas dans vos scripts, car elle pourrait changer à l'avenir.

Spécifiez le chemin d'accès à l'exécutable à l'aide du paramètre script dans la configuration du plug-in.

Exemple 2.6. Exécuter un script Bash à partir d'un profil

Pour exécuter un script Bash nommé script.sh qui se trouve dans le répertoire du profil, utilisez :

[script]
script=${i:PROFILE_DIR}/script.sh
sysfs

Définit divers paramètres sysfs spécifiés par les options du plug-in.

La syntaxe est la suivante name=value, où name est le chemin d'accès sysfs à utiliser.

Utilisez ce plugin si vous devez modifier certains paramètres qui ne sont pas couverts par d'autres plugins. Préférez des plugins spécifiques s'ils couvrent les paramètres requis.

video

Définit différents niveaux d'économie d'énergie sur les cartes vidéo. Actuellement, seules les cartes Radeon sont prises en charge.

Le niveau d'économie d'énergie peut être spécifié à l'aide de l'option radeon_powersave. Les valeurs prises en charge sont les suivantes :

  • default
  • auto
  • low
  • mid
  • high
  • dynpm
  • dpm-battery
  • dpm-balanced
  • dpm-perfomance

Pour plus de détails, voir www.x.org. Notez que ce plug-in est expérimental et que l'option pourrait être modifiée dans les prochaines versions.

bootloader

Ajoute des options à la ligne de commande du noyau. Ce plug-in ne prend en charge que le chargeur de démarrage GRUB 2.

Un emplacement personnalisé non standard du fichier de configuration GRUB 2 peut être spécifié par l'option grub2_cfg_file.

Les options du noyau sont ajoutées à la configuration actuelle de GRUB et à ses modèles. Le système doit être redémarré pour que les options du noyau prennent effet.

Le passage à un autre profil ou l'arrêt manuel du service TuneD supprime les options supplémentaires. Si vous arrêtez ou redémarrez le système, les options du noyau persistent dans le fichier grub.cfg.

Les options du noyau peuvent être spécifiées par la syntaxe suivante :

cmdline=arg1 arg2 ... argN

Exemple 2.7. Modifier la ligne de commande du noyau

Par exemple, pour ajouter l'option de noyau quiet à un profil TuneD, incluez les lignes suivantes dans le fichier tuned.conf:

[bootloader]
cmdline=quiet

Voici un exemple de profil personnalisé qui ajoute l'option isolcpus=2 à la ligne de commande du noyau :

[bootloader]
cmdline=isolcpus=2

2.9. Variables dans les profils TuneD

Les variables se développent au moment de l'exécution lorsqu'un profil TuneD est activé.

L'utilisation des variables TuneD réduit la quantité de données à saisir dans les profils TuneD.

Il n'y a pas de variables prédéfinies dans les profils TuneD. Vous pouvez définir vos propres variables en créant la section [variables] dans un profil et en utilisant la syntaxe suivante :

[variables]

variable_name=value

Pour développer la valeur d'une variable dans un profil, utilisez la syntaxe suivante :

${variable_name}

Exemple 2.8. Isolation des cœurs de l'unité centrale à l'aide de variables

Dans l'exemple suivant, la variable ${isolated_cores} se développe en 1,2; le noyau démarre donc avec l'option isolcpus=1,2:

[variables]
isolated_cores=1,2

[bootloader]
cmdline=isolcpus=${isolated_cores}

Les variables peuvent être spécifiées dans un fichier séparé. Par exemple, vous pouvez ajouter les lignes suivantes à tuned.conf:

[variables]
include=/etc/tuned/my-variables.conf

[bootloader]
cmdline=isolcpus=${isolated_cores}

Si vous ajoutez l'option isolated_cores=1,2 au fichier /etc/tuned/my-variables.conf, le noyau démarre avec l'option isolcpus=1,2.

Ressources supplémentaires

  • tuned.conf(5) page de manuel

2.10. Fonctions intégrées dans les profils TuneD

Les fonctions intégrées se développent en cours d'exécution lorsqu'un profil TuneD est activé.

Vous pouvez :

  • Utiliser diverses fonctions intégrées avec des variables TuneD
  • Créer des fonctions personnalisées en Python et les ajouter à TuneD sous forme de plug-ins

Pour appeler une fonction, utilisez la syntaxe suivante :

${f :function_name:argument_1:argument_2}

Pour développer le chemin du répertoire où se trouvent le profil et le fichier tuned.conf, utilisez la fonction PROFILE_DIR, qui requiert une syntaxe spéciale :

${i:PROFILE_DIR}

Exemple 2.9. Isolation des cœurs de processeur à l'aide de variables et de fonctions intégrées

Dans l'exemple suivant, la variable ${non_isolated_cores} se développe en 0,3-5 et la fonction intégrée cpulist_invert est appelée avec l'argument 0,3-5:

[variables]
non_isolated_cores=0,3-5

[bootloader]
cmdline=isolcpus=${f:cpulist_invert:${non_isolated_cores}}

La fonction cpulist_invert inverse la liste des unités centrales. Pour une machine à 6 CPU, l'inversion est 1,2, et le noyau démarre avec l'option de ligne de commande isolcpus=1,2.

Ressources supplémentaires

  • tuned.conf(5) page de manuel

2.11. Fonctions intégrées disponibles dans les profils TuneD

Les fonctions intégrées suivantes sont disponibles dans tous les profils TuneD:

PROFILE_DIR
Renvoie le chemin du répertoire où se trouvent le profil et le fichier tuned.conf.
exec
Exécute un processus et renvoie sa sortie.
assertion
Compare deux arguments. S'ils sont do not match, la fonction enregistre le texte du premier argument et interrompt le chargement du profil.
assertion_non_equal
Compare deux arguments. S'ils sont match, la fonction enregistre le texte du premier argument et interrompt le chargement du profil.
kb2s
Convertit les kilo-octets en secteurs de disque.
s2kb
Convertit les secteurs du disque en kilo-octets.
strip
Crée une chaîne de caractères à partir de tous les arguments passés et supprime les espaces blancs en début et en fin de chaîne.
virt_check

Vérifie si TuneD s'exécute à l'intérieur d'une machine virtuelle (VM) ou sur du métal nu :

  • À l'intérieur d'une VM, la fonction renvoie le premier argument.
  • Sur le métal nu, la fonction renvoie le deuxième argument, même en cas d'erreur.
cpulist_invert
Inverse une liste d'unités centrales pour obtenir son complément. Par exemple, sur un système avec 4 CPU, numérotés de 0 à 3, l'inversion de la liste 0,2,3 est 1.
cpulist2hex
Convertit une liste de CPU en un masque de CPU hexadécimal.
cpulist2hex_invert
Convertit une liste de CPU en un masque de CPU hexadécimal et l'inverse.
hex2cpulist
Convertit un masque de CPU hexadécimal en une liste de CPU.
cpulist_online
Vérifie si les unités centrales de la liste sont en ligne. Renvoie la liste contenant uniquement les unités centrales en ligne.
cpulist_present
Vérifie si les unités centrales de la liste sont présentes. Renvoie la liste contenant uniquement les unités centrales présentes.
cpulist_unpack
Décompresse une liste de CPU sous la forme de 1-3,4 à 1,2,3,4.
cpulist_pack
Fournit une liste d'unités centrales sous la forme de 1,2,3,5 à 1-3,5.

2.12. Création de nouveaux profils TuneD

Cette procédure crée un nouveau profil TuneD avec des règles de performance personnalisées.

Conditions préalables

Procédure

  1. Dans le répertoire /etc/tuned/, créez un nouveau répertoire portant le même nom que le profil que vous souhaitez créer :

    # mkdir /etc/tuned/my-profile
  2. Dans le nouveau répertoire, créez un fichier nommé tuned.conf. Ajoutez-y une section [main] et des définitions de plug-ins, en fonction de vos besoins.

    Par exemple, voir la configuration du profil balanced:

    [main]
    summary=General non-specialized TuneD profile
    
    [cpu]
    governor=conservative
    energy_perf_bias=normal
    
    [audio]
    timeout=10
    
    [video]
    radeon_powersave=dpm-balanced, auto
    
    [scsi_host]
    alpm=medium_power
  3. Pour activer le profil, utilisez :

    # tuned-adm profile my-profile
  4. Vérifiez que le profil TuneD est actif et que les paramètres du système sont appliqués :

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

Ressources supplémentaires

  • tuned.conf(5) page de manuel

2.13. Modifier les profils TuneD existants

Cette procédure permet de créer un profil enfant modifié sur la base d'un profil TuneD existant.

Conditions préalables

Procédure

  1. Dans le répertoire /etc/tuned/, créez un nouveau répertoire portant le même nom que le profil que vous souhaitez créer :

    # mkdir /etc/tuned/modified-profile
  2. Dans le nouveau répertoire, créez un fichier nommé tuned.conf, et définissez la section [main] comme suit :

    [main]
    include=parent-profile

    Remplacer parent-profile par le nom du profil que vous modifiez.

  3. Inclure les modifications de votre profil.

    Exemple 2.10. Diminution de la permutation dans le profil débit-performance

    Pour utiliser les paramètres du profil throughput-performance et modifier la valeur de vm.swappiness à 5, au lieu de la valeur par défaut de 10, utilisez :

    [main]
    include=throughput-performance
    
    [sysctl]
    vm.swappiness=5
  4. Pour activer le profil, utilisez :

    # tuned-adm profile modified-profile
  5. Vérifiez que le profil TuneD est actif et que les paramètres du système sont appliqués :

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

Ressources supplémentaires

  • tuned.conf(5) page de manuel

2.14. Paramétrage du planificateur de disque à l'aide de TuneD

Cette procédure permet de créer et d'activer un profil TuneD qui définit un planificateur de disque donné pour les périphériques de bloc sélectionnés. Le paramètre persiste lors des redémarrages du système.

Dans les commandes et la configuration suivantes, remplacer :

  • device avec le nom du dispositif de blocage, par exemple sdf
  • selected-scheduler avec le planificateur de disque que vous souhaitez définir pour le périphérique, par exemple bfq

Conditions préalables

Procédure

  1. Facultatif : Sélectionnez un profil TuneD existant sur lequel votre profil sera basé. Pour obtenir une liste des profils disponibles, voir les profils TuneD distribués avec RHEL.

    Pour savoir quel profil est actuellement actif, utilisez :

    $ tuned-adm active
  2. Créez un nouveau répertoire qui contiendra votre profil TuneD:

    # mkdir /etc/tuned/my-profile
  3. Recherchez l'identifiant unique du système du bloc sélectionné :

    $ udevadm info --query=property --name=/dev/device | grep -E '(WWN|SERIAL)'
    
    ID_WWN=0x5002538d00000000_
    ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0
    ID_SERIAL_SHORT=20120501030900000
    Note

    La commande de cet exemple renverra toutes les valeurs identifiées par un World Wide Name (WWN) ou un numéro de série associé au dispositif de bloc spécifié. Bien qu'il soit préférable d'utiliser un WWN, celui-ci n'est pas toujours disponible pour un dispositif donné et toutes les valeurs renvoyées par la commande de l'exemple peuvent être utilisées comme device system unique ID.

  4. Créer le fichier de /etc/tuned/my-profile/tuned.conf fichier de configuration. Dans le fichier, définissez les options suivantes :

    1. Facultatif : Inclure un profil existant :

      [main]
      include=existing-profile
    2. Définir le planificateur de disque sélectionné pour le périphérique qui correspond à l'identifiant WWN :

      [disk]
      devices_udev_regex=IDNAME=device system unique id
      elevator=selected-scheduler

      Ici :

      • Remplacer IDNAME par le nom de l'identifiant utilisé (par exemple, ID_WWN).
      • Remplacer device system unique id par la valeur de l'identifiant choisi (par exemple, 0x5002538d00000000).

        Pour faire correspondre plusieurs appareils dans l'option devices_udev_regex, mettez les identifiants entre parenthèses et séparez-les par des barres verticales :

        devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
  5. Activez votre profil :

    # tuned-adm profile my-profile

Verification steps

  1. Vérifiez que le profil TuneD est actif et appliqué :

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See TuneD log file ('/var/log/tuned/tuned.log') for details.
  2. Lire le contenu du /sys/block/device/queue/scheduler fichier :

    # cat /sys/block/device/queue/scheduler
    
    [mq-deadline] kyber bfq none

    Dans le nom du fichier, remplacez device par le nom du bloc, par exemple sdc.

    Le planificateur actif est indiqué entre crochets ([]).

Ressources supplémentaires

Chapitre 3. Révision d'un système à l'aide de l'interface tuna

Utilisez l'outil tuna pour ajuster les paramètres de l'ordonnanceur, la priorité des threads, les gestionnaires d'IRQ et pour isoler les cœurs et les sockets de l'unité centrale. Tuna réduit la complexité des tâches de réglage.

L'outil tuna effectue les opérations suivantes :

  • Liste des unités centrales d'un système
  • Répertorie les demandes d'interruption (IRQ) en cours sur un système
  • Modifie les informations relatives à la politique et à la priorité sur les fils de discussion
  • Affiche les politiques et priorités actuelles d'un système

3.1. Installation de l'outil thon

L'outil tuna est conçu pour être utilisé sur un système en fonctionnement. Cela permet aux outils de mesure spécifiques à une application de voir et d'analyser les performances du système immédiatement après que des modifications ont été apportées.

Cette procédure décrit comment installer l'outil tuna.

Procédure

  • Installer l'outil tuna:

    # dnf install tuna

Verification steps

  • Voir les options CLI disponibles sur tuna:

    # tuna -h

Ressources supplémentaires

  • tuna(8) page de manuel

3.2. Visualisation de l'état du système à l'aide de l'outil tuna

Cette procédure décrit comment visualiser l'état du système à l'aide de l'outil d'interface de ligne de commande (CLI) tuna.

Conditions préalables

Procédure

  • Pour consulter les politiques et priorités actuelles :

    # tuna --show_threads
                thread
    pid   SCHED_ rtpri affinity             cmd
    1      OTHER     0      0,1            init
    2       FIFO    99        0     migration/0
    3      OTHER     0        0     ksoftirqd/0
    4       FIFO    99        0      watchdog/0
  • Pour visualiser un fil spécifique correspondant à un PID ou à un nom de commande :

    # tuna --threads=pid_or_cmd_list --show_threads

    L'argument pid_or_cmd_list est une liste de PID ou de noms de commande séparés par des virgules.

  • Pour régler les processeurs à l'aide de l'interface CLI de tuna, voir Réglage des processeurs à l'aide de l'outil tuna.
  • Pour régler les IRQ à l'aide de l'outil tuna, voir Réglage des IRQ à l'aide de l'outil tuna.
  • Pour enregistrer la configuration modifiée :

    # tuna --save=filename

    Cette commande ne sauvegarde que les threads du noyau en cours d'exécution. Les processus qui ne sont pas en cours d'exécution ne sont pas sauvegardés.

Ressources supplémentaires

  • tuna(8) page de manuel

3.3. Optimisation des processeurs à l'aide de l'outil tuna

Les commandes de l'outil tuna peuvent cibler des unités centrales individuelles.

En utilisant l'outil thon, vous pouvez

Isolate CPUs
Toutes les tâches exécutées sur l'unité centrale spécifiée se déplacent vers la prochaine unité centrale disponible. L'isolation d'une unité centrale la rend indisponible en la supprimant du masque d'affinité de tous les threads.
Include CPUs
Permet aux tâches de s'exécuter sur l'unité centrale spécifiée
Restore CPUs
Rétablit la configuration précédente de l'unité centrale spécifiée.

Cette procédure décrit comment régler les CPU à l'aide de l'interface CLI de tuna.

Conditions préalables

Procédure

  • Pour spécifier la liste des unités centrales devant être affectées par une commande :

    # tuna --cpus=cpu_list [command]

    L'argument cpu_list est une liste de numéros de CPU séparés par des virgules. Par exemple, --cpus=0,2. Les listes d'unités centrales peuvent également être spécifiées dans une plage, par exemple --cpus=”1-3qui sélectionnerait les unités centrales 1, 2 et 3.

    Pour ajouter une unité centrale spécifique à l'actuelle cpu_list, par exemple, utilisez --cpus= 0.

    Remplacer [command] par, par exemple, --isolate.

  • Pour isoler une unité centrale :

    # tuna --cpus=cpu_list --isolate
  • Pour inclure une unité centrale :

    # tuna --cpus=cpu_list --include
  • Pour utiliser un système à quatre processeurs ou plus, montrez comment faire en sorte que tous les threads ssh s'exécutent sur les unités centrales 0 et 1, et tous les threads http sur les unités centrales 2 et 3:

    # tuna --cpus=0,1 --threads=ssh\* \
    --move --cpus=2,3 --threads=http\* --move

    Cette commande permet d'effectuer les opérations suivantes de manière séquentielle :

    1. Sélectionne les unités centrales 0 et 1.
    2. Sélectionne tous les fils qui commencent par ssh.
    3. Déplace les threads sélectionnés vers les unités centrales sélectionnées. Tuna définit le masque d'affinité des threads commençant par ssh vers les CPU appropriés. Les CPU peuvent être exprimés numériquement par 0 et 1, en masque hexagonal par 0x3, ou en binaire par 11.
    4. Réinitialise la liste des unités centrales à 2 et 3.
    5. Sélectionne tous les fils qui commencent par http.
    6. Déplace les threads sélectionnés vers les unités centrales spécifiées. Tuna définit le masque d'affinité des threads commençant par http vers les unités centrales spécifiées. Les unités centrales peuvent être exprimées numériquement par 2 et 3, en masque hexagonal par 0xC, ou en binaire par 1100.

Verification steps

  • Affichez la configuration actuelle et vérifiez que les modifications ont été effectuées comme prévu :

    # tuna --threads=gnome-sc\* --show_threads \
    --cpus=0 --move --show_threads --cpus=1 \
    --move --show_threads --cpus=+0 --move --show_threads
    
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0      0,1     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0        0     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0        1     33997           58 gnome-screensav
                           thread       ctxt_switches
         pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       3861   OTHER     0      0,1     33997           58 gnome-screensav

    Cette commande permet d'effectuer les opérations suivantes de manière séquentielle :

    1. Sélectionne tous les fils qui commencent par les fils gnome-sc.
    2. Affiche les threads sélectionnés pour permettre à l'utilisateur de vérifier leur masque d'affinité et leur priorité RT.
    3. Sélectionne l'unité centrale 0.
    4. Déplace les threads gnome-sc vers l'unité centrale spécifiée, l'unité centrale 0.
    5. Affiche le résultat du déplacement.
    6. Réinitialise la liste des CPU à CPU 1.
    7. Déplace les threads gnome-sc vers l'unité centrale spécifiée, l'unité centrale 1.
    8. Affiche le résultat du déplacement.
    9. Ajoute l'unité centrale 0 à la liste des unités centrales.
    10. Déplace les threads gnome-sc vers les unités centrales spécifiées, les unités centrales 0 et 1.
    11. Affiche le résultat du déplacement.

Ressources supplémentaires

  • /proc/cpuinfo fichier
  • tuna(8) page de manuel

3.4. Réglage des IRQ à l'aide de l'outil tuna

Le fichier /proc/interrupts enregistre le nombre d'interruptions par IRQ, le type d'interruption et le nom du périphérique situé à cette IRQ.

Cette procédure décrit comment régler les IRQ à l'aide de l'outil tuna.

Conditions préalables

Procédure

  • Pour afficher les IRQ en cours et leur affinité :

    # tuna --show_irqs
    # users            affinity
    0 timer                   0
    1 i8042                   0
    7 parport0                0
  • Pour spécifier la liste des IRQ à affecter par une commande :

    # tuna --irqs=irq_list [command]

    L'argument irq_list est une liste de numéros d'IRQ ou de noms d'utilisateurs séparés par des virgules.

    Remplacer [command] par, par exemple, --spread.

  • Pour déplacer une interruption vers une unité centrale spécifiée :

    # tuna --irqs=128 --show_irqs
       # users            affinity
     128 iwlwifi           0,1,2,3
    
    # tuna --irqs=128 --cpus=3 --move

    Remplacez 128 par l'argument irq_list et 3 par l'argument cpu_list.

    L'argument cpu_list est une liste de numéros de CPU séparés par des virgules, par exemple, --cpus=0,2. Pour plus d'informations, voir Tuning CPUs using tuna tool.

Verification steps

  • Comparer l'état des IRQ sélectionnées avant et après le déplacement d'une interruption vers une unité centrale spécifiée :

    # tuna --irqs=128 --show_irqs
       # users            affinity
     128 iwlwifi                 3

Ressources supplémentaires

  • /procs/interrupts fichier
  • tuna(8) page de manuel

Chapitre 4. Surveillance des performances à l'aide des rôles système RHEL

En tant qu'administrateur système, vous pouvez utiliser le rôle système metrics RHEL pour surveiller les performances d'un système.

4.1. Préparation d'un nœud de contrôle et de nœuds gérés à l'utilisation des rôles système RHEL

Avant de pouvoir utiliser des rôles système RHEL individuels pour gérer des services et des paramètres, vous devez préparer le nœud de contrôle et les nœuds gérés.

4.1.1. Préparation d'un nœud de contrôle sur RHEL 9

Avant d'utiliser RHEL System Roles, vous devez configurer un nœud de contrôle. Ce système configure ensuite les hôtes gérés à partir de l'inventaire conformément aux playbooks.

Conditions préalables

  • RHEL 8.6 ou une version ultérieure est installée. Pour plus d'informations sur l'installation de RHEL, voir Effectuer une installation standard de RHEL 9.
  • Le système est enregistré sur le portail client.
  • Un abonnement Red Hat Enterprise Linux Server est attaché au système.
  • S'il est disponible dans votre compte Portail Client, un abonnement Ansible Automation Platform est attaché au système.

Procédure

  1. Installez le paquetage rhel-system-roles:

    [root@control-node]# dnf install rhel-system-roles

    Cette commande installe le paquet ansible-core en tant que dépendance.

    Note

    Dans RHEL 8.5 et les versions antérieures, les packages Ansible étaient fournis via Ansible Engine au lieu d'Ansible Core, et avec un niveau de support différent. N'utilisez pas Ansible Engine car les packages peuvent ne pas être compatibles avec le contenu d'automatisation Ansible dans RHEL 8.6 et les versions ultérieures. Pour plus d'informations, voir Étendue de la prise en charge du package Ansible Core inclus dans les référentiels AppStream RHEL 9 et RHEL 8.6 et versions ultérieures.

  2. Créez un utilisateur nommé ansible pour gérer et exécuter les playbooks :

    [root@control-node]# useradd ansible
  3. Passez à l'utilisateur nouvellement créé ansible:

    [root@control-node]# su - ansible

    Effectuez le reste de la procédure en tant qu'utilisateur.

  4. Créez une clé publique et une clé privée SSH :

    [ansible@control-node]$ ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/ansible/.ssh/id_rsa): <password>
    ...

    Utilisez l'emplacement par défaut proposé pour le fichier clé.

  5. Facultatif : Pour éviter qu'Ansible ne vous demande le mot de passe de la clé SSH à chaque fois que vous établissez une connexion, configurez un agent SSH.
  6. Créez le fichier ~/.ansible.cfg avec le contenu suivant :

    [defaults]
    inventory = /home/ansible/inventory
    remote_user = ansible
    
    [privilege_escalation]
    become = True
    become_method = sudo
    become_user = root
    become_ask_pass = True
    Note

    Les paramètres du fichier ~/.ansible.cfg ont une priorité plus élevée et remplacent les paramètres du fichier global /etc/ansible/ansible.cfg.

    Avec ces paramètres, Ansible effectue les actions suivantes :

    • Gère les hôtes dans le fichier d'inventaire spécifié.
    • Utilise le compte défini dans le paramètre remote_user lorsqu'il établit des connexions SSH avec les nœuds gérés.
    • Utilise l'utilitaire sudo pour exécuter des tâches sur les nœuds gérés en tant qu'utilisateur root.
    • Demande le mot de passe root de l'utilisateur distant à chaque fois que vous appliquez un playbook. Ceci est recommandé pour des raisons de sécurité.
  7. Créez un fichier ~/inventory au format INI ou YAML qui répertorie les noms d'hôtes gérés. Vous pouvez également définir des groupes d'hôtes dans le fichier d'inventaire. Par exemple, voici un fichier d'inventaire au format INI avec trois hôtes et un groupe d'hôtes nommé US:

    managed-node-01.example.com
    
    [US]
    managed-node-02.example.com ansible_host=192.0.2.100
    managed-node-03.example.com

    Notez que le nœud de contrôle doit être en mesure de résoudre les noms d'hôte. Si le serveur DNS ne peut pas résoudre certains noms d'hôtes, ajoutez le paramètre ansible_host à côté de l'entrée de l'hôte pour spécifier son adresse IP.

Prochaines étapes

4.1.2. Préparation d'un nœud géré

Les nœuds gérés sont les systèmes répertoriés dans l'inventaire et qui seront configurés par le nœud de contrôle conformément au cahier de jeu. Il n'est pas nécessaire d'installer Ansible sur les hôtes gérés.

Conditions préalables

  • Vous avez préparé le nœud de contrôle. Pour plus d'informations, voir Préparation d'un nœud de contrôle sur RHEL 9.
  • Vous disposez d'un accès SSH à partir du nœud de contrôle.

    Important

    L'accès SSH direct en tant qu'utilisateur root présente un risque pour la sécurité. Pour réduire ce risque, vous créerez un utilisateur local sur ce nœud et configurerez une politique sudo lors de la préparation d'un nœud géré. Ansible sur le nœud de contrôle peut alors utiliser le compte d'utilisateur local pour se connecter au nœud géré et exécuter des playbooks en tant qu'utilisateurs différents, tels que root.

Procédure

  1. Créez un utilisateur nommé ansible:

    [root@managed-node-01]# useradd ansible

    Le nœud de contrôle utilise ensuite cet utilisateur pour établir une connexion SSH avec cet hôte.

  2. Définir un mot de passe pour l'utilisateur ansible:

    [root@managed-node-01]# passwd ansible
    Changing password for user ansible.
    New password: <password>
    Retype new password: <password>
    passwd: all authentication tokens updated successfully.

    Vous devez saisir ce mot de passe lorsque Ansible utilise sudo pour effectuer des tâches en tant qu'utilisateur root.

  3. Installez la clé publique SSH de l'utilisateur ansible sur le nœud géré :

    1. Connectez-vous au nœud de contrôle en tant qu'utilisateur ansible et copiez la clé publique SSH sur le nœud géré :

      [ansible@control-node]$ ssh-copy-id managed-node-01.example.com
      /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/ansible/.ssh/id_rsa.pub"
      The authenticity of host 'managed-node-01.example.com (192.0.2.100)' can't be established.
      ECDSA key fingerprint is SHA256:9bZ33GJNODK3zbNhybokN/6Mq7hu3vpBXDrCxe7NAvo.
    2. Lorsque vous y êtes invité, connectez-vous en entrant yes:

      Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
      /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
    3. Lorsque vous y êtes invité, saisissez le mot de passe :

      ansible@managed-node-01.example.com's password: <password>
      
      Number of key(s) added: 1
      
      Now try logging into the machine, with:   "ssh '<managed-node-01.example.com>'"
      and check to make sure that only the key(s) you wanted were added.
    4. Vérifiez la connexion SSH en exécutant à distance une commande sur le nœud de contrôle :

      [ansible@control-node]$ ssh <managed-node-01.example.com> whoami
      ansible
  4. Créer une configuration sudo pour l'utilisateur ansible:

    1. Créez et modifiez le fichier /etc/sudoers.d/ansible à l'aide de la commande visudo:

      [root@managed-node-01]# visudo /etc/sudoers.d/ansible

      L'avantage d'utiliser visudo plutôt qu'un éditeur normal est que cet utilitaire fournit des contrôles de base et vérifie les erreurs d'analyse avant d'installer le fichier.

    2. Configurez une politique sudoers dans le fichier /etc/sudoers.d/ansible qui réponde à vos besoins, par exemple :

      • Pour autoriser l'utilisateur ansible à exécuter toutes les commandes en tant qu'utilisateur et groupe sur cet hôte après avoir saisi le mot de passe de l'utilisateur ansible, utilisez l'option suivante :

        ansible ALL=(ALL) ALL
      • Pour autoriser l'utilisateur ansible à exécuter toutes les commandes en tant qu'utilisateur et groupe sur cet hôte sans saisir le mot de passe de l'utilisateur ansible, utilisez la commande suivante

        ansible ALL=(ALL) NOPASSWD: ALL

    Vous pouvez également configurer une politique plus fine qui correspond à vos exigences en matière de sécurité. Pour plus d'informations sur les politiques de sudoers, voir la page de manuel sudoers(5).

Vérification

  1. Vérifiez que vous pouvez exécuter des commandes à partir du nœud de contrôle sur tous les nœuds gérés :

    [ansible@control-node]$ ansible all -m ping
    BECOME password: <password>
    managed-node-01.example.com | SUCCESS => {
        	"ansible_facts": {
        	    "discovered_interpreter_python": "/usr/bin/python3"
        	},
        	"changed": false,
        	"ping": "pong"
    }
    ...

    Le groupe all codé en dur contient dynamiquement tous les hôtes répertoriés dans le fichier d'inventaire.

  2. Vérifiez que l'escalade des privilèges fonctionne correctement en exécutant l'utilitaire whoami sur un hôte géré à l'aide du module Ansible command:

    [ansible@control-node]$ ansible managed-node-01.example.com -m command -a whoami
    BECOME password: <password>
    managed-node-01.example.com | CHANGED | rc=0 >>
    root

    Si la commande renvoie la valeur root, vous avez configuré correctement sudo sur les nœuds gérés.

Ressources supplémentaires

4.2. Introduction au rôle du système metrics

RHEL System Roles est une collection de rôles et de modules Ansible qui fournissent une interface de configuration cohérente pour gérer à distance plusieurs systèmes RHEL. Le rôle système metrics configure les services d'analyse des performances pour le système local et, en option, inclut une liste de systèmes distants à surveiller par le système local. Le rôle système metrics vous permet d'utiliser pcp pour surveiller les performances de vos systèmes sans avoir à configurer pcp séparément, car la configuration et le déploiement de pcp sont gérés par le playbook.

Tableau 4.1. metrics variables de rôle du système
Variable de rôleDescriptionExemple d'utilisation

métriques_hôtes_surveillés

Liste des hôtes distants à analyser par l'hôte cible. Ces hôtes auront des métriques enregistrées sur l'hôte cible, il faut donc s'assurer qu'il y a suffisamment d'espace disque sous /var/log pour chaque hôte.

metrics_monitored_hosts: ["webserver.example.com", "database.example.com"]

jours_de_métriques_de_rétention

Configure le nombre de jours de rétention des données de performance avant leur suppression.

metrics_retention_days: 14

service_graphique_métriques

Indicateur booléen qui permet à l'hôte d'être configuré avec des services de visualisation de données de performance via pcp et grafana. La valeur par défaut est false.

metrics_graph_service: no

metrics_query_service

Indicateur booléen qui permet à l'hôte d'être configuré avec des services d'interrogation de séries temporelles pour l'interrogation des mesures enregistrées sur pcp via redis. La valeur par défaut est false.

metrics_query_service: no

fournisseur de métriques

Spécifie le collecteur de métriques à utiliser pour fournir des métriques. Actuellement, pcp est le seul fournisseur de métriques pris en charge.

metrics_provider: "pcp"

metrics_manage_firewall

Utilise le rôle firewall pour gérer l'accès aux ports directement à partir du rôle metrics. La valeur par défaut est false.

metrics_manage_firewall: true

metrics_manage_selinux

Utilise le rôle selinux pour gérer l'accès aux ports directement à partir du rôle metrics. La valeur par défaut est false.

metrics_manage_selinux: true

Note

Pour plus de détails sur les paramètres utilisés dans metrics_connections et des informations supplémentaires sur le rôle de système metrics, voir le fichier /usr/share/ansible/roles/rhel-system-roles.metrics/README.md.

4.3. Utilisation du rôle de système metrics pour surveiller votre système local avec visualisation

Cette procédure décrit comment utiliser le rôle de système RHEL metrics pour surveiller votre système local tout en fournissant une visualisation des données via Grafana.

Conditions préalables

  • Le paquetage Ansible Core est installé sur la machine de contrôle.
  • Le paquetage rhel-system-roles est installé sur la machine que vous voulez surveiller.

Procédure

  1. Configurez localhost dans l'inventaire Ansible /etc/ansible/hosts en ajoutant le contenu suivant à l'inventaire :

    localhost ansible_connection=local
  2. Créez un playbook Ansible avec le contenu suivant :

    ---
    - name: Manage metrics
      hosts: localhost
      vars:
        metrics_graph_service: yes
        metrics_manage_firewall: true
        metrics_manage_selinux: true
      roles:
        - rhel-system-roles.metrics
  3. Exécutez le playbook Ansible :

    # ansible-playbook name_of_your_playbook.yml
    Note

    Comme le booléen metrics_graph_service est défini sur la valeur="yes", Grafana est automatiquement installé et provisionné avec pcp ajouté en tant que source de données. Comme metrics_manage_firewall et metrics_manage_selinux sont tous deux définis sur true, le rôle metrics utilisera les rôles système firewall et selinux pour gérer les ports utilisés par le rôle metrics.

  4. Pour visualiser les métriques collectées sur votre machine, accédez à l'interface web grafana comme décrit dans Accéder à l'interface web Grafana.

4.4. L'utilisation du rôle de système metrics permet de configurer un parc de systèmes individuels pour qu'ils se surveillent eux-mêmes

Cette procédure décrit comment utiliser le rôle de système metrics pour configurer une flotte de machines afin qu'elles se surveillent elles-mêmes.

Conditions préalables

  • Le paquetage Ansible Core est installé sur la machine de contrôle.
  • Le paquetage rhel-system-roles est installé sur la machine que vous souhaitez utiliser pour exécuter le playbook.
  • La connexion SSH est établie.

Procédure

  1. Ajoutez le nom ou l'IP des machines que vous souhaitez surveiller via le playbook au fichier d'inventaire Ansible /etc/ansible/hosts sous un nom de groupe d'identification entre parenthèses :

    [remotes]
    webserver.example.com
    database.example.com
  2. Créez un playbook Ansible avec le contenu suivant :

    ---
    - hosts: remotes
      vars:
        metrics_retention_days: 0
        metrics_manage_firewall: true
        metrics_manage_selinux: true
      roles:
        - rhel-system-roles.metrics
    Note

    Puisque metrics_manage_firewall et metrics_manage_selinux sont tous deux définis sur true, le rôle metrics utilisera les rôles firewall et selinux pour gérer les ports utilisés par le rôle metrics.

  3. Exécutez le playbook Ansible :

    # ansible-playbook name_of_your_playbook.yml -k

Lorsque le site -k demande un mot de passe pour se connecter au système distant.

4.5. Utilisation du rôle de système metrics pour surveiller un parc de machines de manière centralisée via votre machine locale

Cette procédure décrit comment utiliser le rôle de système metrics pour configurer votre machine locale afin de surveiller de manière centralisée un parc de machines, tout en prévoyant la visualisation des données via grafana et l'interrogation des données via redis.

Conditions préalables

  • Le paquetage Ansible Core est installé sur la machine de contrôle.
  • Le paquetage rhel-system-roles est installé sur la machine que vous souhaitez utiliser pour exécuter le playbook.

Procédure

  1. Créez un playbook Ansible avec le contenu suivant :

    ---
    - hosts: localhost
      vars:
        metrics_graph_service: yes
        metrics_query_service: yes
        metrics_retention_days: 10
        metrics_monitored_hosts: ["database.example.com", "webserver.example.com"]
        metrics_manage_firewall: yes
        metrics_manage_selinux: yes
      roles:
        - rhel-system-roles.metrics
  2. Exécutez le playbook Ansible :

    # ansible-playbook name_of_your_playbook.yml
    Note

    Étant donné que les booléens metrics_graph_service et metrics_query_service ont la valeur "yes", grafana est automatiquement installé et approvisionné avec pcp ajouté en tant que source de données, l'enregistrement des données pcp étant indexé dans redis, ce qui permet d'utiliser le langage d'interrogation pcp pour effectuer des requêtes complexes sur les données. Étant donné que metrics_manage_firewall et metrics_manage_selinux sont tous deux définis comme vrais, le rôle metrics utilisera les rôles firewall et selinux pour gérer les ports utilisés par le rôle metrics.

  3. Pour afficher une représentation graphique des métriques collectées de manière centralisée par votre machine et pour interroger les données, accédez à l'interface web grafana comme décrit dans Accéder à l'interface web Grafana.

4.6. Configuration de l'authentification lors de la surveillance d'un système à l'aide du rôle de système metrics

PCP prend en charge le mécanisme d'authentification scram-sha-256 par le biais du cadre SASL (Simple Authentication Security Layer). Le rôle système metrics RHEL automatise les étapes de configuration de l'authentification à l'aide du mécanisme d'authentification scram-sha-256. Cette procédure décrit comment configurer l'authentification à l'aide du rôle système metrics RHEL.

Conditions préalables

  • Le paquetage Ansible Core est installé sur la machine de contrôle.
  • Le paquetage rhel-system-roles est installé sur la machine que vous souhaitez utiliser pour exécuter le playbook.

Procédure

  1. Incluez les variables suivantes dans le playbook Ansible pour lequel vous souhaitez configurer l'authentification :

    ---
      vars:
        metrics_username: your_username
        metrics_password: your_password
        metrics_manage_firewall: true
        metrics_manage_selinux: true
    Note

    Puisque metrics_manage_firewall et metrics_manage_selinux sont tous deux définis sur true, le rôle metrics utilisera les rôles firewall et selinux pour gérer les ports utilisés par le rôle metrics.

  2. Exécutez le playbook Ansible :

    # ansible-playbook name_of_your_playbook.yml

Verification steps

  • Vérifiez la configuration de sasl:

    # pminfo -f -h "pcp://ip_adress?username=your_username" disk.dev.read
    Password:
    disk.dev.read
    inst [0 or "sda"] value 19540

    ip_adress doit être remplacé par l'adresse IP de l'hôte.

4.7. Utilisation du rôle de système metrics pour configurer et activer la collecte de métriques pour SQL Server

Cette procédure décrit comment utiliser le rôle système metrics RHEL pour automatiser la configuration et l'activation de la collecte de métriques pour Microsoft SQL Server via pcp sur votre système local.

Conditions préalables

Procédure

  1. Configurez localhost dans l'inventaire Ansible /etc/ansible/hosts en ajoutant le contenu suivant à l'inventaire :

    localhost ansible_connection=local
  2. Créez un playbook Ansible contenant les éléments suivants :

    ---
    - hosts: localhost
      vars:
       metrics_from_mssql: true
       metrics_manage_firewall: true
       metrics_manage_selinux: true
      roles:
       - role: rhel-system-roles.metrics
    Note

    Puisque metrics_manage_firewall et metrics_manage_selinux sont tous deux définis sur true, le rôle metrics utilisera les rôles firewall et selinux pour gérer les ports utilisés par le rôle metrics.

  3. Exécutez le playbook Ansible :

    # ansible-playbook name_of_your_playbook.yml

Verification steps

  • Utilisez la commande pcp pour vérifier que l'agent PMDA du serveur SQL (mssql) est chargé et en cours d'exécution :

    # pcp
    platform: Linux rhel82-2.local 4.18.0-167.el8.x86_64 #1 SMP Sun Dec 15 01:24:23 UTC 2019 x86_64
     hardware: 2 cpus, 1 disk, 1 node, 2770MB RAM
     timezone: PDT+7
     services: pmcd pmproxy
         pmcd: Version 5.0.2-1, 12 agents, 4 clients
         pmda: root pmcd proc pmproxy xfs linux nfsclient mmv kvm mssql
               jbd2 dm
     pmlogger: primary logger: /var/log/pcp/pmlogger/rhel82-2.local/20200326.16.31
         pmie: primary engine: /var/log/pcp/pmie/rhel82-2.local/pmie.log

Chapitre 5. Mise en place du PCP

Performance Co-Pilot (PCP) est une suite d'outils, de services et de bibliothèques permettant de surveiller, de visualiser, de stocker et d'analyser les mesures de performance au niveau du système.

5.1. Vue d'ensemble du PCP

Vous pouvez ajouter des mesures de performance à l'aide des interfaces Python, Perl, C et C. Les outils d'analyse peuvent utiliser directement les API client Python, C , C, et les applications web riches peuvent explorer toutes les données de performance disponibles à l'aide d'une interface JSON.

Vous pouvez analyser les modèles de données en comparant les résultats en temps réel avec les données archivées.

Caractéristiques du PCP :

  • Architecture distribuée légère, utile pour l'analyse centralisée de systèmes complexes.
  • Il permet le suivi et la gestion des données en temps réel.
  • Il permet d'enregistrer et d'extraire des données historiques.

Le PCP comprend les éléments suivants :

  • Le Performance Metric Collector Daemon (pmcd) collecte les données de performance à partir des Performance Metric Domain Agents (pmda) installés. PMDAs peut être chargé ou déchargé individuellement sur le système et est contrôlé par PMCD sur le même hôte.
  • Divers outils clients, tels que pminfo ou pmstat, peuvent récupérer, afficher, archiver et traiter ces données sur le même hôte ou sur le réseau.
  • Le paquetage pcp fournit les outils en ligne de commande et les fonctionnalités sous-jacentes.
  • Le paquetage pcp-gui fournit l'application graphique. Installez le paquetage pcp-gui en exécutant la commande dnf install pcp-gui. Pour plus d'informations, voir Tracer visuellement les archives de journaux PCP avec l'application PCP Charts.

5.2. Installation et activation de PCP

Pour commencer à utiliser PCP, installez tous les paquets nécessaires et activez les services de surveillance PCP.

Cette procédure décrit comment installer PCP à l'aide du paquetage pcp. Si vous souhaitez automatiser l'installation de PCP, installez-le à l'aide du paquetage pcp-zeroconf. Pour plus d'informations sur l'installation de PCP à l'aide de pcp-zeroconf, voir Configuration de PCP avec pcp-zeroconf.

Procédure

  1. Installez le paquetage pcp:

    # dnf install pcp
  2. Activez et démarrez le service pmcd sur la machine hôte :

    # systemctl enable pmcd
    
    # systemctl start pmcd

Verification steps

  • Vérifiez si le processus pmcd est en cours d'exécution sur l'hôte :

    # pcp
    
    Performance Co-Pilot configuration on workstation:
    
    platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64
    hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM
    timezone: CEST-2
    services: pmcd
    pmcd: Version 4.3.0-1, 8 agents
    pmda: root pmcd proc xfs linux mmv kvm jbd2

Ressources supplémentaires

5.3. Déployer une configuration PCP minimale

L'installation minimale de PCP permet de collecter des statistiques de performance sur Red Hat Enterprise Linux. L'installation consiste à ajouter le nombre minimum de paquets sur un système de production nécessaire pour collecter des données en vue d'une analyse plus approfondie.

Vous pouvez analyser le fichier tar.gz résultant et l'archive de la sortie pmlogger à l'aide de divers outils PCP et les comparer à d'autres sources d'informations sur les performances.

Conditions préalables

Procédure

  1. Mettre à jour la configuration de pmlogger:

    # pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
  2. Démarrez les services pmcd et pmlogger:

    # systemctl start pmcd.service
    
    # systemctl start pmlogger.service
  3. Exécutez les opérations nécessaires pour enregistrer les données de performance.
  4. Arrêtez les services pmcd et pmlogger:

    # systemctl stop pmcd.service
    
    # systemctl stop pmlogger.service
  5. Enregistrez la sortie et sauvegardez-la dans un fichier tar.gz dont le nom est basé sur le nom de l'hôte et sur la date et l'heure actuelles :

    # cd /var/log/pcp/pmlogger/
    
    # tar -czf $(hostname).$(date +%F-%Hh%M).pcp.tar.gz $(hostname)

    Extraire ce fichier et analyser les données à l'aide des outils PCP.

Ressources supplémentaires

5.4. Services système distribués avec PCP

Le tableau suivant décrit les rôles des différents services du système, qui sont distribués avec PCP.

Tableau 5.1. Rôles des services du système distribués avec le PCP

Nom

Description

pmcd

Le Performance Metric Collector Daemon (PMCD).

pmie

Le moteur d'inférence des mesures de performance.

pmlogger

L'enregistreur de mesures de performance.

pmproxy

Le proxy de mesures de performance en temps réel et historique, la requête de séries temporelles et le service API REST.

5.5. Outils distribués avec le PCP

Le tableau suivant décrit l'utilisation des différents outils fournis avec PCP.

Tableau 5.2. Utilisation des outils distribués avec le PCP

Nom

Description

pcp

Affiche l'état actuel de l'installation de Performance Co-Pilot.

pcp-atop

Montre l'occupation au niveau du système des ressources matérielles les plus critiques du point de vue des performances : CPU, mémoire, disque et réseau.

pcp-atopsar

Génère un rapport d'activité au niveau du système sur une variété d'utilisation des ressources du système. Le rapport est généré à partir d'un fichier journal brut préalablement enregistré à l'aide de pmlogger ou de l'option -w de pcp-atop.

pcp-dmcache

Affiche des informations sur les cibles configurées de Device Mapper Cache, telles que : les IOP des périphériques, l'utilisation des périphériques de cache et de métadonnées, ainsi que les taux de réussite et d'échec et les ratios pour les lectures et les écritures pour chaque périphérique de cache.

pcp-dstat

Affiche les métriques d'un seul système à la fois. Pour afficher les mesures de plusieurs systèmes, utilisez l'option --host.

pcp-free

Indique la mémoire libre et la mémoire utilisée dans un système.

pcp-htop

Affiche tous les processus en cours d'exécution sur un système ainsi que leurs arguments de ligne de commande d'une manière similaire à la commande top, mais vous permet de faire défiler verticalement et horizontalement et d'interagir à l'aide d'une souris. Vous pouvez également visualiser les processus sous forme d'arbre et sélectionner et agir sur plusieurs processus à la fois.

pcp-ipcs

Affiche des informations sur les installations de communication interprocessus (IPC) pour lesquelles le processus appelant dispose d'un accès en lecture.

pcp-numastat

Affiche les statistiques d'allocation NUMA de l'allocateur de mémoire du noyau.

pcp-pidstat

Affiche des informations sur les tâches individuelles ou les processus en cours d'exécution sur le système, telles que le pourcentage de CPU, l'utilisation de la mémoire et de la pile, la planification et la priorité : Le pourcentage de CPU, l'utilisation de la mémoire et de la pile, la planification et la priorité. Affiche par défaut les données en direct de l'hôte local.

pcp-ss

Affiche les statistiques des sockets collectées par l'agent PMDA (Performance Metrics Domain Agent).

pcp-uptime

Affiche la durée de fonctionnement du système, le nombre d'utilisateurs actuellement connectés et les moyennes de charge du système pour les 1, 5 et 15 dernières minutes.

pcp-vmstat

Fournit une vue d'ensemble des performances du système toutes les 5 secondes. Affiche des informations sur les processus, la mémoire, la pagination, les entrées-sorties par bloc, les pièges et l'activité de l'unité centrale.

pmchart

Trace les valeurs des mesures de performance disponibles par le biais des installations du copilote de performance.

pmclient

Affiche les mesures de performance du système de haut niveau en utilisant l'interface de programmation d'applications de mesures de performance (PMAPI).

pmconfig

Affiche les valeurs des paramètres de configuration.

pmdbg

Affiche les drapeaux de contrôle de débogage de Performance Co-Pilot disponibles et leurs valeurs.

pmdiff

Compare les valeurs moyennes de chaque paramètre dans une ou deux archives, dans une fenêtre temporelle donnée, pour détecter les changements susceptibles d'être intéressants lors de la recherche de régressions des performances.

pmdumplog

Affiche les informations relatives au contrôle, aux métadonnées, à l'index et à l'état d'un fichier d'archive de Performance Co-Pilot.

pmdumptext

Produit les valeurs des mesures de performance collectées en direct ou à partir d'une archive Performance Co-Pilot.

pmerr

Affiche les codes d'erreur Performance Co-Pilot disponibles et les messages d'erreur correspondants.

pmfind

Recherche des services de PCP sur le réseau.

pmie

Un moteur d'inférence qui évalue périodiquement un ensemble d'expressions arithmétiques, logiques et de règles. Les mesures sont collectées soit à partir d'un système réel, soit à partir d'un fichier d'archive de Performance Co-Pilot.

pmieconf

Affiche ou définit les variables pmie configurables.

pmiectl

Gère les instances non primaires de pmie.

pminfo

Affiche des informations sur les mesures de performance. Les mesures sont collectées soit à partir d'un système réel, soit à partir d'un fichier d'archive de Performance Co-Pilot.

pmiostat

Affiche les statistiques d'E/S pour les périphériques SCSI (par défaut) ou les périphériques de mappage de périphériques (avec l'option -x dm).

pmlc

Configure de manière interactive les instances actives de pmlogger.

pmlogcheck

Identifie les données non valides dans un fichier d'archive de Performance Co-Pilot.

pmlogconf

Crée et modifie un fichier de configuration pmlogger.

pmlogctl

Gère les instances non primaires de pmlogger.

pmloglabel

Vérifie, modifie ou répare l'étiquette d'un fichier d'archive de Performance Co-Pilot.

pmlogsummary

Calcule des informations statistiques sur les mesures de performance stockées dans un fichier d'archive de Performance Co-Pilot.

pmprobe

Détermine la disponibilité des mesures de performance.

pmrep

Rapports sur des valeurs de mesure de la performance sélectionnées et facilement personnalisables.

pmsocks

Permet d'accéder à un hôte Performance Co-Pilot à travers un pare-feu.

pmstat

Affiche périodiquement un bref résumé des performances du système.

pmstore

Modifie les valeurs des mesures de performance.

pmtrace

Fournit une interface de ligne de commande à la trace PMDA.

pmval

Affiche la valeur actuelle d'une mesure de performance.

5.6. Architectures de déploiement PCP

Performance Co-Pilot (PCP) prend en charge plusieurs architectures de déploiement, en fonction de l'échelle de déploiement de PCP, et offre de nombreuses options pour réaliser des configurations avancées.

Les variantes de configuration de déploiement de mise à l'échelle disponibles, basées sur la configuration de déploiement recommandée par Red Hat, les facteurs de dimensionnement et les options de configuration, sont les suivantes :

Localhost

Chaque service s'exécute localement sur la machine surveillée. Lorsque vous démarrez un service sans aucun changement de configuration, il s'agit du déploiement par défaut. Dans ce cas, il n'est pas possible de passer à une échelle supérieure à celle d'un nœud individuel.

Par défaut, le déploiement de Redis se fait de manière autonome, sur l'hôte local. Cependant, Redis peut optionnellement fonctionner en grappe hautement disponible et hautement évolutive, où les données sont partagées entre plusieurs hôtes. Une autre option viable consiste à déployer un cluster Redis dans le nuage ou à utiliser un cluster Redis géré par un fournisseur de nuage.

Decentralized

La seule différence entre l'hôte local et la configuration décentralisée est le service Redis centralisé. Dans ce modèle, l'hôte exécute le service pmlogger sur chaque hôte surveillé et récupère les mesures à partir d'une instance locale pmcd. Un service local pmproxy exporte ensuite les mesures de performance vers une instance Redis centrale.

Figure 5.1. Exploitation décentralisée des données

Decentralized logging
Centralized logging - pmlogger farm

Lorsque l'utilisation des ressources sur les hôtes surveillés est limitée, une autre option de déploiement est une ferme pmlogger, également connue sous le nom de journalisation centralisée. Dans cette configuration, un seul hôte enregistreur exécute plusieurs processus pmlogger, et chacun est configuré pour récupérer des mesures de performance à partir d'un hôte pmcd distant différent. L'hôte de l'enregistreur centralisé est également configuré pour exécuter le service pmproxy, qui découvre les archives PCP résultantes et charge les données métriques dans une instance Redis.

Figure 5.2. Journalisation centralisée - pmlogger farm

Centralized logging - pmlogger farm
Federated - multiple pmlogger farms

Pour les déploiements à grande échelle, Red Hat recommande de déployer plusieurs fermes pmlogger de manière fédérée. Par exemple, une ferme pmlogger par rack ou centre de données. Chaque ferme pmlogger charge les métriques dans une instance Redis centrale.

Figure 5.3. Federated - de multiples fermes de pmlogger

Federated - multiple pmlogger farms
Note

Par défaut, le déploiement de Redis se fait de manière autonome, sur l'hôte local. Cependant, Redis peut optionnellement fonctionner en grappe hautement disponible et hautement évolutive, où les données sont partagées entre plusieurs hôtes. Une autre option viable consiste à déployer un cluster Redis dans le nuage ou à utiliser un cluster Redis géré par un fournisseur de nuage.

Ressources supplémentaires

5.8. Facteurs de dimensionnement

Les facteurs de dimensionnement requis pour la mise à l'échelle sont les suivants :

Remote system size
Le nombre d'unités centrales, de disques, d'interfaces réseau et d'autres ressources matérielles influe sur la quantité de données collectées par chaque site pmlogger sur l'hôte d'enregistrement centralisé.
Logged Metrics
Le nombre et les types de mesures enregistrées jouent un rôle important. En particulier, les mesures per-process proc.* nécessitent un espace disque important. Par exemple, avec la configuration standard pcp-zeroconf, un intervalle de journalisation de 10 secondes, 11 Mo sans les mesures proc contre 155 Mo avec les mesures proc, soit un facteur de 10 fois supérieur. En outre, le nombre d'instances pour chaque mesure, par exemple le nombre de CPU, de périphériques de bloc et d'interfaces réseau, a également une incidence sur la capacité de stockage requise.
Logging Interval
L'intervalle de temps pendant lequel les métriques sont enregistrées affecte les besoins en stockage. Les tailles prévues des fichiers d'archive PCP quotidiens sont écrites dans le fichier pmlogger.log pour chaque instance de pmlogger. Ces valeurs sont des estimations non compressées. Étant donné que les archives PCP sont très bien compressées (environ 10:1), les besoins réels en espace disque à long terme peuvent être déterminés pour un site particulier.
pmlogrewrite
Après chaque mise à jour de PCP, l'outil pmlogrewrite est exécuté et réécrit les anciennes archives s'il y a eu des changements dans les métadonnées métriques entre la version précédente et la nouvelle version de PCP. La durée de ce processus est linéaire en fonction du nombre d'archives stockées.

Ressources supplémentaires

  • pmlogrewrite(1) et pmlogger(1) pages de manuel

5.9. Options de configuration pour la mise à l'échelle du PCP

Les options de configuration suivantes sont nécessaires pour la mise à l'échelle :

sysctl and rlimit settings
Lorsque la découverte d'archives est activée, pmproxy a besoin de quatre descripteurs pour chaque pmlogger qu'il surveille ou enregistre, ainsi que des descripteurs de fichiers supplémentaires pour les journaux de service et les sockets des clients pmproxy, le cas échéant. Chaque processus pmlogger utilise environ 20 descripteurs de fichiers pour la socket pmcd distante, les fichiers d'archive, les journaux de service et autres. Au total, cela peut dépasser la limite de 1024 soft par défaut sur un système exécutant environ 200 processus pmlogger. Le service pmproxy dans pcp-5.3.0 et les versions ultérieures augmente automatiquement la limite douce à la limite dure. Sur les versions antérieures de PCP, un réglage est nécessaire si un nombre élevé de processus pmlogger doit être déployé, ce qui peut être réalisé en augmentant les limites logicielles ou matérielles pour pmlogger. Pour plus d'informations, voir Comment définir des limites (ulimit) pour les services exécutés par systemd.
Local Archives
Le service pmlogger stocke les mesures des systèmes locaux et distants pmcds dans le répertoire /var/log/pcp/pmlogger/. Pour contrôler l'intervalle de journalisation du système local, mettez à jour le fichier /etc/pcp/pmlogger/control.d/configfile et ajoutez -t X dans les arguments, où X est l'intervalle de journalisation en secondes. Pour configurer les mesures qui doivent être enregistrées, exécutez pmlogconf /var/lib/pcp/config/pmlogger/config.clienthostname. Cette commande déploie un fichier de configuration avec un ensemble de mesures par défaut, qui peut éventuellement être personnalisé. Pour spécifier les paramètres de rétention, c'est-à-dire quand purger les anciennes archives PCP, mettez à jour le fichier /etc/sysconfig/pmlogger_timers et spécifiez PMLOGGER_DAILY_PARAMS="-E -k X"X est le nombre de jours pendant lesquels les archives PCP doivent être conservées.
Redis

Le service pmproxy envoie les mesures consignées de pmlogger à une instance Redis. Voici les deux options disponibles pour spécifier les paramètres de rétention dans le fichier de configuration /etc/pcp/pmproxy/pmproxy.conf:

  • stream.expire spécifie la durée pendant laquelle les métriques périmées doivent être supprimées, c'est-à-dire les métriques qui n'ont pas été mises à jour pendant un laps de temps spécifié en secondes.
  • stream.maxlen spécifie le nombre maximum de valeurs métriques pour une métrique par hôte. Ce paramètre doit correspondre à la durée de conservation divisée par l'intervalle d'enregistrement, par exemple 20160 pour une conservation de 14 jours et un intervalle d'enregistrement de 60s (60*60*24*14/60)

Ressources supplémentaires

  • pmproxy(1), pmlogger(1), et sysctl(8) pages de manuel

5.10. Exemple : Analyse du déploiement de la journalisation centralisée

Les résultats suivants ont été recueillis sur une configuration de journalisation centralisée, également connue sous le nom de déploiement de ferme pmlogger, avec une installation par défaut de pcp-zeroconf 5.3.0, où chaque hôte distant est une instance de conteneur identique exécutant pmcd sur un serveur avec 64 cœurs de CPU, 376 Go de RAM, et un disque attaché.

L'intervalle de journalisation est de 10 secondes, les métriques proc des nœuds distants ne sont pas incluses et les valeurs de mémoire se réfèrent à la valeur RSS (Resident Set Size).

Tableau 5.4. Statistiques d'utilisation détaillées pour un intervalle d'enregistrement de 10 secondes
Nombre d'hôtes1050

Stockage des archives PCP par jour

91 MB

522 MB

pmlogger Mémoire

160 MO

580 MB

pmlogger Réseau par jour (en)

2 MB

9 MB

pmproxy Mémoire

1.4 GB

6.3 GB

Mémoire Redis par jour

2.6 GB

12 GB

Tableau 5.5. Ressources utilisées en fonction des hôtes surveillés pour l'intervalle d'enregistrement de 60s
Nombre d'hôtes1050100

Stockage des archives PCP par jour

20 MB

120 MB

271 MB

pmlogger Mémoire

104 MB

524 MB

1049 MB

pmlogger Réseau par jour (en)

0.38 MB

1.75 MB

3.48 MB

pmproxy Mémoire

2.67 GB

5.5GB

9 GB

Mémoire Redis par jour

0.54 GB

2.65 GB

5.3 GB

Note

Le site pmproxy met en file d'attente les requêtes Redis et utilise le pipelining Redis pour accélérer les requêtes Redis. Cela peut entraîner une utilisation élevée de la mémoire. Pour résoudre ce problème, voir Résolution des problèmes liés à une utilisation élevée de la mémoire.

5.11. Exemple : Analyse du déploiement de l'installation fédérée

Les résultats suivants ont été observés sur une installation fédérée, également connue sous le nom de fermes pmlogger multiples, composée de trois installations de journalisation centralisée (fermespmlogger ), où chaque ferme pmlogger surveillait 100 hôtes distants, soit 300 hôtes au total.

Cette configuration des fermes pmlogger est identique à celle mentionnée dans le document

Exemple : Analyse du déploiement de la journalisation centralisée pour l'intervalle de journalisation de 60s, sauf que les serveurs Redis fonctionnaient en mode cluster.

Tableau 5.6. Ressources utilisées en fonction des hôtes fédérés pour un intervalle de journalisation de 60s
Stockage des archives PCP par jourpmlogger MémoireRéseau par jour (entrée/sortie)pmproxy MémoireMémoire Redis par jour

277 MB

1058 MB

15.6 MB / 12.3 MB

6-8 GB

5.5 GB

Ici, toutes les valeurs sont par hôte. La bande passante du réseau est plus élevée en raison de la communication entre les nœuds du cluster Redis.

5.12. Établir des connexions PCP sécurisées

Vous pouvez configurer les composants de collecte et de surveillance PCP pour qu'ils participent aux échanges sécurisés du protocole PCP.

5.12.1. Connexions PCP sécurisées

Vous pouvez établir des connexions sécurisées entre les composants de collecte et de surveillance de Performance Co-Pilot (PCP). Les composants de collecte PCP sont les parties de PCP qui collectent et extraient les données de performance à partir de différentes sources. Les composants de surveillance PCP sont les parties de PCP qui affichent les données collectées à partir d'hôtes ou d'archives sur lesquels sont installés les composants de collecte PCP. L'établissement de connexions sécurisées entre ces composants permet d'éviter que des personnes non autorisées n'accèdent aux données collectées et surveillées ou ne les modifient.

Toutes les connexions avec le démon Performance Metrics Collector (pmcd) sont effectuées à l'aide du protocole PCP basé sur TCP/IP. Le protocole proxy et les API REST de PCP sont servis par le démon pmproxy - l'API REST est accessible via HTTPS, ce qui garantit une connexion sécurisée.

Les démons pmcd et pmproxy sont tous deux capables d'établir des communications TLS et non TLS simultanées sur un seul port. Le port par défaut pour pmcd est 44321 et 44322 pour pmproxy. Cela signifie que vous n'avez pas à choisir entre les communications TLS ou non TLS pour vos systèmes collecteurs PCP et que vous pouvez utiliser les deux en même temps.

5.12.2. Configuration de connexions sécurisées pour les composants du collecteur PCP

Tous les systèmes collecteurs PCP doivent disposer de certificats valides afin de participer aux échanges sécurisés du protocole PCP.

Note

le démon pmproxy fonctionne à la fois comme un client et un serveur du point de vue de TLS.

Conditions préalables

  • PCP est installé. Pour plus d'informations, voir Installation et activation de PCP.
  • La clé privée du client est stockée dans le fichier /etc/pcp/tls/client.key. Si vous utilisez un chemin différent, adaptez les étapes correspondantes de la procédure.

    Pour plus de détails sur la création d'une clé privée et d'une demande de signature de certificat (CSR), ainsi que sur la manière de demander un certificat à une autorité de certification (AC), consultez la documentation de votre AC.

  • Le certificat client TLS est stocké dans le fichier /etc/pcp/tls/client.crt. Si vous utilisez un chemin différent, adaptez les étapes correspondantes de la procédure.
  • Le certificat CA est stocké dans le fichier /etc/pcp/tls/ca.crt. Si vous utilisez un chemin différent, adaptez les étapes correspondantes de la procédure. En outre, pour le démon pmproxy:
  • La clé privée du serveur est stockée dans le fichier /etc/pcp/tls/server.key. Si vous utilisez un chemin différent, adaptez les étapes correspondantes de la procédure
  • Le certificat du serveur TLS est stocké dans le fichier /etc/pcp/tls/server.crt. Si vous utilisez un chemin différent, adaptez les étapes correspondantes de la procédure.

Procédure

  1. Mettez à jour le fichier de configuration PCP TLS sur les systèmes collecteurs afin d'utiliser les certificats émis par l'autorité de certification pour établir une connexion sécurisée :

    # cat > /etc/pcp/tls.conf << END
    tls-ca-cert-file = /etc/pcp/tls/ca.crt
    tls-key-file = /etc/pcp/tls/server.key
    tls-cert-file = /etc/pcp/tls/server.crt
    tls-client-key-file = /etc/pcp/tls/client.key
    tls-client-cert-file = /etc/pcp/tls/client.crt
    END
  2. Redémarrer l'infrastructure du collecteur PCP :

    # systemctl restart pmcd.service
    # systemctl restart pmproxy.service

Vérification

  • Vérifiez la configuration TLS :

    • Sur le service pmcd:

      # grep 'Info:' /var/log/pcp/pmcd/pmcd.log
      [Tue Feb 07 11:47:33] pmcd(6558) Info: OpenSSL 3.0.7 setup
    • Sur le service pmproxy:

      # grep 'Info:' /var/log/pcp/pmproxy/pmproxy.log
      [Tue Feb 07 11:44:13] pmproxy(6014) Info: OpenSSL 3.0.7 setup

5.12.3. Configuration de connexions sécurisées pour les composants de surveillance PCP

Configurez vos composants de surveillance PCP pour qu'ils participent aux échanges sécurisés du protocole PCP.

Conditions préalables

  • PCP est installé. Pour plus d'informations, voir Installation et activation de PCP.
  • La clé privée du client est stockée dans le fichier ~/.pcp/tls/client.key. Si vous utilisez un chemin différent, adaptez les étapes correspondantes de la procédure.

    Pour plus de détails sur la création d'une clé privée et d'une demande de signature de certificat (CSR), ainsi que sur la manière de demander un certificat à une autorité de certification (AC), consultez la documentation de votre AC.

  • Le certificat client TLS est stocké dans le fichier ~/.pcp/tls/client.crt. Si vous utilisez un chemin différent, adaptez les étapes correspondantes de la procédure.
  • Le certificat CA est stocké dans le fichier /etc/pcp/tls/ca.crt. Si vous utilisez un chemin différent, adaptez les étapes correspondantes de la procédure.

Procédure

  1. Créez un fichier de configuration TLS avec les informations suivantes :

    $ home=echo ~
    $ cat > ~/.pcp/tls.conf << END
    tls-ca-cert-file = /etc/pcp/tls/ca.crt
    tls-key-file = $home/.pcp/tls/client.key
    tls-cert-file = $home/.pcp/tls/client.crt
    END
  2. Établir la connexion sécurisée :

    $ export PCP_SECURE_SOCKETS=enforce
    $ export PCP_TLSCONF_PATH=~/.pcp/tls.conf

Vérification

  • Vérifiez que la connexion sécurisée est configurée :

    $ pminfo --fetch --host pcps://localhost kernel.all.load
    
    kernel.all.load
        inst [1 or "1 minute"] value 1.26
        inst [5 or "5 minute"] value 1.29
        inst [15 or "15 minute"] value 1.28

5.13. Dépannage en cas d'utilisation élevée de la mémoire

Les scénarios suivants peuvent entraîner une utilisation élevée de la mémoire :

  • Le processus pmproxy est occupé à traiter de nouvelles archives PCP et n'a pas de cycles de CPU disponibles pour traiter les requêtes et les réponses Redis.
  • Le nœud ou le cluster Redis est surchargé et ne peut pas traiter les demandes entrantes à temps.

Le démon de service pmproxy utilise les flux Redis et prend en charge les paramètres de configuration, qui sont des paramètres de réglage PCP et affectent l'utilisation de la mémoire Redis et la conservation des clés. Le fichier /etc/pcp/pmproxy/pmproxy.conf répertorie les options de configuration disponibles pour pmproxy et les API associées.

La procédure suivante décrit comment résoudre un problème d'utilisation élevée de la mémoire.

Conditions préalables

  1. Installez le paquetage pcp-pmda-redis:

    # dnf install pcp-pmda-redis
  2. Installez le PMDA redis :

    # cd /var/lib/pcp/pmdas/redis && ./Install

Procédure

  • Pour résoudre un problème d'utilisation élevée de la mémoire, exécutez la commande suivante et observez la colonne inflight:

    $ pmrep :pmproxy
             backlog  inflight  reqs/s  resp/s   wait req err  resp err  changed  throttled
              byte     count   count/s  count/s  s/s  count/s   count/s  count/s   count/s
    14:59:08   0         0       N/A       N/A   N/A    N/A      N/A      N/A        N/A
    14:59:09   0         0    2268.9    2268.9    28     0        0       2.0        4.0
    14:59:10   0         0       0.0       0.0     0     0        0       0.0        0.0
    14:59:11   0         0       0.0       0.0     0     0        0       0.0        0.0

    Cette colonne indique le nombre de requêtes Redis en cours, ce qui signifie qu'elles sont en file d'attente ou envoyées et qu'aucune réponse n'a été reçue jusqu'à présent.

    Un nombre élevé indique l'une des conditions suivantes :

    • Le processus pmproxy est occupé à traiter de nouvelles archives PCP et n'a pas de cycles de CPU disponibles pour traiter les requêtes et les réponses Redis.
    • Le nœud ou le cluster Redis est surchargé et ne peut pas traiter les demandes entrantes à temps.
  • Pour résoudre le problème de l'utilisation élevée de la mémoire, réduisez le nombre de processus pmlogger pour cette ferme et ajoutez une autre ferme pmlogger. Utilisez la configuration fédérée - plusieurs fermes pmlogger.

    Si le nœud Redis utilise 100 PU pendant une période prolongée, déplacez-le vers un hôte plus performant ou utilisez plutôt une configuration Redis en grappe.

  • Pour afficher les paramètres de pmproxy.redis.*, utilisez la commande suivante :

    $ pminfo -ftd pmproxy.redis
    pmproxy.redis.responses.wait [wait time for responses]
        Data Type: 64-bit unsigned int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: counter  Units: microsec
        value 546028367374
    pmproxy.redis.responses.error [number of error responses]
        Data Type: 64-bit unsigned int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: counter  Units: count
        value 1164
    [...]
    pmproxy.redis.requests.inflight.bytes [bytes allocated for inflight requests]
        Data Type: 64-bit int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: discrete  Units: byte
        value 0
    
    pmproxy.redis.requests.inflight.total [inflight requests]
        Data Type: 64-bit unsigned int  InDom: PM_INDOM_NULL 0xffffffff
        Semantics: discrete  Units: count
        value 0
    [...]

    Pour connaître le nombre de requêtes Redis en cours, consultez les métriques pmproxy.redis.requests.inflight.total et pmproxy.redis.requests.inflight.bytes pour savoir combien d'octets sont occupés par toutes les requêtes Redis en cours.

    En général, la file d'attente des requêtes redis est nulle, mais elle peut s'allonger en fonction de l'utilisation des grandes fermes pmlogger, ce qui limite l'évolutivité et peut entraîner des temps de latence élevés pour les clients pmproxy.

  • Utilisez la commande pminfo pour afficher des informations sur les mesures de performance. Par exemple, pour afficher les mesures de redis.*, utilisez la commande suivante :

    $ pminfo -ftd redis
    redis.redis_build_id [Build ID]
        Data Type: string  InDom: 24.0 0x6000000
        Semantics: discrete  Units: count
        inst [0 or "localhost:6379"] value "87e335e57cffa755"
    redis.total_commands_processed [Total number of commands processed by the server]
        Data Type: 64-bit unsigned int  InDom: 24.0 0x6000000
        Semantics: counter  Units: count
        inst [0 or "localhost:6379"] value 595627069
    [...]
    
    redis.used_memory_peak [Peak memory consumed by Redis (in bytes)]
        Data Type: 32-bit unsigned int  InDom: 24.0 0x6000000
        Semantics: instant  Units: count
        inst [0 or "localhost:6379"] value 572234920
    [...]

    Pour connaître l'utilisation maximale de la mémoire, consultez la métrique redis.used_memory_peak.

Ressources supplémentaires

Chapitre 6. Enregistrement des données de performance avec pmlogger

L'outil PCP vous permet d'enregistrer les valeurs des mesures de performance et de les rejouer ultérieurement. Cela vous permet d'effectuer une analyse rétrospective des performances.

En utilisant l'outil pmlogger, vous pouvez

  • Créer les journaux archivés des mesures sélectionnées sur le système
  • Spécifier quelles mesures sont enregistrées sur le système et à quelle fréquence

6.1. Modifier le fichier de configuration de pmlogger avec pmlogconf

Lorsque le service pmlogger est en cours d'exécution, PCP enregistre un ensemble de mesures par défaut sur l'hôte.

Utilisez l'utilitaire pmlogconf pour vérifier la configuration par défaut. Si le fichier de configuration pmlogger n'existe pas, pmlogconf le crée avec des valeurs métriques par défaut.

Conditions préalables

Procédure

  1. Créer ou modifier le fichier de configuration de pmlogger:

    # pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
  2. Suivez les invites de pmlogconf pour activer ou désactiver des groupes de mesures de performance connexes et pour contrôler l'intervalle de journalisation pour chaque groupe activé.

Ressources supplémentaires

6.2. Modifier manuellement le fichier de configuration de pmlogger

Pour créer une configuration de journalisation personnalisée avec des mesures spécifiques et des intervalles donnés, modifiez manuellement le fichier de configuration pmlogger. Le fichier de configuration par défaut de pmlogger est /var/lib/pcp/config/pmlogger/config.default. Le fichier de configuration spécifie les mesures qui sont enregistrées par l'instance de journalisation principale.

En configuration manuelle, vous pouvez

  • Enregistrer les mesures qui ne sont pas répertoriées dans la configuration automatique.
  • Choisissez des fréquences d'enregistrement personnalisées.
  • Ajouter PMDA avec les métriques de l'application.

Conditions préalables

Procédure

  • Ouvrez et modifiez le fichier /var/lib/pcp/config/pmlogger/config.default pour ajouter des mesures spécifiques :

    # It is safe to make additions from here on ...
    #
    
    log mandatory on every 5 seconds {
        xfs.write
        xfs.write_bytes
        xfs.read
        xfs.read_bytes
    }
    
    log mandatory on every 10 seconds {
        xfs.allocs
        xfs.block_map
        xfs.transactions
        xfs.log
    
    }
    
    [access]
    disallow * : all;
    allow localhost : enquire;

Ressources supplémentaires

6.3. Activation du service pmlogger

Le service pmlogger doit être démarré et activé pour enregistrer les valeurs métriques sur la machine locale.

Cette procédure décrit comment activer le service pmlogger.

Conditions préalables

Procédure

  • Démarrez et activez le service pmlogger:

    # systemctl start pmlogger
    
    # systemctl enable pmlogger

Verification steps

  • Vérifiez si le service pmlogger est activé :

    # pcp
    
    Performance Co-Pilot configuration on workstation:
    
    platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64
    hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM
    timezone: CEST-2
    services: pmcd
    pmcd: Version 4.3.0-1, 8 agents, 1 client
    pmda: root pmcd proc xfs linux mmv kvm jbd2
    pmlogger: primary logger: /var/log/pcp/pmlogger/workstation/20190827.15.54

Ressources supplémentaires

6.4. Mise en place d'un système client pour la collecte de données

Cette procédure décrit comment configurer un système client de manière à ce qu'un serveur central puisse collecter des métriques auprès des clients utilisant PCP.

Conditions préalables

Procédure

  1. Installez le paquetage pcp-system-tools:

    # dnf install pcp-system-tools
  2. Configurez une adresse IP pour pmcd:

    # echo "-i 192.168.4.62" >>/etc/pcp/pmcd/pmcd.options

    Remplacez 192.168.4.62 par l'adresse IP sur laquelle le client doit écouter.

    Par défaut, pmcd écoute sur localhost.

  3. Configurer le pare-feu pour ajouter le site public zone de façon permanente :

    # firewall-cmd --permanent --zone=public --add-port=44321/tcp
    success
    
    # firewall-cmd --reload
    success
  4. Définit un booléen SELinux :

    # setsebool -P pcp_bind_all_unreserved_ports on
  5. Activez les services pmcd et pmlogger:

    # systemctl enable pmcd pmlogger
    # systemctl restart pmcd pmlogger

Verification steps

  • Vérifiez que le site pmcd écoute correctement l'adresse IP configurée :

    # ss -tlp | grep 44321
    LISTEN   0   5     127.0.0.1:44321   0.0.0.0:*   users:(("pmcd",pid=151595,fd=6))
    LISTEN   0   5  192.168.4.62:44321   0.0.0.0:*   users:(("pmcd",pid=151595,fd=0))
    LISTEN   0   5         [::1]:44321      [::]:*   users:(("pmcd",pid=151595,fd=7))

Ressources supplémentaires

6.5. Mise en place d'un serveur central pour la collecte des données

Cette procédure décrit comment créer un serveur central pour collecter les métriques des clients exécutant PCP.

Conditions préalables

Procédure

  1. Installez le paquetage pcp-system-tools:

    # dnf install pcp-system-tools
  2. Créez le fichier /etc/pcp/pmlogger/control.d/remote avec le contenu suivant :

    # DO NOT REMOVE OR EDIT THE FOLLOWING LINE
    $version=1.1
    
    192.168.4.13 n n PCP_ARCHIVE_DIR/rhel7u4a -r -T24h10m -c config.rhel7u4a
    192.168.4.14 n n PCP_ARCHIVE_DIR/rhel6u10a -r -T24h10m -c config.rhel6u10a
    192.168.4.62 n n PCP_ARCHIVE_DIR/rhel8u1a -r -T24h10m -c config.rhel8u1a
    192.168.4.69 n n PCP_ARCHIVE_DIR/rhel9u3a -r -T24h10m -c config.rhel9u3a

    Remplacez 192.168.4.13, 192.168.4.14, 192.168.4.62 et 192.168.4.69 par les adresses IP des clients.

  3. Activez les services pmcd et pmlogger:

    # systemctl enable pmcd pmlogger
    # systemctl restart pmcd pmlogger

Verification steps

  • Assurez-vous que vous pouvez accéder au dernier fichier d'archive de chaque répertoire :

    # for i in /var/log/pcp/pmlogger/rhel*/*.0; do pmdumplog -L $i; done
    Log Label (Log Format Version 2)
    Performance metrics from host rhel6u10a.local
      commencing Mon Nov 25 21:55:04.851 2019
      ending     Mon Nov 25 22:06:04.874 2019
    Archive timezone: JST-9
    PID for pmlogger: 24002
    Log Label (Log Format Version 2)
    Performance metrics from host rhel7u4a
      commencing Tue Nov 26 06:49:24.954 2019
      ending     Tue Nov 26 07:06:24.979 2019
    Archive timezone: CET-1
    PID for pmlogger: 10941
    [..]

    Les fichiers d'archive du répertoire /var/log/pcp/pmlogger/ peuvent être utilisés pour d'autres analyses et graphiques.

Ressources supplémentaires

6.6. Reproduire les archives des journaux PCP avec pmrep

Après avoir enregistré les données métriques, vous pouvez relire les archives des journaux PCP. Pour exporter les journaux vers des fichiers texte et les importer dans des feuilles de calcul, utilisez les utilitaires PCP tels que pcp2csv, pcp2xml, pmrep ou pmlogsummary.

En utilisant l'outil pmrep, vous pouvez

  • Consulter les fichiers journaux
  • Analyse l'archive PCP sélectionnée et exporte les valeurs dans un tableau ASCII
  • Extraire l'intégralité du journal d'archive ou seulement certaines valeurs métriques du journal en spécifiant des métriques individuelles sur la ligne de commande

Conditions préalables

Procédure

  • Afficher les données sur la métrique :

    $ pmrep --start @3:00am --archive 20211128 --interval 5seconds --samples 10 --output csv disk.dev.write
    Time,"disk.dev.write-sda","disk.dev.write-sdb"
    2021-11-28 03:00:00,,
    2021-11-28 03:00:05,4.000,5.200
    2021-11-28 03:00:10,1.600,7.600
    2021-11-28 03:00:15,0.800,7.100
    2021-11-28 03:00:20,16.600,8.400
    2021-11-28 03:00:25,21.400,7.200
    2021-11-28 03:00:30,21.200,6.800
    2021-11-28 03:00:35,21.000,27.600
    2021-11-28 03:00:40,12.400,33.800
    2021-11-28 03:00:45,9.800,20.600

    L'exemple mentionné affiche les données sur la métrique disk.dev.write collectées dans une archive à un intervalle 5 second dans un format de valeurs séparées par des virgules.

    Note

    Remplacez 20211128 dans cet exemple par un nom de fichier contenant l'archive pmlogger dont vous voulez afficher les données.

Ressources supplémentaires

6.7. Activation des archives PCP version 3

Les archives Performance Co-Pilot (PCP) stockent les valeurs historiques des métriques PCP enregistrées à partir d'un seul hôte et permettent une analyse rétrospective des performances. Les archives PCP contiennent toutes les données métriques importantes et les métadonnées nécessaires à l'analyse hors ligne ou hors site. Ces archives peuvent être lues par la plupart des outils clients PCP ou vidées de manière brute par l'outil pmdumplog.

À partir de PCP 6.0, les archives de la version 3 sont prises en charge en plus des archives de la version 2. Les archives de la version 2 restent les archives par défaut et continueront à bénéficier d'un support à long terme à des fins de rétrocompatibilité, tandis que les archives de la version 3 bénéficieront d'un support à long terme à partir de RHEL 9.2.

L'utilisation des archives de la version 3 du PCP offre les avantages suivants par rapport à la version 2 :

  • Prise en charge du changement de domaine d'instance-deltas
  • Horodatage sécurisé Y2038
  • Horodatage à la nanoseconde près
  • Prise en charge de fuseaux horaires arbitraires
  • décalages de fichiers de 64 bits utilisés pour les volumes individuels de plus de 2 Go

Conditions préalables

Procédure

  1. Ouvrez le fichier /etc/pcp.conf dans un éditeur de texte de votre choix et définissez la version de l'archive PCP :

    PCP_ARCHIVE_VERSION=3
  2. Redémarrez le service pmlogger pour appliquer vos changements de configuration :

    # systemctl restart pmlogger.service
  3. Créez un nouveau journal d'archive PCP en utilisant votre nouvelle configuration. Pour plus d'informations, voir Enregistrer les données de performance avec pmlogger.

Vérification

  • Vérifiez la version de l'archive créée avec votre nouvelle configuration :

    # pmloglabel -l /var/log/pcp/pmlogger/20230208
    Log Label (Log Format Version 3)
    Performance metrics from host host1
            commencing Wed Feb   08 00:11:09.396 2023
            ending           Thu  Feb   07 00:13:54.347 2023

Ressources supplémentaires

Chapitre 7. Suivi des performances avec Performance Co-Pilot

Performance Co-Pilot (PCP) est une suite d'outils, de services et de bibliothèques permettant de surveiller, de visualiser, de stocker et d'analyser les mesures de performance au niveau du système.

En tant qu'administrateur système, vous pouvez surveiller les performances du système à l'aide de l'application PCP dans Red Hat Enterprise Linux 9.

7.1. Surveillance de postfix avec pmda-postfix

Cette procédure décrit comment surveiller les paramètres de performance du serveur de messagerie postfix à l'aide de pmda-postfix. Elle permet de vérifier le nombre de courriers électroniques reçus par seconde.

Conditions préalables

Procédure

  1. Install the following packages:

    1. Installer le site pcp-system-tools:

      # dnf install pcp-system-tools
    2. Installez le paquet pmda-postfix pour contrôler postfix:

      # dnf install pcp-pmda-postfix postfix
    3. Installer le démon de journalisation :

      # dnf install rsyslog
    4. Installez le client de messagerie pour le tester :

      # dnf install mutt
  2. Activez les services postfix et rsyslog:

    # systemctl enable postfix rsyslog
    # systemctl restart postfix rsyslog
  3. Activez le booléen SELinux, afin que pmda-postfix puisse accéder aux fichiers journaux requis :

    # setsebool -P pcp_read_generic_logs=on
  4. Installer le site PMDA:

    # cd /var/lib/pcp/pmdas/postfix/
    
    # ./Install
    
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Waiting for pmcd to terminate ...
    Starting pmcd ...
    Check postfix metrics have appeared ... 7 metrics and 58 values

Verification steps

  • Vérifier le fonctionnement de pmda-postfix:

    echo testmail | mutt root
  • Vérifier les métriques disponibles :

    # pminfo postfix
    
    postfix.received
    postfix.sent
    postfix.queues.incoming
    postfix.queues.maildrop
    postfix.queues.hold
    postfix.queues.deferred
    postfix.queues.active

Ressources supplémentaires

7.2. Tracer visuellement les archives des journaux PCP avec l'application PCP Charts

Après avoir enregistré les données métriques, vous pouvez rejouer les archives des journaux PCP sous forme de graphiques. Les mesures proviennent d'un ou de plusieurs hôtes en direct, mais il est également possible d'utiliser les données des archives de journaux PCP comme source de données historiques. Pour personnaliser l'interface de l'application PCP Charts afin d'afficher les données des mesures de performance, vous pouvez utiliser des graphiques linéaires, des graphiques à barres ou des graphiques d'utilisation.

En utilisant l'application PCP Charts, vous pouvez

  • Reproduire les données dans l'application PCP Charts et utiliser des graphiques pour visualiser les données rétrospectives avec les données en temps réel du système.
  • Tracer les valeurs des mesures de performance dans des graphiques.
  • Affichage simultané de plusieurs graphiques.

Conditions préalables

Procédure

  1. Lancez l'application PCP Charts à partir de la ligne de commande :

    # pmchart

    Figure 7.1. Application PCP Charts

    pmchart started

    Les paramètres du serveur pmtime sont situés en bas. Les boutons start et pause vous permettent de contrôler :

    • Intervalle dans lequel le PCP interroge les données métriques
    • La date et l'heure des mesures des données historiques
  2. Cliquez sur File puis sur New Chart pour sélectionner une métrique à partir de la machine locale et des machines distantes en spécifiant leur nom d'hôte ou leur adresse. Les options de configuration avancées comprennent la possibilité de définir manuellement les valeurs des axes du graphique et de choisir manuellement la couleur des tracés.
  3. Enregistrer les vues créées dans l'application PCP Charts:

    Les options suivantes permettent de prendre des photos ou d'enregistrer les vues créées dans l'application PCP Charts:

    • Cliquez sur File puis sur Export pour enregistrer une image de la vue actuelle.
    • Cliquez sur Record puis sur Start pour démarrer un enregistrement. Cliquez sur Record puis sur Stop pour arrêter l'enregistrement. Après l'arrêt de l'enregistrement, les mesures enregistrées sont archivées pour être consultées ultérieurement.
  4. Facultatif : dans l'application PCP Charts, le fichier de configuration principal, appelé view, permet de sauvegarder les métadonnées associées à un ou plusieurs graphiques. Ces métadonnées décrivent tous les aspects du graphique, y compris les mesures utilisées et les colonnes du graphique. Enregistrez la configuration personnalisée de view en cliquant sur File puis sur Save View, et chargez la configuration de view ultérieurement.

    L'exemple suivant du fichier de configuration de la vue de l'application PCP Charts décrit un graphique d'empilement montrant le nombre total d'octets lus et écrits dans le système de fichiers XFS donné loop1:

    #kmchart
    version 1
    
    chart title "Filesystem Throughput /loop1" style stacking antialiasing off
        plot legend "Read rate"   metric xfs.read_bytes   instance  "loop1"
        plot legend "Write rate"  metric xfs.write_bytes  instance  "loop1"

Ressources supplémentaires

7.3. Collecte de données à partir d'un serveur SQL à l'aide de PCP

L'agent SQL Server est disponible dans Performance Co-Pilot (PCP), qui vous aide à surveiller et à analyser les problèmes de performance des bases de données.

Cette procédure décrit comment collecter des données pour Microsoft SQL Server via pcp sur votre système.

Conditions préalables

  • Vous avez installé Microsoft SQL Server pour Red Hat Enterprise Linux et établi une connexion "fiable" à un serveur SQL.
  • Vous avez installé le pilote Microsoft ODBC pour SQL Server pour Red Hat Enterprise Linux.

Procédure

  1. Installer le PCP :

    # dnf install pcp-zeroconf
  2. Installer les paquets requis pour le pilote pyodbc:

    # dnf install python3-pyodbc
  3. Installer l'agent mssql:

    1. Installer l'agent de domaine Microsoft SQL Server pour PCP :

      # dnf install pcp-pmda-mssql
    2. Modifiez le fichier /etc/pcp/mssql/mssql.conf pour configurer le nom d'utilisateur et le mot de passe du compte SQL Server pour l'agent mssql. Assurez-vous que le compte que vous configurez a des droits d'accès aux données de performance.

      username: user_name
      password: user_password

      Remplacez user_name par le compte SQL Server et user_password par le mot de passe de l'utilisateur SQL Server pour ce compte.

  4. Installer l'agent :

    # cd /var/lib/pcp/pmdas/mssql
    # ./Install
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check mssql metrics have appeared ... 168 metrics and 598 values
    [...]

Verification steps

  • À l'aide de la commande pcp, vérifiez si le serveur SQL PMDA (mssql) est chargé et en cours d'exécution :

    $ pcp
    Performance Co-Pilot configuration on rhel.local:
    
    platform: Linux rhel.local 4.18.0-167.el8.x86_64 #1 SMP Sun Dec 15 01:24:23 UTC 2019 x86_64
     hardware: 2 cpus, 1 disk, 1 node, 2770MB RAM
     timezone: PDT+7
     services: pmcd pmproxy
         pmcd: Version 5.0.2-1, 12 agents, 4 clients
         pmda: root pmcd proc pmproxy xfs linux nfsclient mmv kvm mssql
               jbd2 dm
     pmlogger: primary logger: /var/log/pcp/pmlogger/rhel.local/20200326.16.31
         pmie: primary engine: /var/log/pcp/pmie/rhel.local/pmie.log
  • Voir la liste complète des mesures que PCP peut collecter à partir du serveur SQL :

    # pminfo mssql
  • Après avoir consulté la liste des mesures, vous pouvez indiquer le taux de transactions. Par exemple, pour connaître le nombre global de transactions par seconde, sur une fenêtre de temps de cinq secondes :

    # pmval -t 1 -T 5 mssql.databases.transactions
  • Affichez le graphique de ces mesures sur votre système à l'aide de la commande pmchart. Pour plus d'informations, voir Tracer visuellement les archives de journaux PCP avec l'application PCP Charts.

Ressources supplémentaires

7.4. Générer des archives PCP à partir d'archives sadc

Vous pouvez utiliser l'outil sadf fourni par le paquetage sysstat pour générer des archives PCP à partir d'archives natives sadc.

Conditions préalables

  • Une archive sadc a été créée :

    # /usr/lib64/sa/sadc 1 5 -

    Dans cet exemple, sadc échantillonne les données du système une fois dans un intervalle de 5 secondes. Le fichier de sortie est spécifié comme étant -, ce qui fait que sadc écrit les données dans le fichier de données quotidiennes standard de l'activité du système. Ce fichier s'appelle saDD et se trouve par défaut dans le répertoire /var/log/sa.

Procédure

  • Générer une archive PCP à partir d'une archive sadc:

    # sadf -l -O pcparchive=/tmp/recording -2

    Dans cet exemple, l'utilisation de l'option -2 permet à sadf de générer une archive PCP à partir d'une archive sadc enregistrée il y a 2 jours.

Verification steps

Vous pouvez utiliser les commandes PCP pour inspecter et analyser l'archive PCP générée à partir d'une archive sadc comme vous le feriez avec une archive PCP native. Par exemple :

  • Pour afficher une liste de métriques dans l'archive PCP générée à partir d'une archive sadc, exécutez la commande suivante :

    $ pminfo --archive /tmp/recording
    Disk.dev.avactive
    Disk.dev.read
    Disk.dev.write
    Disk.dev.blkread
    [...]
  • Pour afficher l'espace temporel de l'archive et le nom d'hôte de l'archive PCP, exécutez :

    $ pmdumplog --label /tmp/recording
    Log Label (Log Format Version 2)
    Performance metrics from host shard
            commencing Tue Jul 20 00:10:30.642477 2021
            ending     Wed Jul 21 00:10:30.222176 2021
  • Pour tracer les valeurs des mesures de performance dans des graphiques, exécutez :

    $ pmchart --archive /tmp/recording

Chapitre 8. Analyse des performances de XFS avec PCP

L'outil XFS PMDA fait partie du paquetage pcp et est activé par défaut lors de l'installation. Il est utilisé pour recueillir des données sur les performances des systèmes de fichiers XFS dans Performance Co-Pilot (PCP).

Vous pouvez utiliser PCP pour analyser les performances du système de fichiers XFS.

8.1. Installation manuelle de XFS PMDA

Si le PMDA XFS n'est pas répertorié dans la sortie de configuration de pcp, installez l'agent PMDA manuellement.

Cette procédure décrit comment installer manuellement l'agent PMDA.

Conditions préalables

Procédure

  1. Naviguez jusqu'au répertoire xfs :

    # cd /var/lib/pcp/pmdas/xfs/
  2. Installer manuellement le PMDA XFS :

    xfs]# ./Install
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check xfs metrics have appeared ... 387 metrics and 387 values

Verification steps

  • Vérifiez que le processus pmcd est en cours d'exécution sur l'hôte et que le XFS PMDA est indiqué comme étant activé dans la configuration :

    # pcp
    
    Performance Co-Pilot configuration on workstation:
    
    platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64
    hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM
    timezone: CEST-2
    services: pmcd
    pmcd: Version 4.3.0-1, 8 agents
    pmda: root pmcd proc xfs linux mmv kvm jbd2

Ressources supplémentaires

8.2. Examen des performances de XFS avec pminfo

PCP permet à XFS PMDA d'établir des rapports sur certaines mesures XFS pour chacun des systèmes de fichiers XFS montés. Il est ainsi plus facile d'identifier les problèmes spécifiques des systèmes de fichiers montés et d'évaluer les performances.

La commande pminfo fournit des mesures XFS par périphérique pour chaque système de fichiers XFS monté.

Cette procédure permet d'afficher une liste de toutes les mesures disponibles fournies par le PMDA XFS.

Conditions préalables

Procédure

  • Affiche la liste de toutes les mesures disponibles fournies par le PMDA XFS :

    # pminfo xfs
  • Afficher des informations sur les mesures individuelles. Les exemples suivants examinent les mesures XFS read et write à l'aide de l'outil pminfo:

    • Affiche une brève description de la métrique xfs.write_bytes:

      # pminfo --oneline xfs.write_bytes
      
      xfs.write_bytes [number of bytes written in XFS file system write operations]
    • Affiche une longue description de la métrique xfs.read_bytes:

      # pminfo --helptext xfs.read_bytes
      
      xfs.read_bytes
      Help:
      This is the number of bytes read via read(2) system calls to files in
      XFS file systems. It can be used in conjunction with the read_calls
      count to calculate the average size of the read operations to file in
      XFS file systems.
    • Obtenir la valeur de performance actuelle de la métrique xfs.read_bytes:

      # pminfo --fetch xfs.read_bytes
      
      xfs.read_bytes
          value 4891346238
    • Obtenir les métriques XFS par périphérique avec pminfo:

      # pminfo --fetch --oneline xfs.perdev.read xfs.perdev.write
      
      xfs.perdev.read [number of XFS file system read operations]
      inst [0 or "loop1"] value 0
      inst [0 or "loop2"] value 0
      
      xfs.perdev.write [number of XFS file system write operations]
      inst [0 or "loop1"] value 86
      inst [0 or "loop2"] value 0

8.3. Réinitialisation des mesures de performance XFS avec pmstore

Avec PCP, vous pouvez modifier les valeurs de certaines métriques, en particulier si la métrique agit comme une variable de contrôle, comme la métrique xfs.control.reset. Pour modifier la valeur d'une métrique, utilisez l'outil pmstore.

Cette procédure décrit comment réinitialiser les métriques XFS à l'aide de l'outil pmstore.

Conditions préalables

Procédure

  1. Affiche la valeur d'une métrique :

    $ pminfo -f xfs.write
    
    xfs.write
        value 325262
  2. Réinitialiser toutes les mesures XFS :

    # pmstore xfs.control.reset 1
    
    xfs.control.reset old value=0 new value=1

Verification steps

  • Afficher les informations après la réinitialisation du système métrique :

    $ pminfo --fetch xfs.write
    
    xfs.write
        value 0

Ressources supplémentaires

8.4. Groupes de métriques PCP pour XFS

Le tableau suivant décrit les groupes de métriques PCP disponibles pour XFS.

Tableau 8.1. Groupes de métriques pour XFS

Groupe métrique

Mesures fournies

xfs.*

Métriques XFS générales comprenant le nombre d'opérations de lecture et d'écriture, le nombre d'octets de lecture et d'écriture. Il existe également des compteurs pour le nombre de fois où les inodes sont vidés, mis en cluster et le nombre d'échecs de mise en cluster.

xfs.allocs.*

xfs.alloc_btree.*

Gamme de mesures concernant l'allocation d'objets dans le système de fichiers, notamment le nombre de créations/libres d'étendues et de blocs. Recherche et comparaison de l'arbre d'allocation, ainsi que création et suppression d'enregistrements d'extension dans l'arbre d'allocation.

xfs.block_map.*

xfs.bmap_btree.*

Les mesures comprennent le nombre de lectures/écritures de la carte de blocs et de suppressions de blocs, les opérations de liste d'étendue pour l'insertion, les suppressions et les consultations. Il existe également des compteurs d'opérations pour les comparaisons, les consultations, les insertions et les suppressions de la carte de blocs.

xfs.dir_ops.*

Compteurs pour les opérations de répertoire sur les systèmes de fichiers XFS pour la création, les suppressions d'entrées, le nombre d'opérations "getdent".

xfs.transactions.*

Compteurs pour le nombre de transactions de métadonnées, comprenant le nombre de transactions synchrones et asynchrones ainsi que le nombre de transactions vides.

xfs.inode_ops.*

Compteurs du nombre de fois où le système d'exploitation a recherché un inode XFS dans le cache d'inodes avec différents résultats. Ces compteurs comptabilisent les occurrences dans le cache, les échecs dans le cache, etc.

xfs.log.*

xfs.log_tail.*

Les compteurs du nombre d'écritures du tampon de journal sur les systèmes de fichiers XFS comprennent le nombre de blocs écrits sur le disque. Des mesures sont également disponibles pour le nombre de vidanges et d'épinglages de journaux.

xfs.xstrat.*

Compteurs du nombre d'octets de données de fichiers évacués par le déamon de vidange XFS, ainsi que des compteurs du nombre de tampons évacués vers l'espace contigu et non contigu du disque.

xfs.attr.*

Compte le nombre d'opérations d'obtention, de définition, de suppression et d'énumération d'attributs sur tous les systèmes de fichiers XFS.

xfs.quota.*

Mesures pour le fonctionnement des quotas sur les systèmes de fichiers XFS, y compris les compteurs pour le nombre de réclamations de quotas, les échecs de cache de quotas, les occurrences de cache et les réclamations de données de quotas.

xfs.buffer.*

Gamme de mesures concernant les objets tampons XFS. Les compteurs incluent le nombre d'appels de tampons demandés, de verrous de tampons réussis, de verrous de tampons attendus, de miss_locks, de miss_retries et d'occurrences de tampons lors de la recherche de pages.

xfs.btree.*

Métriques concernant les opérations de l'arborescence XFS.

xfs.control.reset

Métriques de configuration utilisées pour réinitialiser les compteurs de métriques pour les statistiques XFS. Les métriques de contrôle sont modifiées à l'aide de l'outil pmstore.

8.5. Groupes de métriques PCP par périphérique pour XFS

Le tableau suivant décrit le groupe de métriques PCP disponible par périphérique pour XFS.

Tableau 8.2. Groupes de métriques PCP par périphérique pour XFS

Groupe métrique

Mesures fournies

xfs.perdev.*

Métriques XFS générales comprenant le nombre d'opérations de lecture et d'écriture, le nombre d'octets de lecture et d'écriture. Il existe également des compteurs pour le nombre de fois où les inodes sont vidés, mis en cluster et le nombre d'échecs de mise en cluster.

xfs.perdev.allocs.*

xfs.perdev.alloc_btree.*

Gamme de mesures concernant l'allocation d'objets dans le système de fichiers, notamment le nombre de créations/libres d'étendues et de blocs. Recherche et comparaison de l'arbre d'allocation, ainsi que création et suppression d'enregistrements d'extension dans l'arbre d'allocation.

xfs.perdev.block_map.*

xfs.perdev.bmap_btree.*

Les mesures comprennent le nombre de lectures/écritures de la carte de blocs et de suppressions de blocs, les opérations de liste d'étendue pour l'insertion, les suppressions et les consultations. Il existe également des compteurs d'opérations pour les comparaisons, les consultations, les insertions et les suppressions de la carte de blocs.

xfs.perdev.dir_ops.*

Compteurs pour les opérations de répertoire des systèmes de fichiers XFS pour la création, les suppressions d'entrées, le nombre d'opérations "getdent".

xfs.perdev.transactions.*

Compteurs pour le nombre de transactions de métadonnées, comprenant le nombre de transactions synchrones et asynchrones ainsi que le nombre de transactions vides.

xfs.perdev.inode_ops.*

Compteurs du nombre de fois où le système d'exploitation a recherché un inode XFS dans le cache d'inodes avec différents résultats. Ces compteurs comptabilisent les occurrences dans le cache, les échecs dans le cache, etc.

xfs.perdev.log.*

xfs.perdev.log_tail.*

Les compteurs du nombre d'écritures du tampon de journal sur les systèmes de fichiers XFS comprennent le nombre de blocs écrits sur le disque. Des mesures sont également disponibles pour le nombre de vidanges et d'épinglages de journaux.

xfs.perdev.xstrat.*

Compteurs du nombre d'octets de données de fichiers évacués par le déamon de vidange XFS, ainsi que des compteurs du nombre de tampons évacués vers l'espace contigu et non contigu du disque.

xfs.perdev.attr.*

Compte le nombre d'opérations d'obtention, de définition, de suppression et d'énumération d'attributs sur tous les systèmes de fichiers XFS.

xfs.perdev.quota.*

Mesures pour le fonctionnement des quotas sur les systèmes de fichiers XFS, y compris les compteurs pour le nombre de réclamations de quotas, les échecs de cache de quotas, les occurrences de cache et les réclamations de données de quotas.

xfs.perdev.buffer.*

Gamme de mesures concernant les objets tampons XFS. Les compteurs incluent le nombre d'appels de tampons demandés, de verrous de tampons réussis, de verrous de tampons attendus, de miss_locks, de miss_retries et d'occurrences de tampons lors de la recherche de pages.

xfs.perdev.btree.*

Métriques concernant les opérations de l'arborescence XFS.

Chapitre 9. Mise en place d'une représentation graphique des mesures PCP

L'utilisation d'une combinaison de pcp, grafana, pcp redis, pcp bpftrace, et pcp vector fournit une représentation graphique des données en direct ou des données collectées par Performance Co-Pilot (PCP).

9.1. Mise en place de PCP avec pcp-zeroconf

Cette procédure décrit comment configurer PCP sur un système doté du paquetage pcp-zeroconf. Une fois le paquetage pcp-zeroconf installé, le système enregistre le jeu de métriques par défaut dans des fichiers archivés.

Procédure

  • Installez le paquetage pcp-zeroconf:

    # dnf install pcp-zeroconf

Verification steps

  • Assurez-vous que le service pmlogger est actif et qu'il commence à archiver les mesures :

    # pcp | grep pmlogger
     pmlogger: primary logger: /var/log/pcp/pmlogger/localhost.localdomain/20200401.00.12

Ressources supplémentaires

9.2. Mise en place d'un serveur grafana

Grafana génère des graphiques accessibles depuis un navigateur. Le site grafana-server est un serveur dorsal pour le tableau de bord Grafana. Il écoute, par défaut, toutes les interfaces et fournit des services web accessibles via le navigateur web. Le plugin grafana-pcp interagit avec le protocole pmproxy dans le backend.

Cette procédure décrit comment configurer un site grafana-server.

Conditions préalables

Procédure

  1. Install the following packages:

    # dnf install grafana grafana-pcp
  2. Redémarrez et activez le service suivant :

    # systemctl restart grafana-server
    # systemctl enable grafana-server
  3. Ouvrez le pare-feu du serveur pour le trafic réseau vers le service Grafana.

    # firewall-cmd --permanent --add-service=grafana
    success
    
    # firewall-cmd --reload
    success

Verification steps

  • S'assurer que le site grafana-server est à l'écoute et répond aux demandes :

    # ss -ntlp | grep 3000
    LISTEN  0  128  *:3000  *:*  users:(("grafana-server",pid=19522,fd=7))
  • Assurez-vous que le plugin grafana-pcp est installé :

    # grafana-cli plugins ls | grep performancecopilot-pcp-app
    
    performancecopilot-pcp-app @ 3.1.0

Ressources supplémentaires

  • pmproxy(1) et grafana-server pages de manuel

9.3. Accéder à l'interface web de Grafana

Cette procédure décrit comment accéder à l'interface web de Grafana.

En utilisant l'interface web de Grafana, vous pouvez :

  • ajouter les sources de données PCP Redis, PCP bpftrace et PCP Vector
  • créer un tableau de bord
  • afficher une vue d'ensemble de toutes les mesures utiles
  • créer des alertes dans PCP Redis

Conditions préalables

  1. PCP est configuré. Pour plus d'informations, voir Configuration de PCP avec pcp-zeroconf.
  2. Le site grafana-server est configuré. Pour plus d'informations, voir Configuration d'un serveur grafana.

Procédure

  1. Sur le système client, ouvrez un navigateur et accédez à grafana-server sur le port 3000, en utilisant le lien http://192.0.2.0:3000.

    Remplacez 192.0.2.0 par l'IP de votre machine.

  2. Pour la première connexion, saisissez admin dans les champs Email or username et Password.

    Grafana vous invite à définir un New password pour créer un compte sécurisé. Si vous souhaitez le définir plus tard, cliquez sur Skip.

  3. Dans le menu, survolez l'icône icône d'engrenage grafana Configuration puis cliquez sur Plugins.
  4. Dans l'onglet Plugins, tapez performance co-pilot dans la zone de texte Search by name or type puis cliquez sur Performance Co-Pilot (PCP) plugin.
  5. Dans le volet Plugins / Performance Co-Pilot, cliquez sur Activer.
  6. Cliquez sur Grafana page d'accueil de Grafana icône tourbillon (tourbillon). La page Grafana Home s'affiche.

    Figure 9.1. Tableau de bord de l'accueil

    grafana home dashboard
    Note

    Le coin supérieur de l'écran présente une icône similaire grafana top corner settings icon mais elle contrôle les paramètres généraux de Dashboard settings.

  7. Dans la page Grafana Home, cliquez sur Add your first data source pour ajouter les sources de données PCP Redis, PCP bpftrace et PCP Vector. Pour plus d'informations sur l'ajout de sources de données, voir :

  8. Facultatif : Dans le menu, survolez l'icône du profil admin icône de l'option de déconnexion de grafana pour changer le Preferences en Edit Profile, Change Password, ou en Sign out.

Ressources supplémentaires

  • grafana-cli et grafana-server pages de manuel

9.4. Configurer des connexions sécurisées pour Grafana

Vous pouvez établir des connexions sécurisées entre les composants Grafana et Performance Co-Pilot (PCP). L'établissement de connexions sécurisées entre ces composants permet d'empêcher les parties non autorisées d'accéder aux données collectées et surveillées ou de les modifier.

Conditions préalables

  • PCP est installé. Pour plus d'informations, voir Installation et activation de PCP.
  • Le site grafana-server est configuré. Pour plus d'informations, voir Configuration d'un serveur grafana.
  • La clé privée du client est stockée dans le fichier /etc/grafana/grafana.key. Si vous utilisez un chemin différent, modifiez-le dans les étapes correspondantes de la procédure.

    Pour plus de détails sur la création d'une clé privée et d'une demande de signature de certificat (CSR), ainsi que sur la manière de demander un certificat à une autorité de certification (AC), consultez la documentation de votre AC.

  • Le certificat client TLS est stocké dans le fichier /etc/grafana/grafana.crt. Si vous utilisez un chemin différent, modifiez le chemin dans les étapes correspondantes de la procédure.

Procédure

  1. En tant qu'utilisateur root, ouvrez le fichier /etc/grafana/grana.ini et ajustez les options suivantes dans la section [server] pour refléter ce qui suit :

    protocol = https
    cert_key = /etc/grafana/grafana.key
    cert_file = /etc/grafana/grafana.crt
  2. Assurez-vous que grafana peut accéder aux certificats :

    # su grafana -s /bin/bash -c \
      'ls -1 /etc/grafana/grafana.crt /etc/grafana/grafana.key'
    /etc/grafana/grafana.crt
    /etc/grafana/grafana.key
  3. Redémarrez et activez le service Grafana pour appliquer les modifications de configuration :

    # systemctl restart grafana-server
    # systemctl enable grafana-server

Vérification

  1. Sur le système client, ouvrez un navigateur et accédez à la machine grafana-server sur le port 3000, en utilisant le lien https://192.0.2.0:3000. Remplacez 192.0.2.0 par l'IP de votre machine.
  2. Confirmer l'icône icône de verrouillage l'icône de verrouillage s'affiche à côté de la barre d'adresse.

    Note

    Si le protocole est défini sur http et qu'une connexion HTTPS est tentée, vous recevrez une erreur ERR_SSL_PROTOCOL_ERROR. Si le protocole est défini sur https et qu'une connexion HTTP est tentée, le serveur Grafana répond par un message "Client sent an HTTP request to an HTTPS server".

9.5. Configuration de PCP Redis

Utilisez la source de données Redis de PCP pour :

  • Voir les archives de données
  • Interroger les séries temporelles à l'aide du langage pmseries
  • Analyser les données sur plusieurs hôtes

Conditions préalables

  1. PCP est configuré. Pour plus d'informations, voir Configuration de PCP avec pcp-zeroconf.
  2. Le site grafana-server est configuré. Pour plus d'informations, voir Configuration d'un serveur grafana.

Procédure

  1. Installez le paquetage redis:

    # dnf install redis
  2. Démarrez et activez les services suivants :

    # systemctl start pmproxy redis
    # systemctl enable pmproxy redis
  3. L'agent de transfert de courrier, par exemple sendmail ou postfix, est installé et configuré.
  4. Assurez-vous que le paramètre allow_loading_unsigned_plugins est défini sur la base de données PCP Redis dans le fichier grafana.ini:

    # vi /etc/grafana/grafana.ini
    
    allow_loading_unsigned_plugins = pcp-redis-datasource
  5. Redémarrer le site grafana-server:

    # systemctl restart grafana-server

Verification steps

  • Assurez-vous que les sites pmproxy et redis fonctionnent :

    # pmseries disk.dev.read
    2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df

    Cette commande ne renvoie aucune donnée si le paquetage redis n'est pas installé.

Ressources supplémentaires

  • pmseries(1) page de manuel

9.6. Configurer des connexions sécurisées pour PCP redis

Vous pouvez établir des connexions sécurisées entre Performance Co-Pilot (PCP), Grafana et PCP Redis. L'établissement de connexions sécurisées entre ces composants permet d'empêcher les parties non autorisées d'accéder aux données collectées et surveillées ou de les modifier.

Conditions préalables

  • PCP est installé. Pour plus d'informations, voir Installation et activation de PCP.
  • Le site grafana-server est configuré. Pour plus d'informations, voir Configuration d'un serveur grafana.
  • PCP redis est installé. Pour plus d'informations, voir Configuration de PCP Redis.
  • La clé privée du client est stockée dans le fichier /etc/redis/client.key. Si vous utilisez un chemin différent, modifiez-le dans les étapes correspondantes de la procédure.

    Pour plus de détails sur la création d'une clé privée et d'une demande de signature de certificat (CSR), ainsi que sur la manière de demander un certificat à une autorité de certification (AC), consultez la documentation de votre AC.

  • Le certificat client TLS est stocké dans le fichier /etc/redis/client.crt. Si vous utilisez un chemin différent, modifiez le chemin dans les étapes correspondantes de la procédure.
  • La clé du serveur TLS est stockée dans le fichier /etc/redis/redis.key. Si vous utilisez un chemin différent, modifiez le chemin dans les étapes correspondantes de la procédure.
  • Le certificat du serveur TLS est stocké dans le fichier /etc/redis/redis.crt. Si vous utilisez un chemin différent, modifiez le chemin dans les étapes correspondantes de la procédure.
  • Le certificat CA est stocké dans le fichier /etc/redis/ca.crt. Si vous utilisez un chemin différent, modifiez-le dans les étapes correspondantes de la procédure.

En outre, pour le démon pmproxy:

  • La clé privée du serveur est stockée dans le fichier /etc/pcp/tls/server.key. Si vous utilisez un chemin différent, modifiez le chemin dans les étapes correspondantes de la procédure.

Procédure

  1. En tant qu'utilisateur root, ouvrez le fichier /etc/redis/redis.conf et ajustez les options TLS/SSL pour refléter les propriétés suivantes :

    port 0
    tls-port 6379
    tls-cert-file /etc/redis/redis.crt
    tls-key-file /etc/redis/redis.key
    tls-client-key-file /etc/redis/client.key
    tls-client-cert-file /etc/redis/client.crt
    tls-ca-cert-file /etc/redis/ca.crt
  2. Assurez-vous que redis peut accéder aux certificats TLS :

    # su redis -s /bin/bash -c \
      'ls -1 /etc/redis/ca.crt /etc/redis/redis.key /etc/redis/redis.crt'
    /etc/redis/ca.crt
    /etc/redis/redis.crt
    /etc/redis/redis.key
  3. Redémarrez le serveur redis pour appliquer les changements de configuration :

    # systemctl restart redis

Vérification

  • Confirmez que la configuration TLS fonctionne :

    # redis-cli --tls --cert /etc/redis/client.crt \
        --key /etc/redis/client.key \
        --cacert /etc/redis/ca.crt <<< "PING"
    PONG

    Une configuration TLS infructueuse peut entraîner le message d'erreur suivant :

    Could not negotiate a TLS connection: Invalid CA Certificate File/Directory

9.7. Création de panneaux et d'alertes dans la source de données Redis de PCP

Après avoir ajouté la source de données PCP Redis, vous pouvez afficher le tableau de bord avec un aperçu des mesures utiles, ajouter une requête pour visualiser le graphique de charge et créer des alertes qui vous aideront à visualiser les problèmes du système après qu'ils se soient produits.

Conditions préalables

  1. Le PCP Redis est configuré. Pour plus d'informations, voir Configuration de PCP Redis.
  2. Le site grafana-server est accessible. Pour plus d'informations, voir Accéder à l'interface web de Grafana.

Procédure

  1. Connectez-vous à l'interface web de Grafana.
  2. Dans la page Grafana Home, cliquez sur Add your first data source.
  3. Dans le volet Add data source, tapez redis dans la zone de texte Filter by name or type et cliquez sur PCP Redis.
  4. Dans le volet Data Sources / PCP Redis, effectuez les opérations suivantes :

    1. Ajoutez http://localhost:44322 dans le champ URL et cliquez sur Save & Test.
    2. Cliquez sur Onglet Tableaux de bordImporterPCP Redis : Aperçu de l'hôte pour afficher un tableau de bord avec une vue d'ensemble de toutes les mesures utiles.

      Figure 9.2. PCP Redis : Présentation de l'hôte

      pcp redis host overview
  5. Ajouter un nouveau panneau :

    1. Dans le menu, survolez le signe signe plus grafana Icône de créationTableau de bordAjouter une nouvelle icône de tableau de bord pour ajouter un tableau de bord.
    2. Dans l'onglet Query, sélectionnez l'option PCP Redis dans la liste des requêtes au lieu de l'option default et dans le champ de texte A, entrez une métrique, par exemple kernel.all.load pour visualiser le graphique de charge du noyau.
    3. Optionnel : Ajoutez Panel title et Description, et mettez à jour les autres options du site Settings.
    4. Cliquez sur Enregistrer pour appliquer les modifications et sauvegarder le tableau de bord. Ajouter Dashboard name.
    5. Cliquez sur Appliquer pour appliquer les modifications et revenir au tableau de bord.

      Figure 9.3. Panneau de requêtes Redis PCP

      pcp redis query panel
  6. Créer une règle d'alerte :

    1. Dans le site PCP Redis query panel, cliquez sur l'icône d'alerte redis Alert puis cliquez sur Create Alert.
    2. Modifiez les champs Name, Evaluate query, et For à partir du champ Rule, et spécifiez le champ Conditions pour votre alerte.
    3. Cliquez sur Enregistrer pour appliquer les modifications et sauvegarder le tableau de bord. Cliquez sur Appliquer pour appliquer les modifications et revenir au tableau de bord.

      Figure 9.4. Création d'alertes dans le tableau de bord Redis de PCP

      pcp redis query alert panel
    4. Facultatif : dans le même panneau, faites défiler vers le bas et cliquez sur l'icône Supprimer pour supprimer la règle créée.
    5. Optionnel : Dans le menu, cliquez sur icône de cloche d'alerte Alerting pour afficher les règles d'alerte créées avec différents états d'alerte, pour modifier la règle d'alerte ou pour mettre en pause la règle existante à partir de l'onglet Alert Rules.

      Pour ajouter un canal de notification pour la règle d'alerte créée afin de recevoir une notification d'alerte de Grafana, voir Ajouter des canaux de notification pour les alertes.

9.8. Ajout de canaux de notification pour les alertes

En ajoutant des canaux de notification, vous pouvez recevoir une notification d'alerte de Grafana chaque fois que les conditions de la règle d'alerte sont remplies et que le système nécessite une surveillance supplémentaire.

Vous pouvez recevoir ces alertes après avoir sélectionné un type parmi la liste des notificateurs pris en charge, qui comprend DingDing, Discord, Email, Google Hangouts Chat, HipChat, Kafka REST Proxy, LINE, Microsoft Teams, OpsGenie, PagerDuty, Prometheus Alertmanager, Pushover, Sensu, Slack, Telegram, Threema Gateway, VictorOps, et webhook.

Conditions préalables

  1. Le site grafana-server est accessible. Pour plus d'informations, voir Accéder à l'interface web de Grafana.
  2. Une règle d'alerte est créée. Pour plus d'informations, voir Création de panneaux et d'alertes dans la source de données Redis de PCP.
  3. Configurez le SMTP et ajoutez une adresse électronique d'expéditeur valide dans le fichier grafana/grafana.ini:

    # vi /etc/grafana/grafana.ini
    
    [smtp]
    enabled = true
    from_address = abc@gmail.com

    Remplacez abc@gmail.com par une adresse électronique valide.

  4. Redémarrage grafana-server

    # systemctl restart grafana-server.service

Procédure

  1. Dans le menu, survolez l'icône icône de la cloche d'alerte Icône d'alertecliquez sur Points de contactNouveau point de contact.
  2. Dans la vue détaillée de New contact point, procédez comme suit :

    1. Saisissez votre nom dans la zone de texte Name
    2. Sélectionnez l'option Contact point type, par exemple, Email et saisissez l'adresse électronique. Vous pouvez ajouter plusieurs adresses électroniques en utilisant le séparateur ;.
    3. En option : Configurez Optional Email settings et Notification settings.
  3. Cliquez sur Enregistrer le point de contact.
  4. Sélectionnez un canal de notification dans la règle d'alerte :

    1. Dans le menu, sélectionnez l'icône Notification policies puis cliquez sur New specific policy.
    2. Choisissez le site Contact point que vous venez de créer
    3. Cliquez sur le bouton Save policy

9.9. Mise en place de l'authentification entre les composants du PCP

Vous pouvez configurer l'authentification à l'aide du mécanisme d'authentification scram-sha-256, qui est pris en charge par PCP via le cadre SASL (Simple Authentication Security Layer).

Procédure

  1. Installez le cadre sasl pour le mécanisme d'authentification scram-sha-256:

    # dnf install cyrus-sasl-scram cyrus-sasl-lib
  2. Spécifiez le mécanisme d'authentification pris en charge et le chemin d'accès à la base de données des utilisateurs dans le fichier pmcd.conf:

    # vi /etc/sasl2/pmcd.conf
    
    mech_list: scram-sha-256
    
    sasldb_path: /etc/pcp/passwd.db
  3. Créer un nouvel utilisateur :

    # useradd -r metrics

    Remplacez metrics par votre nom d'utilisateur.

  4. Ajouter l'utilisateur créé dans la base de données des utilisateurs :

    # saslpasswd2 -a pmcd metrics
    
    Password:
    Again (for verification):

    Pour ajouter l'utilisateur créé, vous devez saisir le mot de passe du compte metrics.

  5. Définir les autorisations de la base de données des utilisateurs :

    # chown root:pcp /etc/pcp/passwd.db
    # chmod 640 /etc/pcp/passwd.db
  6. Redémarrez le service pmcd:

    # systemctl restart pmcd

Verification steps

  • Vérifiez la configuration de sasl:

    # pminfo -f -h "pcp://127.0.0.1?username=metrics" disk.dev.read
    Password:
    disk.dev.read
    inst [0 or "sda"] value 19540

Ressources supplémentaires

9.10. Installation de PCP bpftrace

Installez l'agent PCP bpftrace afin d'introspecter un système et de recueillir des mesures à partir des points de contrôle du noyau et de l'espace utilisateur.

L'agent bpftrace utilise des scripts bpftrace pour collecter les mesures. Les scripts bpftrace utilisent le filtre de paquets Berkeley amélioré (eBPF).

Cette procédure décrit comment installer un pcp bpftrace.

Conditions préalables

  1. PCP est configuré. Pour plus d'informations, voir Configuration de PCP avec pcp-zeroconf.
  2. Le site grafana-server est configuré. Pour plus d'informations, voir Configuration d'un serveur grafana.
  3. Le mécanisme d'authentification scram-sha-256 est configuré. Pour plus d'informations, voir Configuration de l'authentification entre les composants PCP.

Procédure

  1. Installez le paquetage pcp-pmda-bpftrace:

    # dnf install pcp-pmda-bpftrace
  2. Modifiez le fichier bpftrace.conf et ajoutez l'utilisateur que vous avez créé dans le fichier {setting-up-authentication-between-pcp-components} :

    # vi /var/lib/pcp/pmdas/bpftrace/bpftrace.conf
    
    [dynamic_scripts]
    enabled = true
    auth_enabled = true
    allowed_users = root,metrics

    Remplacez metrics par votre nom d'utilisateur.

  3. Installer bpftrace PMDA :

    # cd /var/lib/pcp/pmdas/bpftrace/
    # ./Install
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check bpftrace metrics have appeared ... 7 metrics and 6 values

    Le site pmda-bpftrace est maintenant installé et ne peut être utilisé qu'après authentification de l'utilisateur. Pour plus d'informations, voir Affichage du tableau de bord d'analyse du système PCP bpftrace.

Ressources supplémentaires

  • pmdabpftrace(1) et bpftrace pages de manuel

9.11. Visualisation du tableau de bord d'analyse du système PCP bpftrace

En utilisant la source de données PCP bpftrace, vous pouvez accéder aux données en direct provenant de sources qui ne sont pas disponibles en tant que données normales sur le site pmlogger ou dans les archives

Dans la source de données PCP bpftrace, vous pouvez consulter le tableau de bord avec une vue d'ensemble des mesures utiles.

Conditions préalables

  1. Le programme PCP bpftrace est installé. Pour plus d'informations, voir Installation de PCP bpftrace.
  2. Le site grafana-server est accessible. Pour plus d'informations, voir Accéder à l'interface web de Grafana.

Procédure

  1. Connectez-vous à l'interface web de Grafana.
  2. Dans la page Grafana Home, cliquez sur Add your first data source.
  3. Dans le volet Add data source, tapez bpftrace dans la zone de texte Filter by name or type et cliquez sur PCP bpftrace.
  4. Dans le volet Data Sources / PCP bpftrace, effectuez les opérations suivantes :

    1. Ajoutez http://localhost:44322 dans le champ URL.
    2. Activez l'option Basic Auth et ajoutez les informations d'identification de l'utilisateur créé dans les champs User et Password.
    3. Cliquez sur Enregistrer & Test.

      Figure 9.5. Ajout du PCP bpftrace dans la source de données

      bpftrace auth
    4. Cliquez sur Onglet Tableaux de bordImporterPCP bpftrace : Analyse du système pour afficher un tableau de bord avec une vue d'ensemble de toutes les mesures utiles.

      Figure 9.6. PCP bpftrace : Analyse du système

      pcp bpftrace bpftrace system analysis

9.12. Installation de PCP Vector

Cette procédure décrit comment installer un pcp vector.

Conditions préalables

  1. PCP est configuré. Pour plus d'informations, voir Configuration de PCP avec pcp-zeroconf.
  2. Le site grafana-server est configuré. Pour plus d'informations, voir Configuration d'un serveur grafana.

Procédure

  1. Installez le paquetage pcp-pmda-bcc:

    # dnf install pcp-pmda-bcc
  2. Installez le PMDA bcc:

    # cd /var/lib/pcp/pmdas/bcc
    # ./Install
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: Initializing, currently in 'notready' state.
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: Enabled modules:
    [Wed Apr  1 00:27:48] pmdabcc(22341) Info: ['biolatency', 'sysfork',
    [...]
    Updating the Performance Metrics Name Space (PMNS) ...
    Terminate PMDA if already installed ...
    Updating the PMCD control file, and notifying PMCD ...
    Check bcc metrics have appeared ... 1 warnings, 1 metrics and 0 values

Ressources supplémentaires

  • pmdabcc(1) page de manuel

9.13. Visualisation de la liste de contrôle du vecteur PCP

La source de données PCP Vector affiche des métriques en temps réel et utilise les métriques pcp. Elle analyse les données pour des hôtes individuels.

Après avoir ajouté la source de données PCP Vector, vous pouvez afficher le tableau de bord avec une vue d'ensemble des mesures utiles et consulter les liens de dépannage ou de référence dans la liste de contrôle.

Conditions préalables

  1. Le PCP Vector est installé. Pour plus d'informations, voir Installation de PCP Vector.
  2. Le site grafana-server est accessible. Pour plus d'informations, voir Accéder à l'interface web de Grafana.

Procédure

  1. Connectez-vous à l'interface web de Grafana.
  2. Dans la page Grafana Home, cliquez sur Add your first data source.
  3. Dans le volet Add data source, tapez vector dans la zone de texte Filter by name or type et cliquez sur PCP Vector.
  4. Dans le volet Data Sources / PCP Vector, effectuez les opérations suivantes :

    1. Ajoutez http://localhost:44322 dans le champ URL et cliquez sur Save & Test.
    2. Cliquez sur Onglet Tableaux de bordImporterVecteur PCP : Aperçu de l'hôte pour afficher un tableau de bord avec une vue d'ensemble de toutes les mesures utiles.

      Figure 9.7. Vecteur PCP : Présentation de l'hôte

      pcp vector host overview
  5. Dans le menu, survolez la rubrique plugin pcp dans grafana Performance Co-Pilot puis cliquez sur PCP Vector Checklist.

    Dans la liste de contrôle PCP, cliquez sur pcp vector checklist troubleshooting doc ou sur liste de contrôle du vecteur pcp avertissement pour afficher les liens de dépannage ou de référence correspondants.

    Figure 9.8. Liste de contrôle du vecteur du copilote de performance / PCP

    pcp vector checklist

9.14. Résolution des problèmes liés à Grafana

Il est parfois nécessaire de résoudre des problèmes liés à Grafana, tels que Grafana n'affiche aucune donnée, le tableau de bord est noir, ou d'autres problèmes similaires.

Procédure

  • Vérifiez que le service pmlogger est opérationnel en exécutant la commande suivante :

    $ systemctl status pmlogger
  • Vérifiez si des fichiers ont été créés ou modifiés sur le disque en exécutant la commande suivante :

    $ ls /var/log/pcp/pmlogger/$(hostname)/ -rlt
    total 4024
    -rw-r--r--. 1 pcp pcp   45996 Oct 13  2019 20191013.20.07.meta.xz
    -rw-r--r--. 1 pcp pcp     412 Oct 13  2019 20191013.20.07.index
    -rw-r--r--. 1 pcp pcp   32188 Oct 13  2019 20191013.20.07.0.xz
    -rw-r--r--. 1 pcp pcp   44756 Oct 13  2019 20191013.20.30-00.meta.xz
    [..]
  • Vérifiez que le service pmproxy fonctionne en exécutant la commande suivante :

    $ systemctl status pmproxy
  • Vérifiez que pmproxy est en cours d'exécution, que la prise en charge des séries temporelles est activée et qu'une connexion à Redis est établie en consultant le fichier /var/log/pcp/pmproxy/pmproxy.log et en vous assurant qu'il contient le texte suivant :

    pmproxy(1716) Info: Redis slots, command keys, schema version setup

    Ici, 1716 est le PID de pmproxy, qui sera différent pour chaque invocation de pmproxy.

  • Vérifiez si la base de données Redis contient des clés en exécutant la commande suivante :

    $ redis-cli dbsize
    (integer) 34837
  • Vérifiez si des mesures PCP se trouvent dans la base de données Redis et si pmproxy est en mesure d'y accéder en exécutant les commandes suivantes :

    $ pmseries disk.dev.read
    2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    
    $ pmseries "disk.dev.read[count:10]"
    2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
        [Mon Jul 26 12:21:10.085468000 2021] 117971 70e83e88d4e1857a3a31605c6d1333755f2dd17c
        [Mon Jul 26 12:21:00.087401000 2021] 117758 70e83e88d4e1857a3a31605c6d1333755f2dd17c
        [Mon Jul 26 12:20:50.085738000 2021] 116688 70e83e88d4e1857a3a31605c6d1333755f2dd17c
    [...]
    $ redis-cli --scan --pattern "*$(pmseries 'disk.dev.read')"
    
    pcp:metric.name:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:values:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:desc:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:labelvalue:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:instances:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
    pcp:labelflags:series:2eb3e58d8f1e231361fb15cf1aa26fe534b4d9df
  • Vérifiez s'il y a des erreurs dans les journaux de Grafana en exécutant la commande suivante :

    $ journalctl -e -u grafana-server
    -- Logs begin at Mon 2021-07-26 11:55:10 IST, end at Mon 2021-07-26 12:30:15 IST. --
    Jul 26 11:55:17 localhost.localdomain systemd[1]: Starting Grafana instance...
    Jul 26 11:55:17 localhost.localdomain grafana-server[1171]: t=2021-07-26T11:55:17+0530 lvl=info msg="Starting Grafana" logger=server version=7.3.6 c>
    Jul 26 11:55:17 localhost.localdomain grafana-server[1171]: t=2021-07-26T11:55:17+0530 lvl=info msg="Config loaded from" logger=settings file=/usr/s>
    Jul 26 11:55:17 localhost.localdomain grafana-server[1171]: t=2021-07-26T11:55:17+0530 lvl=info msg="Config loaded from" logger=settings file=/etc/g>
    [...]

Chapitre 10. Optimiser les performances du système à l'aide de la console web

Découvrez comment définir un profil de performance dans la console web RHEL afin d'optimiser les performances du système pour une tâche donnée.

10.1. Options de réglage des performances dans la console web

Red Hat Enterprise Linux 9 fournit plusieurs profils de performance qui optimisent le système pour les tâches suivantes :

  • Systèmes utilisant le bureau
  • Performance en termes de débit
  • Performance en matière de latence
  • Performance du réseau
  • Faible consommation d'énergie
  • Machines virtuelles

Le service TuneD optimise les options du système en fonction du profil sélectionné.

Dans la console web, vous pouvez définir le profil de performance utilisé par votre système.

Ressources supplémentaires

10.2. Définition d'un profil de performance dans la console web

Cette procédure utilise la console web pour optimiser les performances du système pour une tâche sélectionnée.

Conditions préalables

Procédure

  1. Connectez-vous à la console web RHEL. Pour plus d'informations, voir Connexion à la console web.
  2. Cliquez sur Overview.
  3. Dans le champ Performance Profile, cliquez sur le profil de performance actuel.

    profil de performance du cockpit pf4

  4. Dans la boîte de dialogue Change Performance Profile, modifiez le profil si nécessaire.
  5. Cliquez sur Change Profile.

    modification du profil de performance du cockpit pf4

Verification steps

  • L'onglet Overview affiche désormais le profil de performance sélectionné.

10.3. Contrôle des performances sur le système local à l'aide de la console web

La console web de Red Hat Enterprise Linux utilise la méthode USE (Utilization Saturation and Errors) pour le dépannage. La nouvelle page de mesures de performance présente une vue historique de vos données organisée chronologiquement avec les données les plus récentes en haut de la page.

Vous pouvez y consulter les événements, les erreurs et la représentation graphique de l'utilisation et de la saturation des ressources.

Conditions préalables

  • La console web est installée et accessible. Pour plus de détails, voir Installation de la console web.
  • Le paquet cockpit-pcp, qui permet de collecter les mesures de performance, est installé :

    1. Pour installer le paquet à partir de l'interface de la console web :

      1. Connectez-vous à la console web avec des privilèges administratifs. Pour plus d'informations, voir Connexion à la console web.
      2. Dans la page Overview, cliquez sur View details and history.
      3. Cliquez sur le bouton Installer cockpit-pcp.
      4. Dans la fenêtre de dialogue Install software, cliquez sur Install.
    2. Pour installer le paquet à partir de l'interface de ligne de commande, utilisez :

      # dnf install cockpit-pcp
  • Le service PCP est activé :

    # systemctl enable --now pmlogger.service pmproxy.service

Procédure

  1. Connectez-vous à la console web RHEL 9. Dans la page Overview, cliquez sur View details and history pour afficher Performance Metrics.

    Voir les détails et l'historique

    Mesures de performance dans la console Web

10.4. Surveillance des performances sur plusieurs systèmes à l'aide de la console web et de Grafana

Grafana vous permet de collecter des données à partir de plusieurs systèmes à la fois et d'examiner une représentation graphique de leurs métriques PCP collectées. Vous pouvez configurer la surveillance et l'exportation des mesures de performance pour plusieurs systèmes dans l'interface de la console web.

Cette procédure vous montre comment activer l'exportation des mesures de performance avec PCP à partir de l'interface de la console Web de RHEL 9.

Conditions préalables

  • La console web doit être installée et accessible. Pour plus de détails, voir Installation de la console web.
  • Installez le paquetage cockpit-pcp.

    1. Depuis l'interface de la console web :

      1. Connectez-vous à la console web avec des privilèges administratifs. Pour plus d'informations, voir Connexion à la console web.
      2. Dans la page Overview, cliquez sur View details and history.
      3. Cliquez sur le bouton Installer cockpit-pcp.
      4. Dans la fenêtre de dialogue Install software, cliquez sur Install.
      5. Déconnectez-vous et reconnectez-vous pour voir l'historique des mesures.
    2. Pour installer le paquet à partir de l'interface de ligne de commande, utilisez :

      # dnf install cockpit-pcp
  • Activer le service PCP :

    # systemctl enable --now pmlogger.service pmproxy.service
  • Configurez le tableau de bord Grafana. Pour plus d'informations, voir Configurer un serveur Grafana.
  • Installez le paquetage redis.

    # dnf install redis

    Vous pouvez également installer le paquet à partir de l'interface de la console web plus tard dans la procédure.

Procédure

  1. Dans la page Overview, cliquez sur View details and history dans le tableau Usage.
  2. Cliquez sur le bouton Paramètres de mesure.
  3. Placez le curseur Export to network en position active.

    exportation du cockpit vers le curseur de réseau

    Si le service redis n'est pas installé, vous serez invité à l'installer.

  4. Pour ouvrir le service pmproxy, sélectionnez une zone dans une liste déroulante et cliquez sur le bouton Add pmproxy.
  5. Cliquez sur Save.

Vérification

  1. Cliquez sur Networking.
  2. Dans le tableau Firewall, cliquez sur n active zones ou sur le bouton Modifier les règles et les zones.
  3. Recherchez pmproxy dans la zone que vous avez sélectionnée.
Important

Répétez cette procédure sur tous les systèmes que vous souhaitez surveiller.

Chapitre 11. Paramétrage du planificateur de disque

L'ordonnanceur de disque est chargé d'ordonner les demandes d'E/S soumises à un périphérique de stockage.

Vous pouvez configurer le planificateur de différentes manières :

Note

Dans Red Hat Enterprise Linux 9, les périphériques de blocs ne prennent en charge que l'ordonnancement à plusieurs files d'attente. Cela permet aux performances de la couche de blocs de bien s'adapter aux disques durs rapides (SSD) et aux systèmes multicœurs.

Les ordonnanceurs traditionnels à file d'attente unique, qui étaient disponibles dans Red Hat Enterprise Linux 7 et les versions antérieures, ont été supprimés.

11.1. Planificateurs de disques disponibles

Les ordonnanceurs de disques à plusieurs files d'attente suivants sont pris en charge dans Red Hat Enterprise Linux 9 :

none
Met en œuvre un algorithme d'ordonnancement FIFO (premier entré, premier sorti). Il fusionne les demandes au niveau du bloc générique par le biais d'un simple cache de dernier arrivé.
mq-deadline

Tente de fournir une latence garantie pour les demandes à partir du moment où les demandes atteignent l'ordonnanceur.

L'ordonnanceur mq-deadline classe les demandes d'E/S en file d'attente dans un lot de lecture ou d'écriture, puis planifie leur exécution dans l'ordre croissant de l'adressage logique des blocs (LBA). Par défaut, les lots de lecture sont prioritaires sur les lots d'écriture, car les applications sont plus susceptibles de se bloquer sur les opérations d'E/S de lecture. Après que mq-deadline a traité un lot, il vérifie pendant combien de temps les opérations d'écriture ont été privées de temps processeur et planifie le lot de lecture ou d'écriture suivant, selon le cas.

Cet ordonnanceur convient à la plupart des cas d'utilisation, mais surtout à ceux dans lesquels les opérations d'écriture sont principalement asynchrones.

bfq

Cible les systèmes de bureau et les tâches interactives.

Le planificateur bfq garantit qu'une seule application n'utilise jamais la totalité de la bande passante. En effet, l'unité de stockage est toujours aussi réactive que si elle était inactive. Dans sa configuration par défaut, bfq s'efforce de fournir la latence la plus faible possible plutôt que d'atteindre un débit maximal.

bfq est basé sur le code cfq. Il n'accorde pas le disque à chaque processus pour une tranche de temps fixe, mais attribue au processus une adresse budget mesurée en nombre de secteurs.

Ce planificateur convient à la copie de fichiers volumineux et le système ne devient pas insensible dans ce cas.

kyber

L'ordonnanceur s'adapte pour atteindre un objectif de latence en calculant les latences de chaque demande d'E/S soumise à la couche d'E/S par bloc. Vous pouvez configurer les temps de latence cibles pour les demandes de lecture, en cas d'oubli de cache, et d'écriture synchrone.

Cet ordonnanceur est adapté aux périphériques rapides, par exemple NVMe, SSD, ou d'autres périphériques à faible latence.

11.2. Différents ordonnanceurs de disques pour différents cas d'utilisation

En fonction des tâches effectuées par votre système, les ordonnanceurs de disques suivants sont recommandés comme base de référence avant toute analyse et tout réglage :

Tableau 11.1. Ordonnanceurs de disques pour différents cas d'utilisation
Use casePlanificateur de disque

Disque dur traditionnel avec interface SCSI

Utilisez mq-deadline ou bfq.

SSD haute performance ou système lié à l'unité centrale avec stockage rapide

Utilisez none, surtout si vous utilisez des applications d'entreprise. Vous pouvez également utiliser kyber.

Tâches de bureau ou interactives

Utiliser bfq.

Invité virtuel

Utilisez mq-deadline. Avec un pilote d'adaptateur de bus hôte (HBA) capable de gérer plusieurs files d'attente, utilisez none.

11.3. Le planificateur de disque par défaut

Les périphériques en mode bloc utilisent le planificateur de disque par défaut, à moins que vous n'en spécifiiez un autre.

Note

Pour les périphériques de bloc non-volatile Memory Express (NVMe) en particulier, l'ordonnanceur par défaut est none et Red Hat recommande de ne pas le modifier.

Le noyau sélectionne un planificateur de disque par défaut en fonction du type de périphérique. Le planificateur sélectionné automatiquement est généralement le paramètre optimal. Si vous avez besoin d'un planificateur différent, Red Hat vous recommande d'utiliser les règles udev ou l'application TuneD pour le configurer. Faites correspondre les périphériques sélectionnés et changez l'ordonnanceur uniquement pour ces périphériques.

11.4. Détermination de l'ordonnanceur de disque actif

Cette procédure permet de déterminer quel planificateur de disque est actuellement actif sur une unité de bloc donnée.

Procédure

  • Lire le contenu du /sys/block/device/queue/scheduler fichier :

    # cat /sys/block/device/queue/scheduler
    
    [mq-deadline] kyber bfq none

    Dans le nom du fichier, remplacez device par le nom du bloc, par exemple sdc.

    Le planificateur actif est indiqué entre crochets ([ ]).

11.5. Paramétrage du planificateur de disque à l'aide de TuneD

Cette procédure permet de créer et d'activer un profil TuneD qui définit un planificateur de disque donné pour les périphériques de bloc sélectionnés. Le paramètre persiste lors des redémarrages du système.

Dans les commandes et la configuration suivantes, remplacer :

  • device avec le nom du dispositif de blocage, par exemple sdf
  • selected-scheduler avec le planificateur de disque que vous souhaitez définir pour le périphérique, par exemple bfq

Conditions préalables

Procédure

  1. Facultatif : Sélectionnez un profil TuneD existant sur lequel votre profil sera basé. Pour obtenir une liste des profils disponibles, voir les profils TuneD distribués avec RHEL.

    Pour savoir quel profil est actuellement actif, utilisez :

    $ tuned-adm active
  2. Créez un nouveau répertoire qui contiendra votre profil TuneD:

    # mkdir /etc/tuned/my-profile
  3. Recherchez l'identifiant unique du système du bloc sélectionné :

    $ udevadm info --query=property --name=/dev/device | grep -E '(WWN|SERIAL)'
    
    ID_WWN=0x5002538d00000000_
    ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0
    ID_SERIAL_SHORT=20120501030900000
    Note

    La commande de cet exemple renverra toutes les valeurs identifiées par un World Wide Name (WWN) ou un numéro de série associé au dispositif de bloc spécifié. Bien qu'il soit préférable d'utiliser un WWN, celui-ci n'est pas toujours disponible pour un dispositif donné et toutes les valeurs renvoyées par la commande de l'exemple peuvent être utilisées comme device system unique ID.

  4. Créer le fichier de /etc/tuned/my-profile/tuned.conf fichier de configuration. Dans le fichier, définissez les options suivantes :

    1. Facultatif : Inclure un profil existant :

      [main]
      include=existing-profile
    2. Définir le planificateur de disque sélectionné pour le périphérique qui correspond à l'identifiant WWN :

      [disk]
      devices_udev_regex=IDNAME=device system unique id
      elevator=selected-scheduler

      Ici :

      • Remplacer IDNAME par le nom de l'identifiant utilisé (par exemple, ID_WWN).
      • Remplacer device system unique id par la valeur de l'identifiant choisi (par exemple, 0x5002538d00000000).

        Pour faire correspondre plusieurs appareils dans l'option devices_udev_regex, mettez les identifiants entre parenthèses et séparez-les par des barres verticales :

        devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
  5. Activez votre profil :

    # tuned-adm profile my-profile

Verification steps

  1. Vérifiez que le profil TuneD est actif et appliqué :

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See TuneD log file ('/var/log/tuned/tuned.log') for details.
  2. Lire le contenu du /sys/block/device/queue/scheduler fichier :

    # cat /sys/block/device/queue/scheduler
    
    [mq-deadline] kyber bfq none

    Dans le nom du fichier, remplacez device par le nom du bloc, par exemple sdc.

    Le planificateur actif est indiqué entre crochets ([]).

Ressources supplémentaires

11.6. Définition de l'ordonnanceur de disque à l'aide des règles udev

Cette procédure permet de définir un planificateur de disque donné pour des périphériques de bloc spécifiques à l'aide des règles udev. Le paramètre persiste lors des redémarrages du système.

Dans les commandes et la configuration suivantes, remplacer :

  • device avec le nom du dispositif de blocage, par exemple sdf
  • selected-scheduler avec le planificateur de disque que vous souhaitez définir pour le périphérique, par exemple bfq

Procédure

  1. Recherchez l'identifiant unique du système du dispositif de blocage :

    $ udevadm info --name=/dev/device | grep -E '(WWN|SERIAL)'
    E: ID_WWN=0x5002538d00000000
    E: ID_SERIAL=Generic-_SD_MMC_20120501030900000-0:0
    E: ID_SERIAL_SHORT=20120501030900000
    Note

    La commande de cet exemple renverra toutes les valeurs identifiées par un World Wide Name (WWN) ou un numéro de série associé au dispositif de bloc spécifié. Bien qu'il soit préférable d'utiliser un WWN, celui-ci n'est pas toujours disponible pour un dispositif donné et toutes les valeurs renvoyées par la commande de l'exemple peuvent être utilisées comme device system unique ID.

  2. Configurez la règle udev. Créez le fichier /etc/udev/rules.d/99-scheduler.rules avec le contenu suivant :

    ACTION=="ajouter/modifier", SUBSYSTEM=="bloquer", ENV{IDNAME}=="device system unique id", ATTR{queue/scheduler}="selected-scheduler"

    Ici :

    • Remplacer IDNAME par le nom de l'identifiant utilisé (par exemple, ID_WWN).
    • Remplacer device system unique id par la valeur de l'identifiant choisi (par exemple, 0x5002538d00000000).
  3. Recharger udev règles :

    # udevadm control --reload-rules
  4. Appliquer la configuration de l'ordonnanceur :

    # udevadm trigger --type=devices --action=change

Verification steps

  • Vérifier l'ordonnanceur actif :

    # cat /sys/block/device/queue/scheduler

11.7. Définition temporaire d'un planificateur pour un disque spécifique

Cette procédure permet de définir un planificateur de disque donné pour des périphériques de bloc spécifiques. Le paramètre ne persiste pas lors des redémarrages du système.

Procédure

  • Inscrivez le nom de l'ordonnanceur sélectionné dans le fichier /sys/block/device/queue/scheduler dans le fichier

    # echo selected-scheduler > /sys/block/device/queue/scheduler

    Dans le nom du fichier, remplacez device par le nom du bloc, par exemple sdc.

Verification steps

  • Vérifiez que l'ordonnanceur est actif sur l'appareil :

    # cat /sys/block/device/queue/scheduler

Chapitre 12. Optimiser les performances d'un serveur Samba

Découvrez quels paramètres peuvent améliorer les performances de Samba dans certaines situations, et quels paramètres peuvent avoir un impact négatif sur les performances.

Certaines parties de cette section ont été adoptées à partir de la documentation Performance Tuning publiée dans le Samba Wiki. Licence : CC BY 4.0. Auteurs et contributeurs : Voir l'onglet historique de la page Wiki.

Conditions préalables

  • Samba est configuré comme un serveur de fichiers ou d'impression

12.1. Réglage de la version du protocole SMB

Chaque nouvelle version de SMB ajoute des fonctionnalités et améliore les performances du protocole. Les systèmes d'exploitation récents Windows et Windows Server prennent toujours en charge la dernière version du protocole. Si Samba utilise également la dernière version du protocole, les clients Windows qui se connectent à Samba bénéficient des améliorations de performance. Dans Samba, la valeur par défaut du protocole max du serveur est définie sur la dernière version stable du protocole SMB prise en charge.

Note

Pour que la dernière version stable du protocole SMB soit toujours activée, ne définissez pas le paramètre server max protocol. Si vous définissez ce paramètre manuellement, vous devrez le modifier à chaque nouvelle version du protocole SMB pour que la dernière version du protocole soit activée.

La procédure suivante explique comment utiliser la valeur par défaut du paramètre server max protocol.

Procédure

  1. Supprimer le paramètre server max protocol de la section [global] du fichier /etc/samba/smb.conf.
  2. Recharger la configuration de Samba

    # smbcontrol all reload-config

12.2. Optimisation des partages avec des répertoires contenant un grand nombre de fichiers

Linux prend en charge les noms de fichiers sensibles à la casse. C'est pourquoi Samba doit rechercher les noms de fichiers en majuscules et en minuscules dans les répertoires lors de la recherche ou de l'accès à un fichier. Vous pouvez configurer un partage pour qu'il crée de nouveaux fichiers uniquement en minuscules ou en majuscules, ce qui améliore les performances.

Conditions préalables

  • Samba est configuré comme serveur de fichiers

Procédure

  1. Renommer tous les fichiers du partage en minuscules.

    Note

    En utilisant les réglages de cette procédure, les fichiers dont les noms ne sont pas en minuscules ne seront plus affichés.

  2. Définissez les paramètres suivants dans la section du partage :

    case sensitive = true
    default case = lower
    preserve case = no
    short preserve case = no

    Pour plus de détails sur les paramètres, voir leur description dans la page de manuel smb.conf(5).

  3. Vérifiez le fichier /etc/samba/smb.conf:

    # testparm
  4. Recharger la configuration de Samba :

    # smbcontrol all reload-config

Après avoir appliqué ces paramètres, les noms de tous les fichiers nouvellement créés sur ce partage utilisent des minuscules. Grâce à ces paramètres, Samba n'a plus besoin de rechercher les majuscules et les minuscules dans le répertoire, ce qui améliore les performances.

12.3. Paramètres pouvant avoir un impact négatif sur les performances

Par défaut, le noyau de Red Hat Enterprise Linux est réglé pour des performances réseau élevées. Par exemple, le noyau utilise un mécanisme de réglage automatique pour la taille des tampons. La définition du paramètre socket options dans le fichier /etc/samba/smb.conf remplace ces paramètres du noyau. Par conséquent, la définition de ce paramètre diminue les performances du réseau Samba dans la plupart des cas.

Pour utiliser les paramètres optimisés du noyau, supprimez le paramètre socket options de la section [global] du site /etc/samba/smb.conf.

Chapitre 13. Optimizing virtual machine performance

Virtual machines (VMs) always experience some degree of performance deterioration in comparison to the host. The following sections explain the reasons for this deterioration and provide instructions on how to minimize the performance impact of virtualization in RHEL 9, so that your hardware infrastructure resources can be used as efficiently as possible.

13.1. What influences virtual machine performance

VMs are run as user-space processes on the host. The hypervisor therefore needs to convert the host’s system resources so that the VMs can use them. As a consequence, a portion of the resources is consumed by the conversion, and the VM therefore cannot achieve the same performance efficiency as the host.

The impact of virtualization on system performance

More specific reasons for VM performance loss include:

  • Virtual CPUs (vCPUs) are implemented as threads on the host, handled by the Linux scheduler.
  • VMs do not automatically inherit optimization features, such as NUMA or huge pages, from the host kernel.
  • Disk and network I/O settings of the host might have a significant performance impact on the VM.
  • Network traffic typically travels to a VM through a software-based bridge.
  • Depending on the host devices and their models, there might be significant overhead due to emulation of particular hardware.

The severity of the virtualization impact on the VM performance is influenced by a variety factors, which include:

  • The number of concurrently running VMs.
  • The amount of virtual devices used by each VM.
  • The device types used by the VMs.
Reducing VM performance loss

RHEL 9 provides a number of features you can use to reduce the negative performance effects of virtualization. Notably:

Important

Tuning VM performance can have adverse effects on other virtualization functions. For example, it can make migrating the modified VM more difficult.

13.2. Optimizing virtual machine performance using TuneD

The TuneD utility is a tuning profile delivery mechanism that adapts RHEL for certain workload characteristics, such as requirements for CPU-intensive tasks or storage-network throughput responsiveness. It provides a number of tuning profiles that are pre-configured to enhance performance and reduce power consumption in a number of specific use cases. You can edit these profiles or create new profiles to create performance solutions tailored to your environment, including virtualized environments.

To optimize RHEL 9 for virtualization, use the following profiles:

  • For RHEL 9 virtual machines, use the virtual-guest profile. It is based on the generally applicable throughput-performance profile, but also decreases the swappiness of virtual memory.
  • For RHEL 9 virtualization hosts, use the virtual-host profile. This enables more aggressive writeback of dirty memory pages, which benefits the host performance.

Conditions préalables

Procédure

To enable a specific TuneD profile:

  1. List the available TuneD profiles.

    # tuned-adm list
    
    Available profiles:
    - balanced             - General non-specialized TuneD profile
    - desktop              - Optimize for the desktop use-case
    [...]
    - virtual-guest        - Optimize for running inside a virtual guest
    - virtual-host         - Optimize for running KVM guests
    Current active profile: balanced
  2. Optional: Create a new TuneD profile or edit an existing TuneD profile.

    For more information, see Customizing TuneD profiles.

  3. Activate a TuneD profile.

    # tuned-adm profile selected-profile
    • To optimize a virtualization host, use the virtual-host profile.

      # tuned-adm profile virtual-host
    • On a RHEL guest operating system, use the virtual-guest profile.

      # tuned-adm profile virtual-guest

13.3. Optimizing libvirt daemons

The libvirt virtualization suite works as a management layer for the RHEL hypervisor, and your libvirt configuration significantly impacts your virtualization host. Notably, RHEL 9 contains two different types of libvirt daemons, monolithic or modular, and which type of daemons you use affects how granularly you can configure individual virtualization drivers.

13.3.1. Types of libvirt daemons

RHEL 9 supports the following libvirt daemon types:

Monolithic libvirt

The traditional libvirt daemon, libvirtd, controls a wide variety of virtualization drivers, using a single configuration file - /etc/libvirt/libvirtd.conf.

As such, libvirtd allows for centralized hypervisor configuration, but may use system resources inefficiently. Therefore, libvirtd will become unsupported in a future major release of RHEL.

However, if you updated to RHEL 9 from RHEL 8, your host still uses libvirtd by default.

Modular libvirt

Newly introduced in RHEL 9, modular libvirt provides a specific daemon for each virtualization driver. These include the following:

  • virtqemud - A primary daemon for hypervisor management
  • virtinterfaced - A secondary daemon for host NIC management
  • virtnetworkd - A secondary daemon for virtual network management
  • virtnodedevd - A secondary daemon for host physical device management
  • virtnwfilterd - A secondary daemon for host firewall management
  • virtsecretd - A secondary daemon for host secret management
  • virtstoraged - A secondary daemon for storage management

Each of the daemons has a separate configuration file - for example /etc/libvirt/virtqemud.conf. As such, modular libvirt daemons provide better options for fine-tuning libvirt resource management.

If you performed a fresh install of RHEL 9, modular libvirt is configured by default.

Prochaines étapes

13.3.2. Enabling modular libvirt daemons

In RHEL 9, the libvirt library uses modular daemons that handle individual virtualization driver sets on your host. For example, the virtqemud daemon handles QEMU drivers.

If you performed a fresh install of a RHEL 9 host, your hypervisor uses modular libvirt daemons by default. However, if you upgraded your host from RHEL 8 to RHEL 9, your hypervisor uses the monolithic libvirtd daemon, which is the default in RHEL 8.

If that is the case, Red Hat recommends enabling the modular libvirt daemons instead, because they provide better options for fine-tuning libvirt resource management. In addition, libvirtd will become unsupported in a future major release of RHEL.

Conditions préalables

  • Your hypervisor is using the monolithic libvirtd service.

    # systemctl is-active libvirtd.service
    active

    If this command displays active, you are using libvirtd.

  • Your virtual machines are shut down.

Procédure

  1. Stop libvirtd and its sockets.

    # systemctl stop libvirtd.service
    # systemctl stop libvirtd{,-ro,-admin,-tcp,-tls}.socket
  2. Disable libvirtd to prevent it from starting on boot.

    $ systemctl disable libvirtd.service
    $ systemctl disable libvirtd{,-ro,-admin,-tcp,-tls}.socket
  3. Enable the modular libvirt daemons.

    # for drv in qemu interface network nodedev nwfilter secret storage; do systemctl unmask virt${drv}d.service; systemctl unmask virt${drv}d{,-ro,-admin}.socket; systemctl enable virt${drv}d.service; systemctl enable virt${drv}d{,-ro,-admin}.socket; done
  4. Start the sockets for the modular daemons.

    # for drv in qemu network nodedev nwfilter secret storage; do systemctl start virt${drv}d{,-ro,-admin}.socket; done
  5. Optional: If you require connecting to your host from remote hosts, enable and start the virtualization proxy daemon.

    1. Check whether the libvirtd-tls.socket service is enabled on your system.

      # cat /etc/libvirt/libvirt.conf | grep listen_tls
      
      listen_tls = 0
    2. If libvirtd-tls.socket is not enabled (listen_tls = 0), activate virtproxyd as follows:

      # systemctl unmask virtproxyd.service
      # systemctl unmask virtproxyd{,-ro,-admin}.socket
      # systemctl enable virtproxyd.service
      # systemctl enable virtproxyd{,-ro,-admin}.socket
      # systemctl start virtproxyd{,-ro,-admin}.socket
    3. If libvirtd-tls.socket is enabled (listen_tls = 1), activate virtproxyd as follows:

      # systemctl unmask virtproxyd.service
      # systemctl unmask virtproxyd{,-ro,-admin,-tls}.socket
      # systemctl enable virtproxyd.service
      # systemctl enable virtproxyd{,-ro,-admin,-tls}.socket
      # systemctl start virtproxyd{,-ro,-admin,-tls}.socket

      To enable the TLS socket of virtproxyd, your host must have TLS certificates configured to work with libvirt. For more information, see the Upstream libvirt documentation.

Vérification

  1. Activate the enabled virtualization daemons.

    # virsh uri
    qemu:///system
  2. Verify that your host is using the virtqemud modular daemon.

    # systemctl is-active virtqemud.service
    active

    If the status is active, you have successfully enabled modular libvirt daemons.

13.4. Configuring virtual machine memory

To improve the performance of a virtual machine (VM), you can assign additional host RAM to the VM. Similarly, you can decrease the amount of memory allocated to a VM so the host memory can be allocated to other VMs or tasks.

To perform these actions, you can use the web console or the command-line interface.

13.4.1. Adding and removing virtual machine memory using the web console

To improve the performance of a virtual machine (VM) or to free up the host resources it is using, you can use the web console to adjust amount of memory allocated to the VM.

Conditions préalables

  • The guest OS is running the memory balloon drivers. To verify this is the case:

    1. Ensure the VM’s configuration includes the memballoon device:

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      If this commands displays any output and the model is not set to none, the memballoon device is present.

    2. Ensure the balloon drivers are running in the guest OS.

  • Le plug-in VM de la console web est installé sur votre système.

Procédure

  1. Optional: Obtain the information about the maximum memory and currently used memory for a VM. This will serve as a baseline for your changes, and also for verification.

    # virsh dominfo testguest
    Max memory:     2097152 KiB
    Used memory:    2097152 KiB
  2. In the Virtual Machines interface, click the VM whose information you want to see.

    A new page opens with an Overview section with basic information about the selected VM and a Console section to access the VM’s graphical interface.

  3. Click edit next to the Memory line in the Overview pane.

    The Memory Adjustment dialog appears.

    Image displaying the VM memory adjustment dialog box.
  4. Configure the virtual CPUs for the selected VM.

    • Maximum allocation - Sets the maximum amount of host memory that the VM can use for its processes. You can specify the maximum memory when creating the VM or increase it later. You can specify memory as multiples of MiB or GiB.

      Adjusting maximum memory allocation is only possible on a shut-off VM.

    • Current allocation - Sets the actual amount of memory allocated to the VM. This value can be less than the Maximum allocation but cannot exceed it. You can adjust the value to regulate the memory available to the VM for its processes. You can specify memory as multiples of MiB or GiB.

      If you do not specify this value, the default allocation is the Maximum allocation value.

  5. Cliquez sur Enregistrer.

    The memory allocation of the VM is adjusted.

13.4.2. Adding and removing virtual machine memory using the command-line interface

To improve the performance of a virtual machine (VM) or to free up the host resources it is using, you can use the CLI to adjust amount of memory allocated to the VM.

Conditions préalables

  • The guest OS is running the memory balloon drivers. To verify this is the case:

    1. Ensure the VM’s configuration includes the memballoon device:

      # virsh dumpxml testguest | grep memballoon
      <memballoon model='virtio'>
          </memballoon>

      If this commands displays any output and the model is not set to none, the memballoon device is present.

    2. Ensure the ballon drivers are running in the guest OS.

Procédure

  1. Optional: Obtain the information about the maximum memory and currently used memory for a VM. This will serve as a baseline for your changes, and also for verification.

    # virsh dominfo testguest
    Max memory:     2097152 KiB
    Used memory:    2097152 KiB
  2. Adjust the maximum memory allocated to a VM. Increasing this value improves the performance potential of the VM, and reducing the value lowers the performance footprint the VM has on your host. Note that this change can only be performed on a shut-off VM, so adjusting a running VM requires a reboot to take effect.

    For example, to change the maximum memory that the testguest VM can use to 4096 MiB:

    # virt-xml testguest --edit --memory memory=4096,currentMemory=4096
    Domain 'testguest' defined successfully.
    Changes will take effect after the domain is fully powered off.

    Pour augmenter la mémoire maximale d'une VM en cours d'exécution, vous pouvez attacher un périphérique de mémoire à la VM. Cette opération est également appelée memory hot plug. Pour plus d'informations, voir Attacher des périphériques aux machines virtuelles.

    Avertissement

    Removing memory devices from a running VM (also referred as a memory hot unplug) is not supported, and highly discouraged by Red Hat.

  3. Optional: You can also adjust the memory currently used by the VM, up to the maximum allocation. This regulates the memory load that the VM has on the host until the next reboot, without changing the maximum VM allocation.

    # virsh setmem testguest --current 2048

Vérification

  1. Confirm that the memory used by the VM has been updated:

    # virsh dominfo testguest
    Max memory:     4194304 KiB
    Used memory:    2097152 KiB
  2. Optional: If you adjusted the current VM memory, you can obtain the memory balloon statistics of the VM to evaluate how effectively it regulates its memory use.

     # virsh domstats --balloon testguest
    Domain: 'testguest'
      balloon.current=365624
      balloon.maximum=4194304
      balloon.swap_in=0
      balloon.swap_out=0
      balloon.major_fault=306
      balloon.minor_fault=156117
      balloon.unused=3834448
      balloon.available=4035008
      balloon.usable=3746340
      balloon.last-update=1587971682
      balloon.disk_caches=75444
      balloon.hugetlb_pgalloc=0
      balloon.hugetlb_pgfail=0
      balloon.rss=1005456

13.4.3. Ressources supplémentaires

13.5. Optimizing virtual machine I/O performance

The input and output (I/O) capabilities of a virtual machine (VM) can significantly limit the VM’s overall efficiency. To address this, you can optimize a VM’s I/O by configuring block I/O parameters.

13.5.1. Tuning block I/O in virtual machines

When multiple block devices are being used by one or more VMs, it might be important to adjust the I/O priority of specific virtual devices by modifying their I/O weights.

Increasing the I/O weight of a device increases its priority for I/O bandwidth, and therefore provides it with more host resources. Similarly, reducing a device’s weight makes it consume less host resources.

Note

Each device’s weight value must be within the 100 to 1000 range. Alternatively, the value can be 0, which removes that device from per-device listings.

Procédure

To display and set a VM’s block I/O parameters:

  1. Display the current <blkio> parameters for a VM:

    # virsh dumpxml VM-name

    <domain>
      [...]
      <blkiotune>
        <weight>800</weight>
        <device>
          <path>/dev/sda</path>
          <weight>1000</weight>
        </device>
        <device>
          <path>/dev/sdb</path>
          <weight>500</weight>
        </device>
      </blkiotune>
      [...]
    </domain>
  2. Edit the I/O weight of a specified device:

    # virsh blkiotune VM-name --device-weights device, I/O-weight

    For example, the following changes the weight of the /dev/sda device in the liftrul VM to 500.

    # virsh blkiotune liftbrul --device-weights /dev/sda, 500

13.5.2. Disk I/O throttling in virtual machines

When several VMs are running simultaneously, they can interfere with system performance by using excessive disk I/O. Disk I/O throttling in KVM virtualization provides the ability to set a limit on disk I/O requests sent from the VMs to the host machine. This can prevent a VM from over-utilizing shared resources and impacting the performance of other VMs.

To enable disk I/O throttling, set a limit on disk I/O requests sent from each block device attached to VMs to the host machine.

Procédure

  1. Use the virsh domblklist command to list the names of all the disk devices on a specified VM.

    # virsh domblklist rollin-coal
    Target     Source
    ------------------------------------------------
    vda        /var/lib/libvirt/images/rollin-coal.qcow2
    sda        -
    sdb        /home/horridly-demanding-processes.iso
  2. Find the host block device where the virtual disk that you want to throttle is mounted.

    For example, if you want to throttle the sdb virtual disk from the previous step, the following output shows that the disk is mounted on the /dev/nvme0n1p3 partition.

    $ lsblk
    NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
    zram0                                         252:0    0     4G  0 disk  [SWAP]
    nvme0n1                                       259:0    0 238.5G  0 disk
    ├─nvme0n1p1                                   259:1    0   600M  0 part  /boot/efi
    ├─nvme0n1p2                                   259:2    0     1G  0 part  /boot
    └─nvme0n1p3                                   259:3    0 236.9G  0 part
      └─luks-a1123911-6f37-463c-b4eb-fxzy1ac12fea 253:0    0 236.9G  0 crypt /home
  3. Set I/O limits for the block device using the virsh blkiotune command.

    # virsh blkiotune VM-name --parameter device,limit

    The following example throttles the sdb disk on the rollin-coal VM to 1000 read and write I/O operations per second and to 50 MB per second read and write throughput.

    # virsh blkiotune rollin-coal --device-read-iops-sec /dev/nvme0n1p3,1000 --device-write-iops-sec /dev/nvme0n1p3,1000 --device-write-bytes-sec /dev/nvme0n1p3,52428800 --device-read-bytes-sec /dev/nvme0n1p3,52428800

Informations complémentaires

  • Disk I/O throttling can be useful in various situations, for example when VMs belonging to different customers are running on the same host, or when quality of service guarantees are given for different VMs. Disk I/O throttling can also be used to simulate slower disks.
  • I/O throttling can be applied independently to each block device attached to a VM and supports limits on throughput and I/O operations.
  • Red Hat ne prend pas en charge l'utilisation de la commande virsh blkdeviotune pour configurer la limitation des E/S dans les machines virtuelles. Pour plus d'informations sur les fonctionnalités non prises en charge lors de l'utilisation de RHEL 9 en tant qu'hôte de VM, voir Fonctionnalités non prises en charge dans la virtualisation RHEL 9.

13.5.3. Enabling multi-queue virtio-scsi

When using virtio-scsi storage devices in your virtual machines (VMs), the multi-queue virtio-scsi feature provides improved storage performance and scalability. It enables each virtual CPU (vCPU) to have a separate queue and interrupt to use without affecting other vCPUs.

Procédure

  • To enable multi-queue virtio-scsi support for a specific VM, add the following to the VM’s XML configuration, where N is the total number of vCPU queues:

    <controller type='scsi' index='0' model='virtio-scsi'>
       <driver queues='N' />
    </controller>

13.6. Optimizing virtual machine CPU performance

Much like physical CPUs in host machines, vCPUs are critical to virtual machine (VM) performance. As a result, optimizing vCPUs can have a significant impact on the resource efficiency of your VMs. To optimize your vCPU:

  1. Adjust how many host CPUs are assigned to the VM. You can do this using the CLI or the web console.
  2. Ensure that the vCPU model is aligned with the CPU model of the host. For example, to set the testguest1 VM to use the CPU model of the host:

    # virt-xml testguest1 --edit --cpu host-model
  3. Manage kernel same-page merging (KSM).
  4. If your host machine uses Non-Uniform Memory Access (NUMA), you can also configure NUMA for its VMs. This maps the host’s CPU and memory processes onto the CPU and memory processes of the VM as closely as possible. In effect, NUMA tuning provides the vCPU with a more streamlined access to the system memory allocated to the VM, which can improve the vCPU processing effectiveness.

    For details, see Configuring NUMA in a virtual machine and Sample vCPU performance tuning scenario.

13.6.1. Adding and removing virtual CPUs using the command-line interface

To increase or optimize the CPU performance of a virtual machine (VM), you can add or remove virtual CPUs (vCPUs) assigned to the VM.

When performed on a running VM, this is also referred to as vCPU hot plugging and hot unplugging. However, note that vCPU hot unplug is not supported in RHEL 9, and Red Hat highly discourages its use.

Conditions préalables

  • Optional: View the current state of the vCPUs in the targeted VM. For example, to display the number of vCPUs on the testguest VM:

    # virsh vcpucount testguest
    maximum      config         4
    maximum      live           2
    current      config         2
    current      live           1

    This output indicates that testguest is currently using 1 vCPU, and 1 more vCPu can be hot plugged to it to increase the VM’s performance. However, after reboot, the number of vCPUs testguest uses will change to 2, and it will be possible to hot plug 2 more vCPUs.

Procédure

  1. Adjust the maximum number of vCPUs that can be attached to a VM, which takes effect on the VM’s next boot.

    For example, to increase the maximum vCPU count for the testguest VM to 8:

    # virsh setvcpus testguest 8 --maximum --config

    Note that the maximum may be limited by the CPU topology, host hardware, the hypervisor, and other factors.

  2. Adjust the current number of vCPUs attached to a VM, up to the maximum configured in the previous step. For example:

    • To increase the number of vCPUs attached to the running testguest VM to 4:

      # virsh setvcpus testguest 4 --live

      This increases the VM’s performance and host load footprint of testguest until the VM’s next boot.

    • To permanently decrease the number of vCPUs attached to the testguest VM to 1:

      # virsh setvcpus testguest 1 --config

      This decreases the VM’s performance and host load footprint of testguest after the VM’s next boot. However, if needed, additional vCPUs can be hot plugged to the VM to temporarily increase its performance.

Vérification

  • Confirm that the current state of vCPU for the VM reflects your changes.

    # virsh vcpucount testguest
    maximum      config         8
    maximum      live           4
    current      config         1
    current      live           4

13.6.2. Managing virtual CPUs using the web console

Using the RHEL 9 web console, you can review and configure virtual CPUs used by virtual machines (VMs) to which the web console is connected.

Conditions préalables

Procédure

  1. In the Virtual Machines interface, click the VM whose information you want to see.

    A new page opens with an Overview section with basic information about the selected VM and a Console section to access the VM’s graphical interface.

  2. Click edit next to the number of vCPUs in the Overview pane.

    The vCPU details dialog appears.

    Image displaying the VM CPU details dialog box.
  1. Configure the virtual CPUs for the selected VM.

    • vCPU Count - The number of vCPUs currently in use.

      Note

      The vCPU count cannot be greater than the vCPU Maximum.

    • vCPU Maximum - The maximum number of virtual CPUs that can be configured for the VM. If this value is higher than the vCPU Count, additional vCPUs can be attached to the VM.
    • Sockets - The number of sockets to expose to the VM.
    • Cores per socket - The number of cores for each socket to expose to the VM.
    • Threads per core - The number of threads for each core to expose to the VM.

      Note that the Sockets, Cores per socket, and Threads per core options adjust the CPU topology of the VM. This may be beneficial for vCPU performance and may impact the functionality of certain software in the guest OS. If a different setting is not required by your deployment, keep the default values.

  2. Cliquez sur Appliquer.

    The virtual CPUs for the VM are configured.

    Note

    Changes to virtual CPU settings only take effect after the VM is restarted.

13.6.3. Configuring NUMA in a virtual machine

The following methods can be used to configure Non-Uniform Memory Access (NUMA) settings of a virtual machine (VM) on a RHEL 9 host.

Conditions préalables

  • The host is a NUMA-compatible machine. To detect whether this is the case, use the virsh nodeinfo command and see the NUMA cell(s) line:

    # virsh nodeinfo
    CPU model:           x86_64
    CPU(s):              48
    CPU frequency:       1200 MHz
    CPU socket(s):       1
    Core(s) per socket:  12
    Thread(s) per core:  2
    NUMA cell(s):        2
    Memory size:         67012964 KiB

    If the value of the line is 2 or greater, the host is NUMA-compatible.

Procédure

For ease of use, you can set up a VM’s NUMA configuration using automated utilities and services. However, manual NUMA setup is more likely to yield a significant performance improvement.

Automatic methods

  • Set the VM’s NUMA policy to Preferred. For example, to do so for the testguest5 VM:

    # virt-xml testguest5 --edit --vcpus placement=auto
    # virt-xml testguest5 --edit --numatune mode=preferred
  • Enable automatic NUMA balancing on the host:

    # echo 1 > /proc/sys/kernel/numa_balancing
  • Use the numad command to automatically align the VM CPU with memory resources.

    # numad

Manual methods

  1. Pin specific vCPU threads to a specific host CPU or range of CPUs. This is also possible on non-NUMA hosts and VMs, and is recommended as a safe method of vCPU performance improvement.

    For example, the following commands pin vCPU threads 0 to 5 of the testguest6 VM to host CPUs 1, 3, 5, 7, 9, and 11, respectively:

    # virsh vcpupin testguest6 0 1
    # virsh vcpupin testguest6 1 3
    # virsh vcpupin testguest6 2 5
    # virsh vcpupin testguest6 3 7
    # virsh vcpupin testguest6 4 9
    # virsh vcpupin testguest6 5 11

    Afterwards, you can verify whether this was successful:

    # virsh vcpupin testguest6
    VCPU   CPU Affinity
    ----------------------
    0      1
    1      3
    2      5
    3      7
    4      9
    5      11
  2. After pinning vCPU threads, you can also pin QEMU process threads associated with a specified VM to a specific host CPU or range of CPUs. For example, the following commands pin the QEMU process thread of testguest6 to CPUs 13 and 15, and verify this was successful:

    # virsh emulatorpin testguest6 13,15
    # virsh emulatorpin testguest6
    emulator: CPU Affinity
    ----------------------------------
           *: 13,15
  3. Finally, you can also specify which host NUMA nodes will be assigned specifically to a certain VM. This can improve the host memory usage by the VM’s vCPU. For example, the following commands set testguest6 to use host NUMA nodes 3 to 5, and verify this was successful:

    # virsh numatune testguest6 --nodeset 3-5
    # virsh numatune testguest6
Note

For best performance results, it is recommended to use all of the manual tuning methods listed above

13.6.4. Sample vCPU performance tuning scenario

To obtain the best vCPU performance possible, Red Hat recommends using manual vcpupin, emulatorpin, and numatune settings together, for example like in the following scenario.

Starting scenario

  • Your host has the following hardware specifics:

    • 2 NUMA nodes
    • 3 CPU cores on each node
    • 2 threads on each core

    The output of virsh nodeinfo of such a machine would look similar to:

    # virsh nodeinfo
    CPU model:           x86_64
    CPU(s):              12
    CPU frequency:       3661 MHz
    CPU socket(s):       2
    Core(s) per socket:  3
    Thread(s) per core:  2
    NUMA cell(s):        2
    Memory size:         31248692 KiB
  • You intend to modify an existing VM to have 8 vCPUs, which means that it will not fit in a single NUMA node.

    Therefore, you should distribute 4 vCPUs on each NUMA node and make the vCPU topology resemble the host topology as closely as possible. This means that vCPUs that run as sibling threads of a given physical CPU should be pinned to host threads on the same core. For details, see the Solution below:

Solution

  1. Obtain the information on the host topology:

    # virsh capabilities

    The output should include a section that looks similar to the following:

    <topology>
      <cells num="2">
        <cell id="0">
          <memory unit="KiB">15624346</memory>
          <pages unit="KiB" size="4">3906086</pages>
          <pages unit="KiB" size="2048">0</pages>
          <pages unit="KiB" size="1048576">0</pages>
          <distances>
            <sibling id="0" value="10" />
            <sibling id="1" value="21" />
          </distances>
          <cpus num="6">
            <cpu id="0" socket_id="0" core_id="0" siblings="0,3" />
            <cpu id="1" socket_id="0" core_id="1" siblings="1,4" />
            <cpu id="2" socket_id="0" core_id="2" siblings="2,5" />
            <cpu id="3" socket_id="0" core_id="0" siblings="0,3" />
            <cpu id="4" socket_id="0" core_id="1" siblings="1,4" />
            <cpu id="5" socket_id="0" core_id="2" siblings="2,5" />
          </cpus>
        </cell>
        <cell id="1">
          <memory unit="KiB">15624346</memory>
          <pages unit="KiB" size="4">3906086</pages>
          <pages unit="KiB" size="2048">0</pages>
          <pages unit="KiB" size="1048576">0</pages>
          <distances>
            <sibling id="0" value="21" />
            <sibling id="1" value="10" />
          </distances>
          <cpus num="6">
            <cpu id="6" socket_id="1" core_id="3" siblings="6,9" />
            <cpu id="7" socket_id="1" core_id="4" siblings="7,10" />
            <cpu id="8" socket_id="1" core_id="5" siblings="8,11" />
            <cpu id="9" socket_id="1" core_id="3" siblings="6,9" />
            <cpu id="10" socket_id="1" core_id="4" siblings="7,10" />
            <cpu id="11" socket_id="1" core_id="5" siblings="8,11" />
          </cpus>
        </cell>
      </cells>
    </topology>
  2. Optional: Test the performance of the VM using the applicable tools and utilities.
  3. Set up and mount 1 GiB huge pages on the host:

    1. Add the following line to the host’s kernel command line:

      default_hugepagesz=1G hugepagesz=1G
    2. Create the /etc/systemd/system/hugetlb-gigantic-pages.service file with the following content:

      [Unit]
      Description=HugeTLB Gigantic Pages Reservation
      DefaultDependencies=no
      Before=dev-hugepages.mount
      ConditionPathExists=/sys/devices/system/node
      ConditionKernelCommandLine=hugepagesz=1G
      
      [Service]
      Type=oneshot
      RemainAfterExit=yes
      ExecStart=/etc/systemd/hugetlb-reserve-pages.sh
      
      [Install]
      WantedBy=sysinit.target
    3. Create the /etc/systemd/hugetlb-reserve-pages.sh file with the following content:

      #!/bin/sh
      
      nodes_path=/sys/devices/system/node/
      if [ ! -d $nodes_path ]; then
      	echo "ERROR: $nodes_path does not exist"
      	exit 1
      fi
      
      reserve_pages()
      {
      	echo $1 > $nodes_path/$2/hugepages/hugepages-1048576kB/nr_hugepages
      }
      
      reserve_pages 4 node1
      reserve_pages 4 node2

      This reserves four 1GiB huge pages from node1 and four 1GiB huge pages from node2.

    4. Make the script created in the previous step executable:

      # chmod +x /etc/systemd/hugetlb-reserve-pages.sh
    5. Enable huge page reservation on boot:

      # systemctl enable hugetlb-gigantic-pages
  4. Use the virsh edit command to edit the XML configuration of the VM you wish to optimize, in this example super-VM:

    # virsh edit super-vm
  5. Adjust the XML configuration of the VM in the following way:

    1. Set the VM to use 8 static vCPUs. Use the <vcpu/> element to do this.
    2. Pin each of the vCPU threads to the corresponding host CPU threads that it mirrors in the topology. To do so, use the <vcpupin/> elements in the <cputune> section.

      Note that, as shown by the virsh capabilities utility above, host CPU threads are not ordered sequentially in their respective cores. In addition, the vCPU threads should be pinned to the highest available set of host cores on the same NUMA node. For a table illustration, see the Sample topology section below.

      The XML configuration for steps a. and b. can look similar to:

      <cputune>
        <vcpupin vcpu='0' cpuset='1'/>
        <vcpupin vcpu='1' cpuset='4'/>
        <vcpupin vcpu='2' cpuset='2'/>
        <vcpupin vcpu='3' cpuset='5'/>
        <vcpupin vcpu='4' cpuset='7'/>
        <vcpupin vcpu='5' cpuset='10'/>
        <vcpupin vcpu='6' cpuset='8'/>
        <vcpupin vcpu='7' cpuset='11'/>
        <emulatorpin cpuset='6,9'/>
      </cputune>
    3. Set the VM to use 1 GiB huge pages:

      <memoryBacking>
        <hugepages>
          <page size='1' unit='GiB'/>
        </hugepages>
      </memoryBacking>
    4. Configure the VM’s NUMA nodes to use memory from the corresponding NUMA nodes on the host. To do so, use the <memnode/> elements in the <numatune/> section:

      <numatune>
        <memory mode="preferred" nodeset="1"/>
        <memnode cellid="0" mode="strict" nodeset="0"/>
        <memnode cellid="1" mode="strict" nodeset="1"/>
      </numatune>
    5. Ensure the CPU mode is set to host-passthrough, and that the CPU uses cache in passthrough mode:

      <cpu mode="host-passthrough">
        <topology sockets="2" cores="2" threads="2"/>
        <cache mode="passthrough"/>

Vérification

  1. Confirm that the resulting XML configuration of the VM includes a section similar to the following:

    [...]
      <memoryBacking>
        <hugepages>
          <page size='1' unit='GiB'/>
        </hugepages>
      </memoryBacking>
      <vcpu placement='static'>8</vcpu>
      <cputune>
        <vcpupin vcpu='0' cpuset='1'/>
        <vcpupin vcpu='1' cpuset='4'/>
        <vcpupin vcpu='2' cpuset='2'/>
        <vcpupin vcpu='3' cpuset='5'/>
        <vcpupin vcpu='4' cpuset='7'/>
        <vcpupin vcpu='5' cpuset='10'/>
        <vcpupin vcpu='6' cpuset='8'/>
        <vcpupin vcpu='7' cpuset='11'/>
        <emulatorpin cpuset='6,9'/>
      </cputune>
      <numatune>
        <memory mode="preferred" nodeset="1"/>
        <memnode cellid="0" mode="strict" nodeset="0"/>
        <memnode cellid="1" mode="strict" nodeset="1"/>
      </numatune>
      <cpu mode="host-passthrough">
        <topology sockets="2" cores="2" threads="2"/>
        <cache mode="passthrough"/>
        <numa>
          <cell id="0" cpus="0-3" memory="2" unit="GiB">
            <distances>
              <sibling id="0" value="10"/>
              <sibling id="1" value="21"/>
            </distances>
          </cell>
          <cell id="1" cpus="4-7" memory="2" unit="GiB">
            <distances>
              <sibling id="0" value="21"/>
              <sibling id="1" value="10"/>
            </distances>
          </cell>
        </numa>
      </cpu>
    </domain>
  2. Optional: Test the performance of the VM using the applicable tools and utilities to evaluate the impact of the VM’s optimization.

Sample topology

  • The following tables illustrate the connections between the vCPUs and the host CPUs they should be pinned to:

    Tableau 13.1. Host topology

    CPU threads

    0

    3

    1

    4

    2

    5

    6

    9

    7

    10

    8

    11

    Cores

    0

    1

    2

    3

    4

    5

    Sockets

    0

    1

    NUMA nodes

    0

    1

    Tableau 13.2. VM topology

    vCPU threads

    0

    1

    2

    3

    4

    5

    6

    7

    Cores

    0

    1

    2

    3

    Sockets

    0

    1

    NUMA nodes

    0

    1

    Tableau 13.3. Combined host and VM topology

    vCPU threads

     

    0

    1

    2

    3

     

    4

    5

    6

    7

    Host CPU threads

    0

    3

    1

    4

    2

    5

    6

    9

    7

    10

    8

    11

    Cores

    0

    1

    2

    3

    4

    5

    Sockets

    0

    1

    NUMA nodes

    0

    1

    In this scenario, there are 2 NUMA nodes and 8 vCPUs. Therefore, 4 vCPU threads should be pinned to each node.

    In addition, Red Hat recommends leaving at least a single CPU thread available on each node for host system operations.

    Because in this example, each NUMA node houses 3 cores, each with 2 host CPU threads, the set for node 0 translates as follows:

    <vcpupin vcpu='0' cpuset='1'/>
    <vcpupin vcpu='1' cpuset='4'/>
    <vcpupin vcpu='2' cpuset='2'/>
    <vcpupin vcpu='3' cpuset='5'/>

13.6.5. Managing kernel same-page merging

Kernel Same-Page Merging (KSM) improves memory density by sharing identical memory pages between virtual machines (VMs). However, enabling KSM increases CPU utilization, and might adversely affect overall performance depending on the workload.

Depending on your requirements, you can either enable or disable KSM for a single session or persistently.

Note

In RHEL 9 and later, KSM is disabled by default.

Conditions préalables

  • Root access to your host system.

Procédure

  • Disable KSM:

    • To deactivate KSM for a single session, use the systemctl utility to stop ksm and ksmtuned services.

      # systemctl stop ksm
      
      # systemctl stop ksmtuned
    • To deactivate KSM persistently, use the systemctl utility to disable ksm and ksmtuned services.

      # systemctl disable ksm
      Removed /etc/systemd/system/multi-user.target.wants/ksm.service.
      # systemctl disable ksmtuned
      Removed /etc/systemd/system/multi-user.target.wants/ksmtuned.service.
Note

Memory pages shared between VMs before deactivating KSM will remain shared. To stop sharing, delete all the PageKSM pages in the system using the following command:

# echo 2 > /sys/kernel/mm/ksm/run

After anonymous pages replace the KSM pages, the khugepaged kernel service will rebuild transparent hugepages on the VM’s physical memory.

  • Enable KSM:
Avertissement

Enabling KSM increases CPU utilization and affects overall CPU performance.

  1. Install the ksmtuned service:

    # yum install ksmtuned
  2. Start the service:

    • To enable KSM for a single session, use the systemctl utility to start the ksm and ksmtuned services.

      # systemctl start ksm
      # systemctl start ksmtuned
    • To enable KSM persistently, use the systemctl utility to enable the ksm and ksmtuned services.

      # systemctl enable ksm
      Created symlink /etc/systemd/system/multi-user.target.wants/ksm.service → /usr/lib/systemd/system/ksm.service
      
      # systemctl enable ksmtuned
      Created symlink /etc/systemd/system/multi-user.target.wants/ksmtuned.service → /usr/lib/systemd/system/ksmtuned.service

13.7. Optimizing virtual machine network performance

Due to the virtual nature of a VM’s network interface card (NIC), the VM loses a portion of its allocated host network bandwidth, which can reduce the overall workload efficiency of the VM. The following tips can minimize the negative impact of virtualization on the virtual NIC (vNIC) throughput.

Procédure

Use any of the following methods and observe if it has a beneficial effect on your VM network performance:

Enable the vhost_net module

On the host, ensure the vhost_net kernel feature is enabled:

# lsmod | grep vhost
vhost_net              32768  1
vhost                  53248  1 vhost_net
tap                    24576  1 vhost_net
tun                    57344  6 vhost_net

If the output of this command is blank, enable the vhost_net kernel module:

# modprobe vhost_net
Set up multi-queue virtio-net

To set up the multi-queue virtio-net feature for a VM, use the virsh edit command to edit to the XML configuration of the VM. In the XML, add the following to the <devices> section, and replace N with the number of vCPUs in the VM, up to 16:

<interface type='network'>
      <source network='default'/>
      <model type='virtio'/>
      <driver name='vhost' queues='N'/>
</interface>

If the VM is running, restart it for the changes to take effect.

Batching network packets

In Linux VM configurations with a long transmission path, batching packets before submitting them to the kernel may improve cache utilization. To set up packet batching, use the following command on the host, and replace tap0 with the name of the network interface that the VMs use:

# ethtool -C tap0 rx-frames 64
SR-IOV
Si votre carte réseau hôte prend en charge SR-IOV, utilisez l'affectation de périphériques SR-IOV pour vos cartes réseau virtuelles. Pour plus d'informations, voir Gestion des périphériques SR-IOV.

Ressources supplémentaires

13.8. Virtual machine performance monitoring tools

To identify what consumes the most VM resources and which aspect of VM performance needs optimization, performance diagnostic tools, both general and VM-specific, can be used.

Default OS performance monitoring tools

For standard performance evaluation, you can use the utilities provided by default by your host and guest operating systems:

  • On your RHEL 9 host, as root, use the top utility or the system monitor application, and look for qemu and virt in the output. This shows how much host system resources your VMs are consuming.

    • If the monitoring tool displays that any of the qemu or virt processes consume a large portion of the host CPU or memory capacity, use the perf utility to investigate. For details, see below.
    • In addition, if a vhost_net thread process, named for example vhost_net-1234, is displayed as consuming an excessive amount of host CPU capacity, consider using virtual network optimization features, such as multi-queue virtio-net.
  • On the guest operating system, use performance utilities and applications available on the system to evaluate which processes consume the most system resources.

    • On Linux systems, you can use the top utility.
    • On Windows systems, you can use the Task Manager application.

perf kvm

You can use the perf utility to collect and analyze virtualization-specific statistics about the performance of your RHEL 9 host. To do so:

  1. On the host, install the perf package:

    # dnf install perf
  2. Use one of the perf kvm stat commands to display perf statistics for your virtualization host:

    • For real-time monitoring of your hypervisor, use the perf kvm stat live command.
    • To log the perf data of your hypervisor over a period of time, activate the logging using the perf kvm stat record command. After the command is canceled or interrupted, the data is saved in the perf.data.guest file, which can be analyzed using the perf kvm stat report command.
  3. Analyze the perf output for types of VM-EXIT events and their distribution. For example, the PAUSE_INSTRUCTION events should be infrequent, but in the following output, the high occurrence of this event suggests that the host CPUs are not handling the running vCPUs well. In such a scenario, consider shutting down some of your active VMs, removing vCPUs from these VMs, or tuning the performance of the vCPUs.

    # perf kvm stat report
    
    Analyze events for all VMs, all VCPUs:
    
    
                 VM-EXIT    Samples  Samples%     Time%    Min Time    Max Time         Avg time
    
      EXTERNAL_INTERRUPT     365634    31.59%    18.04%      0.42us  58780.59us    204.08us ( +-   0.99% )
               MSR_WRITE     293428    25.35%     0.13%      0.59us  17873.02us      1.80us ( +-   4.63% )
        PREEMPTION_TIMER     276162    23.86%     0.23%      0.51us  21396.03us      3.38us ( +-   5.19% )
       PAUSE_INSTRUCTION     189375    16.36%    11.75%      0.72us  29655.25us    256.77us ( +-   0.70% )
                     HLT      20440     1.77%    69.83%      0.62us  79319.41us  14134.56us ( +-   0.79% )
                  VMCALL      12426     1.07%     0.03%      1.02us   5416.25us      8.77us ( +-   7.36% )
           EXCEPTION_NMI         27     0.00%     0.00%      0.69us      1.34us      0.98us ( +-   3.50% )
           EPT_MISCONFIG          5     0.00%     0.00%      5.15us     10.85us      7.88us ( +-  11.67% )
    
    Total Samples:1157497, Total events handled time:413728274.66us.

    Other event types that can signal problems in the output of perf kvm stat include:

For more information on using perf to monitor virtualization performance, see the perf-kvm man page.

numastat

To see the current NUMA configuration of your system, you can use the numastat utility, which is provided by installing the numactl package.

The following shows a host with 4 running VMs, each obtaining memory from multiple NUMA nodes. This is not optimal for vCPU performance, and warrants adjusting:

# numastat -c qemu-kvm

Per-node process memory usage (in MBs)
PID              Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
51722 (qemu-kvm)     68     16    357   6936      2      3    147    598  8128
51747 (qemu-kvm)    245     11      5     18   5172   2532      1     92  8076
53736 (qemu-kvm)     62    432   1661    506   4851    136     22    445  8116
53773 (qemu-kvm)   1393      3      1      2     12      0      0   6702  8114
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
Total              1769    463   2024   7462  10037   2672    169   7837 32434

In contrast, the following shows memory being provided to each VM by a single node, which is significantly more efficient.

# numastat -c qemu-kvm

Per-node process memory usage (in MBs)
PID              Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
51747 (qemu-kvm)      0      0      7      0   8072      0      1      0  8080
53736 (qemu-kvm)      0      0      7      0      0      0   8113      0  8120
53773 (qemu-kvm)      0      0      7      0      0      0      1   8110  8118
59065 (qemu-kvm)      0      0   8050      0      0      0      0      0  8051
---------------  ------ ------ ------ ------ ------ ------ ------ ------ -----
Total                 0      0   8072      0   8072      0   8114   8110 32368

Chapitre 14. Importance de la gestion de l'énergie

La réduction de la consommation d'énergie globale des systèmes informatiques permet de réaliser des économies. L'optimisation efficace de la consommation d'énergie de chaque composant du système passe par l'étude des différentes tâches effectuées par le système et par la configuration de chaque composant pour s'assurer que ses performances sont adaptées à cette tâche. La réduction de la consommation d'énergie d'un composant spécifique ou du système dans son ensemble permet de réduire la chaleur et les performances.

Une bonne gestion de l'énergie se traduit par :

  • réduction de la chaleur pour les serveurs et les centres de calcul
  • réduction des coûts secondaires, notamment en ce qui concerne le refroidissement, l'espace, les câbles, les générateurs et les alimentations sans interruption (ASI)
  • prolongation de la durée de vie de la batterie des ordinateurs portables
  • réduction de la production de dioxyde de carbone
  • respecter les réglementations gouvernementales ou les exigences légales concernant les technologies de l'information vertes, par exemple Energy Star
  • respecter les lignes directrices de l'entreprise pour les nouveaux systèmes

Cette section décrit les informations relatives à la gestion de l'alimentation de vos systèmes Red Hat Enterprise Linux.

14.1. Principes de base de la gestion de l'énergie

Une gestion efficace de l'énergie repose sur les principes suivants :

An idle CPU should only wake up when needed

Depuis Red Hat Enterprise Linux 6, le noyau fonctionne sur tickless, ce qui signifie que les interruptions périodiques précédentes ont été remplacées par des interruptions à la demande. Par conséquent, les CPU inactifs sont autorisés à rester inactifs jusqu'à ce qu'une nouvelle tâche soit mise en file d'attente pour le traitement, et les CPU qui sont entrés dans des états de puissance plus faibles peuvent rester dans ces états plus longtemps. Toutefois, les avantages de cette fonction peuvent être annulés si votre système comporte des applications qui créent des événements de temporisation inutiles. Les événements d'interrogation, tels que les vérifications des changements de volume ou des mouvements de la souris, sont des exemples de tels événements.

Red Hat Enterprise Linux comprend des outils qui vous permettent d'identifier et d'auditer des applications sur la base de leur utilisation du processeur. Pour plus d'informations, consultez les sections Vue d'ensemble de l'audit et de l'analyse et Outils d'audit.

Unused hardware and devices should be disabled completely
C'est le cas des périphériques qui ont des pièces mobiles, comme les disques durs. En outre, certaines applications peuvent laisser un périphérique inutilisé mais activé "ouvert" ; dans ce cas, le noyau suppose que le périphérique est utilisé, ce qui peut empêcher le périphérique de passer en état d'économie d'énergie.
Low activity should translate to low wattage

Dans de nombreux cas, cependant, cela dépend d'un matériel moderne et d'une configuration correcte du BIOS ou de l'UEFI sur les systèmes modernes, y compris les architectures non-x86. Assurez-vous que vous utilisez le dernier micrologiciel officiel pour vos systèmes et que les fonctions de gestion de l'énergie sont activées dans les sections de gestion de l'énergie ou de configuration des périphériques du BIOS. Parmi les fonctions à rechercher, citons

  • Prise en charge du contrôle collaboratif des performances des processeurs (CPPC) pour ARM64
  • Prise en charge de PowerNV pour les systèmes Power d'IBM
  • SpeedStep
  • PowerNow !
  • Cool'n'Quiet
  • ACPI (état C)
  • Intelligent

    Si votre matériel prend en charge ces fonctionnalités et qu'elles sont activées dans le BIOS, Red Hat Enterprise Linux les utilise par défaut.

Different forms of CPU states and their effects

Les unités centrales modernes et l'interface ACPI (Advanced Configuration and Power Interface) proposent différents états d'alimentation. Les trois états différents sont les suivants :

  • Sommeil (états C)
  • Fréquence et tension (états P)
  • Production de chaleur (états T ou états thermiques)

    Un processeur fonctionnant dans l'état de veille le plus bas consomme le moins de watts, mais il faut aussi beaucoup plus de temps pour le réveiller de cet état lorsque c'est nécessaire. Dans de très rares cas, cela peut conduire à ce que l'unité centrale doive se réveiller immédiatement chaque fois qu'elle vient de s'endormir. Dans ce cas, l'unité centrale est occupée en permanence et perd une partie de l'économie d'énergie potentielle qu'aurait permis l'utilisation d'un autre état.

A turned off machine uses the least amount of power
L'un des meilleurs moyens d'économiser de l'énergie est d'éteindre les systèmes. Par exemple, votre entreprise peut développer une culture d'entreprise axée sur la sensibilisation à l'"informatique verte", avec pour consigne d'éteindre les machines pendant la pause déjeuner ou en rentrant chez soi. Vous pouvez également consolider plusieurs serveurs physiques en un seul serveur plus grand et les virtualiser à l'aide de la technologie de virtualisation fournie avec Red Hat Enterprise Linux.

14.2. Vue d'ensemble de l'audit et de l'analyse

L'audit manuel détaillé, l'analyse et le réglage d'un système unique sont généralement l'exception, car le temps et le coût consacrés à cette opération dépassent généralement les avantages tirés de ces derniers éléments de réglage du système.

Toutefois, il peut être très utile d'effectuer ces tâches une seule fois pour un grand nombre de systèmes presque identiques, en réutilisant les mêmes paramètres pour tous les systèmes. Prenons l'exemple du déploiement de milliers d'ordinateurs de bureau ou d'un cluster HPC dont les machines sont presque identiques. Une autre raison d'effectuer des audits et des analyses est de fournir une base de comparaison permettant d'identifier les régressions ou les changements dans le comportement du système à l'avenir. Les résultats de cette analyse peuvent être très utiles dans les cas où des mises à jour du matériel, du BIOS ou des logiciels ont lieu régulièrement et où vous souhaitez éviter toute surprise en ce qui concerne la consommation d'énergie. En règle générale, un audit et une analyse approfondis vous donnent une bien meilleure idée de ce qui se passe réellement sur un système donné.

L'audit et l'analyse d'un système en ce qui concerne la consommation d'énergie sont relativement difficiles, même avec les systèmes les plus modernes disponibles. La plupart des systèmes ne fournissent pas les moyens nécessaires pour mesurer la consommation d'énergie par le biais d'un logiciel. Il existe cependant des exceptions :

  • la console de gestion iLO des systèmes de serveurs Hewlett Packard dispose d'un module de gestion de l'alimentation auquel vous pouvez accéder via le web.
  • IBM propose une solution similaire dans son module de gestion de l'énergie BladeCenter.
  • Sur certains systèmes Dell, l'assistant informatique offre également des fonctions de surveillance de l'alimentation.

D'autres fournisseurs sont susceptibles d'offrir des capacités similaires pour leurs plates-formes de serveurs, mais comme on peut le voir, il n'existe pas de solution unique prise en charge par tous les fournisseurs. Les mesures directes de la consommation d'énergie ne sont souvent nécessaires que pour maximiser les économies dans la mesure du possible.

14.3. Outils d'audit

Red Hat Enterprise Linux 8 propose des outils permettant d'effectuer l'audit et l'analyse du système. La plupart d'entre eux peuvent être utilisés comme sources d'informations supplémentaires au cas où vous souhaiteriez vérifier ce que vous avez déjà découvert ou au cas où vous auriez besoin d'informations plus approfondies sur certaines parties.

Nombre de ces outils sont également utilisés pour l'optimisation des performances :

PowerTOP
Il identifie les composants spécifiques des applications du noyau et de l'espace utilisateur qui réveillent fréquemment le processeur. Utilisez la commande powertop en tant que root pour lancer l'outil PowerTop et powertop --calibrate pour calibrer le moteur d'estimation de la consommation d'énergie. Pour plus d'informations sur PowerTop, voir Gérer la consommation d'énergie avec PowerTOP.
Diskdevstat and netdevstat

Il s'agit d'outils SystemTap qui collectent des informations détaillées sur l'activité du disque et du réseau de toutes les applications exécutées sur un système. En utilisant les statistiques collectées par ces outils, vous pouvez identifier les applications qui gaspillent de l'énergie avec de nombreuses petites opérations d'E/S plutôt qu'avec un nombre réduit d'opérations plus importantes. En utilisant la commande dnf install tuned-utils-systemtap kernel-debuginfo en tant que root, installez les outils diskdevstat et netdevstat.

Pour afficher les informations détaillées sur l'activité du disque et du réseau, utilisez :

# diskdevstat

PID   UID   DEV   WRITE_CNT   WRITE_MIN   WRITE_MAX   WRITE_AVG   READ_CNT   READ_MIN   READ_MAX   READ_AVG   COMMAND

3575  1000  dm-2   59          0.000      0.365        0.006        5         0.000        0.000      0.000      mozStorage #5
3575  1000  dm-2    7          0.000      0.000        0.000        0         0.000        0.000      0.000      localStorage DB
[...]


# netdevstat

PID   UID   DEV       XMIT_CNT   XMIT_MIN   XMIT_MAX   XMIT_AVG   RECV_CNT   RECV_MIN   RECV_MAX   RECV_AVG   COMMAND
3572  991  enp0s31f6    40       0.000      0.882       0.108        0         0.000       0.000       0.000     openvpn
3575  1000 enp0s31f6    27       0.000      1.363       0.160        0         0.000       0.000       0.000     Socket Thread
[...]

Avec ces commandes, vous pouvez spécifier trois paramètres : update_interval, total_duration, et display_histogram.

TuneD
Il s'agit d'un outil de réglage du système basé sur des profils qui utilise le gestionnaire de périphériques udev pour surveiller les périphériques connectés et qui permet un réglage statique et dynamique des paramètres du système. Vous pouvez utiliser la commande tuned-adm recommend pour déterminer quel profil Red Hat recommande comme étant le plus approprié pour un produit particulier. Pour plus d'informations sur TuneD, reportez-vous aux sections Premiers pas avec TuneD et Personnalisation des profils TuneD. En utilisant l'utilitaire powertop2tuned utility, vous pouvez créer des profils TuneD personnalisés à partir des suggestions de PowerTOP. Pour plus d'informations sur l'utilitaire powertop2tuned, voir Optimiser la consommation d'énergie.
Virtual memory statistics (vmstat)

Il est fourni par le paquetage procps-ng. Cet outil permet d'afficher des informations détaillées sur les processus, la mémoire, la pagination, les entrées/sorties par bloc, les pièges et l'activité de l'unité centrale.

Pour afficher ces informations, utilisez :

$ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r  b  swpd  free    buff   cache   si   so  bi   bo   in  cs  us  sy id  wa  st
1  0   0   5805576 380856 4852848   0    0  119  73  814  640  2   2 96   0   0

La commande vmstat -a permet d'afficher la mémoire active et inactive. Pour plus d'informations sur les autres options de vmstat, consultez la page de manuel vmstat.

iostat

Il est fourni par le paquetage sysstat. Cet outil est similaire à vmstat, mais uniquement pour la surveillance des E/S sur les périphériques en mode bloc. Il fournit également des statistiques et des résultats plus détaillés.

Pour surveiller les entrées/sorties du système, utilisez

$ iostat
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.05    0.46    1.55    0.26    0.00   95.67

Device     tps     kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
nvme0n1    53.54     899.48     616.99      3445229     2363196
dm-0       42.84     753.72     238.71      2886921      914296
dm-1        0.03       0.60       0.00         2292           0
dm-2       24.15     143.12     379.80       548193     1454712
blktrace

Il fournit des informations détaillées sur le temps passé dans le sous-système d'E/S.

Pour visualiser ces informations dans un format lisible par l'homme, utilisez :

# blktrace -d /dev/dm-0 -o - | blkparse -i -

253,0   1    1   0.000000000  17694  Q   W 76423384 + 8 [kworker/u16:1]
253,0   2    1   0.001926913     0   C   W 76423384 + 8 [0]
[...]

Ici, la première colonne, 253,0, est le tuple majeur et mineur du périphérique. La deuxième colonne, 1, donne des informations sur le processeur, suivies de colonnes pour les horodatages et le PID du processus émettant le processus IO.

La sixième colonne, Q, indique le type d'événement, la septième colonne, W pour l'opération d'écriture, la huitième colonne, 76423384, est le numéro de bloc, et 8 est le nombre de blocs demandés.

Le dernier champ, [kworker/u16:1], est le nom du processus.

Par défaut, la commande blktrace s'exécute indéfiniment jusqu'à ce que le processus soit explicitement tué. L'option -w permet de spécifier la durée d'exécution.

turbostat

Il est fourni par le paquetage kernel-tools. Il fournit des informations sur la topologie du processeur, la fréquence, les statistiques sur l'état de fonctionnement au repos, la température et la consommation d'énergie des processeurs x86-64.

Pour consulter ce résumé, utilisez :

# turbostat

CPUID(0): GenuineIntel 0x16 CPUID levels; 0x80000008 xlevels; family:model:stepping 0x6:8e:a (6:142:10)
CPUID(1): SSE3 MONITOR SMX EIST TM2 TSC MSR ACPI-TM HT TM
CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow, HWPepp, No-HWPpkg, EPB
[...]

Par défaut, turbostat imprime un résumé des résultats du compteur pour l'ensemble de l'écran, suivi des résultats du compteur toutes les 5 secondes. Spécifiez une période différente entre les résultats du compteur avec l'option -i, par exemple, exécutez turbostat -i 10 pour imprimer les résultats toutes les 10 secondes à la place.

Turbostat est également utile pour identifier les serveurs qui sont inefficaces en termes de consommation d'énergie ou de temps d'inactivité. Il permet également d'identifier le taux d'interruptions de gestion du système (SMI) survenant sur le système. Il peut également être utilisé pour vérifier les effets des réglages de la gestion de l'énergie.

cpupower

IT est une collection d'outils permettant d'examiner et de régler les fonctions d'économie d'énergie des processeurs. Utilisez la commande cpupower avec les options frequency-info, frequency-set, idle-info, idle-set, set, info, et monitor pour afficher et définir les valeurs relatives au processeur.

Par exemple, pour afficher les gouverneurs cpufreq disponibles, utilisez la commande suivante

$ cpupower frequency-info --governors
analyzing CPU 0:
  available cpufreq governors: performance powersave

Pour plus d'informations sur cpupower, voir Affichage des informations relatives à l'unité centrale.

GNOME Power Manager
Il s'agit d'un démon installé dans le cadre de l'environnement de bureau GNOME. Le gestionnaire d'alimentation GNOME vous informe des changements dans l'état de l'alimentation de votre système, par exemple, le passage de la batterie à l'alimentation secteur. Il signale également l'état de la batterie et vous avertit lorsque celle-ci est faible.

Ressources supplémentaires

  • powertop(1)pages de manuel : diskdevstat(8), netdevstat(8), tuned(8), vmstat(8), iostat(1), blktrace(8), blkparse(8), et turbostat(8)
  • cpupower(1)pages de manuel : cpupower-set(1), cpupower-info(1), cpupower-idle(1), cpupower-frequency-set(1), cpupower-frequency-info(1), et cpupower-monitor(1)

Chapitre 15. Gérer la consommation d'énergie avec PowerTOP

En tant qu'administrateur système, vous pouvez utiliser l'outil PowerTOP pour analyser et gérer la consommation d'énergie.

15.1. L'objectif de PowerTOP

PowerTOP est un programme qui diagnostique les problèmes liés à la consommation d'énergie et fournit des suggestions sur la manière de prolonger la durée de vie de la batterie.

L'outil PowerTOP peut fournir une estimation de la consommation totale d'énergie du système ainsi que de la consommation individuelle d'énergie pour chaque processus, périphérique, travailleur du noyau, temporisateur et gestionnaire d'interruptions. L'outil peut également identifier les composants spécifiques des applications du noyau et de l'espace utilisateur qui réveillent fréquemment le processeur.

Red Hat Enterprise Linux 9 utilise la version 2.x de PowerTOP.

15.2. Utilisation de PowerTOP

Conditions préalables

  • Pour pouvoir utiliser PowerTOPassurez-vous que le paquetage powertop a été installé sur votre système :

    # dnf install powertop

15.2.1. Démarrage de PowerTOP

Procédure

  • Pour exécuter PowerTOPutilisez la commande suivante :

    # powertop
Important

Les ordinateurs portables doivent fonctionner sur batterie lors de l'exécution de la commande powertop.

15.2.2. Étalonnage de PowerTOP

Procédure

  1. Sur un ordinateur portable, vous pouvez calibrer le moteur d'estimation de puissance en exécutant la commande suivante :

    # powertop --calibrate
  2. Laissez l'étalonnage se terminer sans interagir avec la machine pendant le processus.

    L'étalonnage prend du temps car le processus effectue divers tests, passe par des niveaux de luminosité et allume et éteint les appareils.

  3. Lorsque le processus d'étalonnage est terminé, PowerTOP démarre normalement. Laissez-le fonctionner pendant environ une heure pour collecter les données.

    Lorsque suffisamment de données sont collectées, les chiffres de l'estimation de la puissance sont affichés dans la première colonne du tableau de sortie.

Note

Notez que powertop --calibrate ne peut être utilisé que sur des ordinateurs portables.

15.2.3. Réglage de l'intervalle de mesure

Par défaut, PowerTOP prend des mesures à intervalles de 20 secondes.

Si vous souhaitez modifier cette fréquence de mesure, utilisez la procédure suivante :

Procédure

  • Exécutez la commande powertop avec l'option --time:

    # powertop --time=time in seconds

15.3. Statistiques PowerTOP

Pendant qu'il s'exécute, PowerTOP recueille des statistiques sur le système.

PowerTOPfournit plusieurs onglets :

  • Overview
  • Idle stats
  • Frequency stats
  • Device stats
  • Tunables
  • WakeUp

Vous pouvez utiliser les touches Tab et Shift Tab pour parcourir ces onglets.

15.3.1. L'onglet Vue d'ensemble

Dans l'onglet Overview, vous pouvez afficher une liste des composants qui envoient le plus souvent des réveils au processeur ou qui consomment le plus d'énergie. Les éléments de l'onglet Overview, y compris les processus, les interruptions, les périphériques et les autres ressources, sont triés en fonction de leur utilisation.

Les colonnes adjacentes de l'onglet Overview fournissent les informations suivantes :

Utilisation
Estimation de la puissance de l'utilisation de la ressource.
Événements/s
Réveils par seconde. Le nombre de réveils par seconde indique l'efficacité des services ou des périphériques et pilotes du noyau. Moins de réveils signifie que moins d'énergie est consommée. Les composants sont classés en fonction de l'optimisation de leur consommation d'énergie.
Catégorie
Classification du composant, par exemple processus, dispositif ou temporisateur.
Description
Description du composant.

S'il est correctement calibré, une estimation de la consommation d'énergie pour chaque élément répertorié dans la première colonne est également affichée.

En outre, l'onglet Overview comprend une ligne avec des statistiques sommaires telles que

  • Consommation électrique totale
  • Durée de vie restante de la batterie (uniquement si applicable)
  • Résumé du nombre total de réveils par seconde, d'opérations du GPU par seconde et d'opérations du système de fichiers virtuels par seconde

15.3.2. L'onglet Statistiques d'inactivité

L'onglet Idle stats montre l'utilisation des états C pour tous les processeurs et cœurs, tandis que l'onglet Frequency stats montre l'utilisation des états P, y compris le mode Turbo, le cas échéant, pour tous les processeurs et cœurs. La durée des états C ou P indique dans quelle mesure l'utilisation du processeur a été optimisée. Plus le CPU reste longtemps dans des états C ou P élevés (par exemple, C4 est plus élevé que C3), meilleure est l'optimisation de l'utilisation du CPU. Idéalement, le taux de résidence est de 90 % ou plus dans les états C ou P les plus élevés lorsque le système est inactif.

15.3.3. L'onglet Statistiques de l'appareil

L'onglet Device stats fournit des informations similaires à l'onglet Overview, mais uniquement pour les appareils.

15.3.4. L'onglet Tunables

L'onglet Tunables contient les suggestions de PowerTOPl'onglet contient les suggestions d'optimisation du système pour réduire la consommation d'énergie.

Utilisez les touches up et down pour vous déplacer dans les suggestions, et la touche enter pour activer ou désactiver la suggestion.

15.3.5. L'onglet WakeUp

L'onglet WakeUp affiche les paramètres de réveil de l'appareil que les utilisateurs peuvent modifier au besoin.

Utilisez les touches up et down pour vous déplacer parmi les paramètres disponibles, et la touche enter pour activer ou désactiver un paramètre.

Figure 15.1. Sortie PowerTOP

powertop2 14

Ressources supplémentaires

Pour plus de détails sur PowerTOPvoir la page d'accueil de PowerTOP.

15.4. Pourquoi Powertop n'affiche-t-il pas les valeurs des statistiques de fréquence dans certains cas ?

Lors de l'utilisation du pilote Intel P-State, PowerTOP n'affiche les valeurs dans l'onglet Frequency Stats que si le pilote est en mode passif. Mais, même dans ce cas, les valeurs peuvent être incomplètes.

Au total, il existe trois modes possibles pour le pilote Intel P-State :

  • Mode actif avec états P matériels (HWP)
  • Mode actif sans HWP
  • Mode passif

Le passage au pilote ACPI CPUfreq permet à PowerTOP d'afficher des informations complètes. Toutefois, il est recommandé de conserver les paramètres par défaut de votre système.

Pour voir quel pilote est chargé et dans quel mode, exécutez :

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
  • intel_pstate est renvoyée si le pilote Intel P-State est chargé et en mode actif.
  • intel_cpufreq est renvoyée si le pilote Intel P-State est chargé et en mode passif.
  • acpi-cpufreq est renvoyé si le pilote ACPI CPUfreq est chargé.

Lorsque vous utilisez le pilote Intel P-State, ajoutez l'argument suivant à la ligne de commande de démarrage du noyau pour forcer le pilote à fonctionner en mode passif :

intel_pstate=passive

Pour désactiver le pilote Intel P-State et utiliser à la place le pilote ACPI CPUfreq, ajoutez l'argument suivant à la ligne de commande de démarrage du noyau :

intel_pstate=disable

15.5. Générer une sortie HTML

Outre la sortie powertop’s dans le terminal, vous pouvez également générer un rapport HTML.

Procédure

  • Exécutez la commande powertop avec l'option --html:

    # powertop --html=htmlfile.html

    Remplacez le paramètre htmlfile.html par le nom requis pour le fichier de sortie.

15.6. Optimiser la consommation d'énergie

Pour optimiser la consommation d'énergie, vous pouvez utiliser le service powertop ou l'utilitaire powertop2tuned.

15.6.1. Optimisation de la consommation d'énergie à l'aide du service powertop

Vous pouvez utiliser le service powertop pour activer automatiquement toutes les suggestions de PowerTOPvous pouvez utiliser le service Tunables pour activer automatiquement toutes les suggestions de dans l'onglet "boot" :

Procédure

  • Activer le service powertop:

    # systemctl enable powertop

15.6.2. L'utilitaire powertop2tuned

L'utilitaire powertop2tuned vous permet de créer des profils personnalisés TuneD à partir de PowerTOP suggestions.

Par défaut, powertop2tuned crée des profils dans le répertoire /etc/tuned/ et base le profil personnalisé sur le profil actuellement sélectionné TuneD sélectionné. Pour des raisons de sécurité, tous les PowerTOP sont initialement désactivés dans le nouveau profil.

Pour activer les réglages, vous pouvez

  • Décommentez-les dans le site /etc/tuned/profile_name/tuned.conf file.
  • Utilisez l'option --enable ou -e pour générer un nouveau profil qui permet la plupart des accords suggérés par PowerTOP.

    Certains réglages potentiellement problématiques, tels que l'autosuspend USB, sont désactivés par défaut et doivent être décommentés manuellement.

15.6.3. Optimisation de la consommation d'énergie à l'aide de l'utilitaire powertop2tuned

Conditions préalables

  • L'utilitaire powertop2tuned est installé sur le système :

    # dnf install tuned-utils

Procédure

  1. Créer un profil personnalisé :

    # powertop2tuned nouveau_nom_du_profil
  2. Activer le nouveau profil :

    # tuned-adm profile new_profile_name

Informations complémentaires

  • Pour obtenir une liste complète des options prises en charge par powertop2tuned, utilisez le lien suivant :

    powertop2tuned --help

15.6.4. Comparaison entre powertop.service et powertop2tuned

L'optimisation de la consommation d'énergie avec powertop2tuned est préférable à powertop.service pour les raisons suivantes :

  • L'utilitaire powertop2tuned représente l'intégration de PowerTOP dans TuneDqui permet de bénéficier des avantages des deux outils.
  • L'utilitaire powertop2tuned permet un contrôle fin des réglages activés.
  • Avec powertop2tuned, les réglages potentiellement dangereux ne sont pas automatiquement activés.
  • Avec powertop2tuned, le retour en arrière est possible sans redémarrage.

Chapitre 16. Démarrer avec perf

En tant qu'administrateur système, vous pouvez utiliser l'outil perf pour collecter et analyser les données de performance de votre système.

16.1. Introduction à la perf

L'outil de l'espace utilisateur perf s'interface avec le sous-système basé sur le noyau Performance Counters for Linux (PCL). perf est un outil puissant qui utilise l'unité de surveillance des performances (PMU) pour mesurer, enregistrer et surveiller une variété d'événements matériels et logiciels. perf prend également en charge les tracepoints, les kprobes et les uprobes.

16.2. Installation de perf

Cette procédure installe l'outil perf dans l'espace utilisateur.

Procédure

  • Installer l'outil perf:

    # dnf install perf

16.3. Commandes courantes de perf

perf stat
Cette commande fournit des statistiques globales pour les événements de performance courants, notamment les instructions exécutées et les cycles d'horloge consommés. Des options permettent de sélectionner des événements autres que les événements de mesure par défaut.
perf record
Cette commande enregistre les données de performance dans un fichier, perf.data, qui peut être analysé ultérieurement à l'aide de la commande perf report.
perf report
Cette commande permet de lire et d'afficher les données de performance du fichier perf.data créé par perf record.
perf list
Cette commande dresse la liste des événements disponibles sur une machine donnée. Ces événements varient en fonction de la configuration matérielle et logicielle du système.
perf top
Cette commande a une fonction similaire à celle de l'utilitaire top. Elle génère et affiche un profil de compteur de performance en temps réel.
perf trace
Cette commande a une fonction similaire à celle de l'outil strace. Elle surveille les appels système utilisés par un thread ou un processus spécifié et tous les signaux reçus par cette application.
perf help
Cette commande permet d'afficher la liste complète des commandes perf.

Ressources supplémentaires

  • Ajouter l'option --help à une sous-commande pour ouvrir la page de manuel.

Chapitre 17. Profilage de l'utilisation de l'unité centrale en temps réel avec perf top

Vous pouvez utiliser la commande perf top pour mesurer l'utilisation de l'unité centrale de différentes fonctions en temps réel.

Conditions préalables

17.1. L'objectif de perf top

La commande perf top est utilisée pour établir le profil du système en temps réel et fonctionne de la même manière que l'utilitaire top. Cependant, alors que l'utilitaire top vous indique généralement le temps d'utilisation du processeur d'un processus ou d'un thread donné, perf top vous indique le temps d'utilisation du processeur de chaque fonction spécifique. Dans son état par défaut, perf top vous renseigne sur les fonctions utilisées par tous les processeurs, tant dans l'espace utilisateur que dans l'espace noyau. Pour utiliser perf top, vous devez disposer d'un accès root.

17.2. Profilage de l'utilisation de l'unité centrale avec perf top

Cette procédure active perf top et établit le profil de l'utilisation de l'unité centrale en temps réel.

Conditions préalables

  • L'outil de l'espace utilisateur perf est installé comme décrit dans la section Installation de perf.
  • Vous avez un accès root

Procédure

  • Lancez l'interface de surveillance perf top:

    # perf top

    L'interface de surveillance ressemble à ce qui suit :

    Samples: 8K of event 'cycles', 2000 Hz, Event count (approx.): 4579432780 lost: 0/0 drop: 0/0
    Overhead  Shared Object       Symbol
       2.20%  [kernel]            [k] do_syscall_64
       2.17%  [kernel]            [k] module_get_kallsym
       1.49%  [kernel]            [k] copy_user_enhanced_fast_string
       1.37%  libpthread-2.29.so  [.] pthread_mutex_lock 1.31% [unknown] [.] 0000000000000000 1.07% [kernel] [k] psi_task_change 1.04% [kernel] [k] switch_mm_irqs_off 0.94% [kernel] [k] fget
       0.74%  [kernel]            [k] entry_SYSCALL_64
       0.69%  [kernel]            [k] syscall_return_via_sysret
       0.69%  libxul.so           [.] 0x000000000113f9b0
       0.67%  [kernel]            [k] kallsyms_expand_symbol.constprop.0
       0.65%  firefox             [.] moz_xmalloc
       0.65%  libpthread-2.29.so  [.] __pthread_mutex_unlock_usercnt
       0.60%  firefox             [.] free
       0.60%  libxul.so           [.] 0x000000000241d1cd
       0.60%  [kernel]            [k] do_sys_poll
       0.58%  [kernel]            [k] menu_select
       0.56%  [kernel]            [k] _raw_spin_lock_irqsave
       0.55%  perf                [.] 0x00000000002ae0f3

    Dans cet exemple, c'est la fonction noyau do_syscall_64 qui utilise le plus de temps processeur.

Ressources supplémentaires

  • perf-top(1) page de manuel

17.3. Interprétation de la sortie de perf top

L'interface de surveillance perf top affiche les données dans plusieurs colonnes :

La colonne "Overhead" (frais généraux)
Affiche le pourcentage de CPU utilisé par une fonction donnée.
La colonne "Objets partagés
Affiche le nom du programme ou de la bibliothèque qui utilise la fonction.
La colonne "Symbol
Affiche le nom ou le symbole de la fonction. Les fonctions exécutées dans l'espace noyau sont identifiées par [k] et les fonctions exécutées dans l'espace utilisateur sont identifiées par [.].

17.4. Pourquoi perf affiche-t-il certains noms de fonctions comme des adresses de fonctions brutes ?

Pour les fonctions du noyau, perf utilise les informations du fichier /proc/kallsyms pour faire correspondre les échantillons à leurs noms de fonction ou symboles respectifs. Pour les fonctions exécutées dans l'espace utilisateur, cependant, vous pouvez voir des adresses de fonctions brutes parce que le binaire est dépouillé.

Le paquet debuginfo de l'exécutable doit être installé ou, si l'exécutable est une application développée localement, l'application doit être compilée avec les informations de débogage activées (l'option -g dans GCC) pour afficher les noms de fonction ou les symboles dans une telle situation.

Note

Il n'est pas nécessaire de réexécuter la commande perf record après avoir installé la commande debuginfo associée à un exécutable. Il suffit de réexécuter la commande perf report.

17.5. Activation des dépôts de débogage et de sources

Une installation standard de Red Hat Enterprise Linux n'active pas les référentiels de débogage et de sources. Ces référentiels contiennent des informations nécessaires pour déboguer les composants du système et mesurer leurs performances.

Procédure

  • Activez les canaux du paquet d'informations de source et de débogage : La partie $(uname -i) est automatiquement remplacée par une valeur correspondant à l'architecture de votre système :

    Nom de l'architectureValeur

    64-bit Intel et AMD

    x86_64

    aRM 64 bits

    aarch64

    IBM POWER

    ppc64le

    iBM Z 64 bits

    s390x

17.6. Obtenir les paquets d'informations de débogage pour une application ou une bibliothèque à l'aide de GDB

Les informations de débogage sont nécessaires pour déboguer le code. Pour le code installé à partir d'un paquetage, le débogueur GNU (GDB) reconnaît automatiquement les informations de débogage manquantes, résout le nom du paquetage et fournit des conseils concrets sur la manière d'obtenir le paquetage.

Conditions préalables

Procédure

  1. Lancez GDB attaché à l'application ou à la bibliothèque que vous souhaitez déboguer. GDB reconnaît automatiquement les informations de débogage manquantes et suggère une commande à exécuter.

    $ gdb -q /bin/ls
    Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
    (no debugging symbols found)...done.
    Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
    (gdb)
  2. Quittez GDB : tapez q et confirmez avec Enter.

    (gdb) q
  3. Exécutez la commande suggérée par GDB pour installer les paquets debuginfo requis :

    # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

    L'outil de gestion des paquets dnf fournit un résumé des changements, demande une confirmation et, une fois que vous avez confirmé, télécharge et installe tous les fichiers nécessaires.

  4. Si GDB n'est pas en mesure de suggérer le paquet debuginfo, suivez la procédure décrite dans Obtenir manuellement les paquets debuginfo pour une application ou une bibliothèque.

Chapitre 18. Compter les événements pendant l'exécution d'un processus avec perf stat

Vous pouvez utiliser la commande perf stat pour compter les événements matériels et logiciels pendant l'exécution du processus.

Conditions préalables

18.1. L'objectif de perf stat

La commande perf stat exécute une commande spécifiée, comptabilise les événements matériels et logiciels survenus pendant l'exécution de la commande et génère des statistiques à partir de ces chiffres. Si vous ne spécifiez aucun événement, perf stat comptabilise un ensemble d'événements matériels et logiciels courants.

18.2. Comptage des événements avec perf stat

Vous pouvez utiliser perf stat pour compter les événements matériels et logiciels survenant au cours de l'exécution des commandes et générer des statistiques sur ces comptages. Par défaut, perf stat fonctionne en mode "per-thread".

Conditions préalables

Procédure

  • Comptez les événements.

    • L'exécution de la commande perf stat sans accès root ne comptabilisera que les événements se produisant dans l'espace utilisateur :

      $ perf stat ls

      Exemple 18.1. Sortie de perf stat exécuté sans accès root

      Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos
      
       Performance counter stats for 'ls':
      
                    1.28 msec task-clock:u               #    0.165 CPUs utilized
                       0      context-switches:u         #    0.000 M/sec
                       0      cpu-migrations:u           #    0.000 K/sec
                     104      page-faults:u              #    0.081 M/sec
               1,054,302      cycles:u                   #    0.823 GHz
               1,136,989      instructions:u             #    1.08  insn per cycle
                 228,531      branches:u                 #  178.447 M/sec
                  11,331      branch-misses:u            #    4.96% of all branches
      
             0.007754312 seconds time elapsed
      
             0.000000000 seconds user
             0.007717000 seconds sys

      Comme vous pouvez le voir dans l'exemple précédent, lorsque perf stat s'exécute sans accès root, les noms des événements sont suivis de :u, ce qui indique que ces événements n'ont été comptés que dans l'espace utilisateur.

    • Pour compter les événements de l'espace utilisateur et de l'espace noyau, vous devez disposer d'un accès root lorsque vous exécutez perf stat:

      # perf stat ls

      Exemple 18.2. Résultat de perf stat exécuté avec l'accès root

      Desktop  Documents  Downloads  Music  Pictures  Public  Templates  Videos
      
       Performance counter stats for 'ls':
      
                    3.09 msec task-clock                #    0.119 CPUs utilized
                      18      context-switches          #    0.006 M/sec
                       3      cpu-migrations            #    0.969 K/sec
                     108      page-faults               #    0.035 M/sec
               6,576,004      cycles                    #    2.125 GHz
               5,694,223      instructions              #    0.87  insn per cycle
               1,092,372      branches                  #  352.960 M/sec
                  31,515      branch-misses             #    2.89% of all branches
      
             0.026020043 seconds time elapsed
      
             0.000000000 seconds user
             0.014061000 seconds sys
      • Par défaut, perf stat fonctionne en mode "per-thread". Pour passer au comptage des événements à l'échelle du processeur, passez l'option -a à perf stat. Pour compter les événements à l'échelle du processeur, vous devez disposer d'un accès root :

        # perf stat -a ls

Ressources supplémentaires

  • perf-stat(1) page de manuel

18.3. Interprétation de la sortie de l'état de perf

perf stat exécute une commande spécifiée et compte les occurrences d'événements pendant l'exécution de la commande et affiche les statistiques de ces comptages dans trois colonnes :

  1. Le nombre d'occurrences comptées pour un événement donné
  2. Le nom de l'événement qui a été compté
  3. Lorsque des mesures connexes sont disponibles, un ratio ou un pourcentage est affiché après le signe dièse (#) dans la colonne la plus à droite.

    Par exemple, en mode par défaut, perf stat compte à la fois les cycles et les instructions et, par conséquent, calcule et affiche les instructions par cycle dans la colonne la plus à droite. Vous pouvez observer un comportement similaire en ce qui concerne les échecs de branchements en pourcentage de tous les branchements, puisque les deux événements sont comptés par défaut.

18.4. Attacher le statut de perf à un processus en cours d'exécution

Vous pouvez attacher perf stat à un processus en cours d'exécution. Cela demandera à perf stat de compter les occurrences d'événements uniquement dans les processus spécifiés pendant l'exécution d'une commande.

Conditions préalables

Procédure

  • Attachez perf stat à un processus en cours :

    $ perf stat -p ID1,ID2 sleep seconds

    L'exemple précédent comptabilise les événements dans les processus avec les identifiants ID1 et ID2 pendant une période de seconds secondes, comme indiqué à l'aide de la commande sleep.

Ressources supplémentaires

  • perf-stat(1) page de manuel

Chapitre 19. Enregistrement et analyse des profils de performance avec perf

L'outil perf vous permet d'enregistrer des données sur les performances et de les analyser ultérieurement.

Conditions préalables

19.1. L'objectif de la fiche de perf

La commande perf record échantillonne les données de performance et les stocke dans un fichier, perf.data, qui peut être lu et visualisé avec d'autres commandes perf. perf.data est généré dans le répertoire courant et peut être consulté ultérieurement, éventuellement sur une autre machine.

Si vous ne spécifiez pas de commande pour que perf record enregistre, il enregistrera jusqu'à ce que vous arrêtiez manuellement le processus en appuyant sur Ctrl C. Vous pouvez attacher perf record à des processus spécifiques en passant l'option -p suivie d'un ou plusieurs identifiants de processus. Vous pouvez exécuter perf record sans accès root, mais vous n'obtiendrez alors que des données de performance dans l'espace utilisateur. Dans le mode par défaut, perf record utilise les cycles du processeur comme événement d'échantillonnage et fonctionne en mode per-thread avec le mode inherit activé.

19.2. Enregistrement d'un profil de performance sans accès root

Vous pouvez utiliser perf record sans accès root pour échantillonner et enregistrer des données de performance dans l'espace utilisateur uniquement.

Conditions préalables

Procédure

  • Prélever des échantillons et enregistrer les données de performance :

    enregistrement de la perf command

    Remplacez command par la commande pendant laquelle vous souhaitez échantillonner les données. Si vous ne spécifiez pas de commande, perf record échantillonnera les données jusqu'à ce que vous l'arrêtiez manuellement en appuyant sur la touche Ctrl+C.

Ressources supplémentaires

  • perf-record(1) page de manuel

19.3. Enregistrement d'un profil de performance avec un accès root

Vous pouvez utiliser perf record avec un accès root pour échantillonner et enregistrer des données de performance à la fois dans l'espace utilisateur et dans l'espace noyau.

Conditions préalables

  • L'outil de l'espace utilisateur perf est installé comme décrit dans la section Installation de perf.
  • Vous avez un accès root.

Procédure

  • Prélever des échantillons et enregistrer les données de performance :

    # perf record command

    Remplacez command par la commande pendant laquelle vous souhaitez échantillonner les données. Si vous ne spécifiez pas de commande, perf record échantillonnera les données jusqu'à ce que vous l'arrêtiez manuellement en appuyant sur la touche Ctrl+C.

Ressources supplémentaires

  • perf-record(1) page de manuel

19.4. Enregistrement d'un profil de performance en mode per-CPU

Vous pouvez utiliser perf record en mode per-CPU pour échantillonner et enregistrer des données de performance à la fois dans l'espace utilisateur et dans l'espace noyau simultanément pour tous les threads d'une unité centrale surveillée. Par défaut, le mode per-CPU surveille toutes les unités centrales en ligne.

Conditions préalables

Procédure

  • Prélever des échantillons et enregistrer les données de performance :

    # perf record -a command

    Remplacez command par la commande pendant laquelle vous souhaitez échantillonner les données. Si vous ne spécifiez pas de commande, perf record échantillonnera les données jusqu'à ce que vous l'arrêtiez manuellement en appuyant sur la touche Ctrl+C.

Ressources supplémentaires

  • perf-record(1) page de manuel

19.5. Capturer les données du graphique d'appel avec l'enregistrement des performances

Vous pouvez configurer l'outil perf record de manière à ce qu'il enregistre la fonction qui appelle d'autres fonctions dans le profil de performance. Cela permet d'identifier un goulot d'étranglement si plusieurs processus appellent la même fonction.

Conditions préalables

Procédure

  • L'option --call-graph permet d'échantillonner et d'enregistrer les données de performance :

    $ perf record --call-graph method command
    • Remplacez command par la commande pendant laquelle vous souhaitez échantillonner les données. Si vous ne spécifiez pas de commande, perf record échantillonnera les données jusqu'à ce que vous l'arrêtiez manuellement en appuyant sur la touche Ctrl+C.
    • Remplacer method par l'une des méthodes de déroulement suivantes :

      fp
      Utilise la méthode du pointeur de cadre. En fonction de l'optimisation du compilateur, comme avec les binaires compilés avec l'option GCC --fomit-frame-pointer, ceci peut ne pas être capable de dérouler la pile.
      dwarf
      Utilise les informations du cadre d'appel DWARF pour dérouler la pile.
      lbr
      Utilise le dernier enregistrement de branche sur les processeurs Intel.

Ressources supplémentaires

  • perf-record(1) page de manuel

19.6. Analyse de perf.data avec perf report

Vous pouvez utiliser perf report pour afficher et analyser un fichier perf.data.

Conditions préalables

  • L'outil de l'espace utilisateur perf est installé comme décrit dans la section Installation de perf.
  • Il existe un fichier perf.data dans le répertoire actuel.
  • Si le fichier perf.data a été créé avec un accès root, vous devez également exécuter perf report avec un accès root.

Procédure

  • Affiche le contenu du fichier perf.data pour une analyse plus approfondie :

    # perf report

    Cette commande affiche une sortie similaire à la suivante :

    Samples: 2K of event 'cycles', Event count (approx.): 235462960
    Overhead  Command          Shared Object                     Symbol
       2.36%  kswapd0          [kernel.kallsyms]                 [k] page_vma_mapped_walk
       2.13%  sssd_kcm         libc-2.28.so                      [.] memset_avx2_erms 2.13% perf [kernel.kallsyms] [k] smp_call_function_single 1.53% gnome-shell libc-2.28.so [.] strcmp_avx2
       1.17%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_hash_table_lookup
       0.93%  Xorg             libc-2.28.so                      [.] memmove_avx_unaligned_erms 0.89% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_object_unref 0.87% kswapd0 [kernel.kallsyms] [k] page_referenced_one 0.86% gnome-shell libc-2.28.so [.] memmove_avx_unaligned_erms
       0.83%  Xorg             [kernel.kallsyms]                 [k] alloc_vmap_area
       0.63%  gnome-shell      libglib-2.0.so.0.5600.4           [.] g_slice_alloc
       0.53%  gnome-shell      libgirepository-1.0.so.1.0.0      [.] g_base_info_unref
       0.53%  gnome-shell      ld-2.28.so                        [.] _dl_find_dso_for_object
       0.49%  kswapd0          [kernel.kallsyms]                 [k] vma_interval_tree_iter_next
       0.48%  gnome-shell      libpthread-2.28.so                [.] pthread_getspecific 0.47% gnome-shell libgirepository-1.0.so.1.0.0 [.] 0x0000000000013b1d 0.45% gnome-shell libglib-2.0.so.0.5600.4 [.] g_slice_free1 0.45% gnome-shell libgobject-2.0.so.0.5600.4 [.] g_type_check_instance_is_fundamentally_a 0.44% gnome-shell libc-2.28.so [.] malloc 0.41% swapper [kernel.kallsyms] [k] apic_timer_interrupt 0.40% gnome-shell ld-2.28.so [.] _dl_lookup_symbol_x 0.39% kswapd0 [kernel.kallsyms] [k] raw_callee_save___pv_queued_spin_unlock

Ressources supplémentaires

  • perf-report(1) page de manuel

19.7. Interprétation du rapport de perf

Le tableau affiché par la commande perf report trie les données en plusieurs colonnes :

La colonne "Overhead" (frais généraux)
Indique le pourcentage de l'ensemble des échantillons collectés dans cette fonction particulière.
La colonne "Commande
Indique le processus à partir duquel les échantillons ont été prélevés.
La colonne "Objet partagé
Affiche le nom de l'image ELF d'où proviennent les échantillons (le nom [kernel.kallsyms] est utilisé lorsque les échantillons proviennent du noyau).
La colonne "Symbole
Affiche le nom ou le symbole de la fonction.

En mode par défaut, les fonctions sont triées par ordre décroissant, celles dont les frais généraux sont les plus élevés étant affichées en premier.

19.8. Générer un fichier perf.data lisible sur un autre appareil

Vous pouvez utiliser l'outil perf pour enregistrer des données de performance dans un fichier perf.data qui sera analysé sur un autre appareil.

Conditions préalables

Procédure

  1. Capturez les données de performance que vous souhaitez étudier plus en détail :

    # perf record -a --call-graph fp sleep seconds

    Cet exemple génère une adresse perf.data sur l'ensemble du système pendant une période de quelques secondes, comme indiqué par la commande seconds secondes, comme indiqué par l'utilisation de la commande sleep. Il capture également les données du graphique d'appel à l'aide de la méthode du pointeur de trame.

  2. Générer un fichier d'archive contenant les symboles de débogage des données enregistrées :

    # perf archive

Verification steps

  • Vérifiez que le fichier d'archive a été généré dans votre répertoire actif actuel :

    # ls perf.data*

    La sortie affichera tous les fichiers de votre répertoire actuel qui commencent par perf.data. Le fichier d'archive sera nommé soit :

    perf.data.tar.gz

    ou

    perf.data.tar.bz2

19.9. Analyse d'un fichier perf.data créé sur un autre appareil

Vous pouvez utiliser l'outil perf pour analyser un fichier perf.data généré sur un autre appareil.

Conditions préalables

  • L'outil de l'espace utilisateur perf est installé comme décrit dans la section Installation de perf.
  • Un fichier perf.data et un fichier d'archive associé, générés sur un autre appareil, sont présents sur l'appareil actuellement utilisé.

Procédure

  1. Copiez le fichier perf.data et le fichier d'archive dans votre répertoire actif actuel.
  2. Extraire le fichier d'archive dans ~/.debug:

    # mkdir -p ~/.debug
    # tar xf perf.data.tar.bz2 -C ~/.debug
    Note

    Le fichier d'archive peut également être nommé perf.data.tar.gz.

  3. Ouvrez le fichier perf.data pour une analyse plus approfondie :

    # perf report

19.10. Pourquoi perf affiche-t-il certains noms de fonctions comme des adresses de fonctions brutes ?

Pour les fonctions du noyau, perf utilise les informations du fichier /proc/kallsyms pour faire correspondre les échantillons à leurs noms de fonction ou symboles respectifs. Pour les fonctions exécutées dans l'espace utilisateur, cependant, vous pouvez voir des adresses de fonctions brutes parce que le binaire est dépouillé.

Le paquet debuginfo de l'exécutable doit être installé ou, si l'exécutable est une application développée localement, l'application doit être compilée avec les informations de débogage activées (l'option -g dans GCC) pour afficher les noms de fonction ou les symboles dans une telle situation.

Note

Il n'est pas nécessaire de réexécuter la commande perf record après avoir installé la commande debuginfo associée à un exécutable. Il suffit de réexécuter la commande perf report.

19.11. Activation des dépôts de débogage et de sources

Une installation standard de Red Hat Enterprise Linux n'active pas les référentiels de débogage et de sources. Ces référentiels contiennent des informations nécessaires pour déboguer les composants du système et mesurer leurs performances.

Procédure

  • Activez les canaux du paquet d'informations de source et de débogage : La partie $(uname -i) est automatiquement remplacée par une valeur correspondant à l'architecture de votre système :

    Nom de l'architectureValeur

    64-bit Intel et AMD

    x86_64

    aRM 64 bits

    aarch64

    IBM POWER

    ppc64le

    iBM Z 64 bits

    s390x

19.12. Obtenir les paquets d'informations de débogage pour une application ou une bibliothèque à l'aide de GDB

Les informations de débogage sont nécessaires pour déboguer le code. Pour le code installé à partir d'un paquetage, le débogueur GNU (GDB) reconnaît automatiquement les informations de débogage manquantes, résout le nom du paquetage et fournit des conseils concrets sur la manière d'obtenir le paquetage.

Conditions préalables

Procédure

  1. Lancez GDB attaché à l'application ou à la bibliothèque que vous souhaitez déboguer. GDB reconnaît automatiquement les informations de débogage manquantes et suggère une commande à exécuter.

    $ gdb -q /bin/ls
    Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
    (no debugging symbols found)...done.
    Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
    (gdb)
  2. Quittez GDB : tapez q et confirmez avec Enter.

    (gdb) q
  3. Exécutez la commande suggérée par GDB pour installer les paquets debuginfo requis :

    # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

    L'outil de gestion des paquets dnf fournit un résumé des changements, demande une confirmation et, une fois que vous avez confirmé, télécharge et installe tous les fichiers nécessaires.

  4. Si GDB n'est pas en mesure de suggérer le paquet debuginfo, suivez la procédure décrite dans Obtenir manuellement les paquets debuginfo pour une application ou une bibliothèque.

Chapitre 20. Étudier les unités centrales occupées à l'aide de la perf

Lorsque vous étudiez les problèmes de performance d'un système, vous pouvez utiliser l'outil perf pour identifier et surveiller les unités centrales les plus occupées afin de concentrer vos efforts.

20.1. Affichage des événements de l'unité centrale qui ont été comptabilisés avec perf stat

Vous pouvez utiliser perf stat pour afficher les événements CPU qui ont été comptés en désactivant l'agrégation du comptage CPU. Vous devez compter les événements en mode système en utilisant l'indicateur -a afin d'utiliser cette fonctionnalité.

Conditions préalables

Procédure

  • Compter les événements avec l'agrégation du nombre de CPU désactivée :

    # perf stat -a -A sleep seconds

    L'exemple précédent affiche les décomptes d'un ensemble par défaut d'événements matériels et logiciels courants enregistrés sur une période de seconds secondes, comme l'indique la commande sleep, sur chaque unité centrale par ordre croissant, en commençant par CPU0. Il peut donc être utile de spécifier un événement tel que les cycles :

    # perf stat -a -A -e cycles sleep seconds

20.2. Affichage de l'unité centrale sur laquelle les échantillons ont été prélevés avec le rapport de perf

La commande p