Optimisation des Performances Système RHEL avec Tuned, Nice et Renice

Introduction

Dans ce laboratoire, vous apprendrez à optimiser les performances du système RHEL en utilisant tuned et à gérer les priorités des processus avec nice et renice. Vous commencerez par vérifier l'installation de tuned et lister les profils disponibles, puis observerez comment la modification des profils tuned impacte les paramètres du système.

Le laboratoire vous guidera à travers le démarrage et la surveillance de processus gourmands en CPU, suivi de l'ajustement de leurs priorités en utilisant nice et renice afin de comprendre leur effet sur l'allocation des ressources. Enfin, vous apprendrez à nettoyer les processus en cours d'exécution, assurant ainsi une compréhension complète de l'optimisation des performances sur RHEL.

Vérifier l'état de tuned et lister les profils disponibles

Dans cette étape, vous apprendrez à vérifier l'état du démon tuned et à lister les profils de réglage disponibles sur votre système RHEL. tuned est un démon de réglage de système adaptatif et dynamique qui ajuste les paramètres du système pour optimiser les performances pour des charges de travail spécifiques. Il utilise des profils de réglage pour appliquer un ensemble de paramètres à l'échelle du système.

Vérifiez que le démon tuned est en cours d'exécution.
Dans cet environnement de conteneur, nous vérifierons si le démon tuned est en cours d'exécution en recherchant son processus. Nous pouvons également vérifier sa fonctionnalité en vérifiant s'il répond aux commandes.

Tout d'abord, vérifiez si le processus tuned est en cours d'exécution :
```
pgrep tuned
```
Si tuned est en cours d'exécution, cette commande renverra son ID de processus (PID). Si aucun PID n'est renvoyé, vous pouvez démarrer le démon manuellement :
```
sudo /usr/sbin/tuned &
```
Ensuite, vérifiez qu'il est en cours d'exécution :
```
pgrep tuned
```
Vous devriez voir une sortie similaire à :
```
739
```
(Remarque : La valeur du PID dans votre sortie variera.)

De plus, vous pouvez vérifier que tuned est fonctionnel en vérifiant s'il répond aux requêtes d'état :
```
sudo tuned-adm active
```
Cela devrait renvoyer le profil actuellement actif sans erreurs.

Lister les profils de réglage disponibles et identifier le profil actif.
La commande tuned-adm list affiche tous les profils de réglage disponibles et met en évidence celui qui est actuellement actif.

sudo tuned-adm list

Vous serez invité à entrer votre mot de passe. Notez le Current active profile dans la sortie.

Available profiles:
- accelerator-performance     - Throughput performance based tuning with disabled higher latency STOP states
- aws                         - Optimize for aws ec2 instances
- balanced                    - General non-specialized tuned profile
- balanced-battery            - Balanced profile biased towards power savings changes for battery
- desktop                     - Optimize for the desktop use-case
- hpc-compute                 - Optimize for HPC compute workloads
- intel-sst                   - Configure for Intel Speed Select Base Frequency
- 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
- optimize-serial-console     - Optimize for serial console use.
- 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: virtual-guest

Examiner la configuration du profil virtual-guest.
Le profil virtual-guest est souvent le profil par défaut pour les machines virtuelles. Vous pouvez inspecter son fichier de configuration pour comprendre quels paramètres il applique.

cat /usr/lib/tuned/virtual-guest/tuned.conf

Cette commande affiche la configuration tuned pour le profil virtual-guest, y compris les paramètres qu'il hérite d'autres profils.

#
## tuned configuration
#

[main]
summary=Optimize for running inside a virtual guest
include=throughput-performance

[vm]
## If a workload mostly uses anonymous memory and it hits this limit, the entire
## working set is buffered for I/O, and any more write buffering would require
## swapping, so it's time to throttle writes until I/O can catch up.  Workloads
## that mostly use file mappings may be able to use even higher values.
#
## The generator of dirty data starts writeback at this percentage (system default
## is 20%)
dirty_ratio = 30

[sysctl]
## Filesystem I/O is usually much more efficient than swapping, so try to keep
## swapping low.  It's usually safe to go even lower than this on systems with
## server-grade storage.
vm.swappiness = 30

Vérifier que le paramètre vm.dirty_background_ratio est appliqué.
Le profil virtual-guest inclut throughput-performance. Vérifions un paramètre que throughput-performance définit généralement, tel que vm.dirty_background_ratio. Ce paramètre contrôle quand le système commence à écrire des pages sales sur le disque en arrière-plan.
```
sysctl vm.dirty_background_ratio
```
La sortie affichera la valeur actuelle de ce paramètre du noyau.
```
vm.dirty_background_ratio = 10
```

Changer de profil tuned et observer les changements des paramètres système

Dans cette étape, vous apprendrez à changer le profil tuned actif et à observer les effets immédiats sur les paramètres du système. Changer un profil tuned vous permet d'appliquer rapidement un ensemble d'optimisations de performances adaptées à différentes charges de travail, telles que les tâches intensives en débit ou l'économie d'énergie.

Changer le profil de réglage actif actuel en throughput-performance.
Le profil throughput-performance est conçu pour les systèmes qui nécessitent un débit élevé, souvent en sacrifiant une certaine latence. Il optimise généralement les E/S disque et les performances réseau. Utilisez la commande tuned-adm profile pour changer de profil.
```
sudo tuned-adm profile throughput-performance
```
Vous serez invité à entrer votre mot de passe.
```
$ sudo tuned-adm profile throughput-performance
[sudo] password for user:
```
Confirmer le nouveau profil actif.
Après avoir changé de profil, il est de bonne pratique de vérifier que le nouveau profil est bien actif. Vous pouvez le faire en utilisant tuned-adm active.
```
sudo tuned-adm active
```
La sortie devrait maintenant afficher throughput-performance comme profil actif.
```
Current active profile: throughput-performance
```
Vérifier que les paramètres vm.dirty_ratio et vm.swappiness ont changé.
Le profil throughput-performance modifie les paramètres du noyau liés à la gestion de la mémoire, tels que vm.dirty_ratio et vm.swappiness. Même si le profil virtual-guest hérite de throughput-performance, le passage direct au profil throughput-performance applique les valeurs de base sans les modifications spécifiques à virtual-guest.
- vm.dirty_ratio : Ce paramètre définit le pourcentage maximal de la mémoire système qui peut être rempli avec des pages sales (pages qui ont été modifiées mais pas encore écrites sur le disque) avant que le système ne commence à les écrire sur le disque. Une valeur plus élevée peut améliorer le débit en permettant de mettre plus de données en mémoire tampon.
- vm.swappiness : Ce paramètre contrôle la manière dont le noyau échange agressivement la mémoire anonyme (données d'application) de la RAM vers l'espace d'échange. Une valeur plus faible signifie que le noyau essaiera de conserver plus de données d'application dans la RAM, ce qui est généralement meilleur pour les performances.
Vérifions leurs valeurs actuelles en utilisant sysctl.
```
sysctl vm.dirty_ratio
sysctl vm.swappiness
```
Vous devriez observer que les valeurs ont changé par rapport aux paramètres du profil virtual-guest (dirty_ratio = 30, vm.swappiness = 30) aux valeurs de base du profil throughput-performance :
```
vm.dirty_ratio = 40
vm.swappiness = 10
```
(Remarque : Ces valeurs reflètent les optimisations de base de throughput-performance sans les modifications spécifiques à virtual-guest.)

Démarrer et surveiller les processus gourmands en CPU sur RHEL

Dans cette étape, vous apprendrez à démarrer des processus intensifs en CPU et à surveiller leur utilisation des ressources. Ceci est crucial pour comprendre comment les processus consomment les ressources du système et comment identifier les goulots d'étranglement. Nous utiliserons la commande sha1sum /dev/zero, qui calcule en continu la somme de contrôle SHA1 d'un flux infini de zéros, consommant ainsi efficacement des cycles CPU.

Important : Cet exercice utilise des commandes qui effectuent des sommes de contrôle infinies sur un fichier de périphérique, consommant intentionnellement des ressources CPU importantes. Vous devez terminer tous les processus de l'exercice avant de quitter cet exercice ou de passer au prochain lab.

Déterminer le nombre de cœurs CPU sur votre système.
Comprendre le nombre de cœurs CPU vous aide à décider combien de processus intensifs en CPU exécuter pour utiliser pleinement le système. Vous pouvez trouver cette information dans /proc/cpuinfo.
```
grep -c '^processor' /proc/cpuinfo
```
Cette commande compte le nombre de lignes qui commencent par processor, ce qui correspond au nombre de cœurs CPU logiques (ou processeurs virtuels).
```
2
```
(Remarque : Votre sortie peut afficher un nombre différent de cœurs en fonction de la configuration du système.)
Démarrer deux instances de la commande sha1sum /dev/zero & pour chaque cœur CPU.
Pour simuler un système fortement chargé, nous allons démarrer plusieurs instances de sha1sum /dev/zero &. Le & à la fin de la commande exécute le processus en arrière-plan, vous permettant de continuer à utiliser le terminal. Par exemple, si vous avez 2 cœurs CPU, vous démarrerez 4 instances (2 instances/cœur * 2 cœurs).
```
for i in $(seq 1 $(grep -c '^processor' /proc/cpuinfo | awk '{print $1 * 2}')); do sha1sum /dev/zero & done
```
Cette commande calcule dynamiquement le nombre de processus à démarrer en fonction du nombre de cœurs de votre CPU.
```
[1] 1234
[2] 1235
[3] 1236
[4] 1237
```
(Remarque : Les valeurs PID dans votre sortie varieront de l'exemple.)
Vérifier que les tâches en arrière-plan sont en cours d'exécution.
La commande jobs liste tous les processus actuellement en cours d'exécution en arrière-plan depuis votre session shell.
```
jobs
```
Vous devriez voir une liste des processus sha1sum que vous venez de démarrer.
```
[1]   Running                 sha1sum /dev/zero &
[2]   Running                 sha1sum /dev/zero &
[3]   Running                 sha1sum /dev/zero &
[4]-  Running                 sha1sum /dev/zero &
```
Utiliser les commandes ps et pgrep pour afficher le pourcentage d'utilisation du CPU pour chaque processus sha1sum.
La commande ps rapporte un instantané des processus en cours. Nous allons la combiner avec pgrep pour filtrer les processus sha1sum.
- ps -o pid,pcpu,nice,comm : Ceci spécifie le format de sortie : ID de processus (pid), pourcentage d'utilisation du CPU (pcpu), valeur nice (nice) et nom de la commande (comm).
- $(pgrep sha1sum) : Cette substitution de commande trouve les PID de tous les processus nommés sha1sum et les transmet comme arguments à ps.
```
ps -o pid,pcpu,nice,comm $(pgrep sha1sum)
```
Vous devriez voir chaque processus sha1sum consommer un pourcentage significatif du CPU.
```
    PID %CPU  NI COMMAND
   5248 48.8   0 sha1sum
   5249 48.7   0 sha1sum
   5250 48.8   0 sha1sum
   5251 48.8   0 sha1sum
```
(Remarque : Les valeurs %CPU peuvent fluctuer mais devraient être élevées, indiquant une forte utilisation du CPU. La colonne NI affiche la valeur nice.)
Terminer tous les processus sha1sum en cours d'exécution et vérifier qu'il n'en reste aucun.
Il est crucial de nettoyer ces processus intensifs en CPU avant de continuer. La commande pkill termine les processus en fonction de leur nom.
```
pkill sha1sum
```
Maintenant, vérifiez qu'aucune tâche sha1sum n'est en cours d'exécution en arrière-plan.
```
jobs
```
La sortie devrait être vide, ou indiquer que toutes les tâches sont terminées.
```
[1]   Terminated              sha1sum /dev/zero
[2]   Terminated              sha1sum /dev/zero
[3]   Terminated              sha1sum /dev/zero
[4]-  Terminated              sha1sum /dev/zero
```
(Remarque : Vous pourriez voir des messages "Terminated", ce qui est attendu car les processus sont en cours d'arrêt.)

Ajuster la priorité des processus avec nice et renice sur RHEL

Dans cette étape, vous apprendrez à influencer la priorité de planification des processus en utilisant les commandes nice et renice. La valeur nice (également connue sous le nom de niceness) d'un processus indique sa priorité pour le planificateur Linux. Une valeur nice plus faible (plus négative) signifie une priorité plus élevée, tandis qu'une valeur nice plus élevée (plus positive) signifie une priorité plus faible. La plage des valeurs nice est généralement de -20 (priorité la plus élevée) à 19 (priorité la plus faible), 0 étant la valeur par défaut.

Démarrer plusieurs instances de sha1sum /dev/zero & puis démarrer une instance supplémentaire avec un niveau nice de 10.
Nous allons démarrer plusieurs processus sha1sum pour simuler un système occupé. Ensuite, nous en démarrerons un avec une priorité délibérément plus faible (valeur nice plus élevée) pour observer l'effet.

Tout d'abord, démarrez trois instances régulières (ajustez-les en fonction du nombre de cœurs de votre CPU si vous le souhaitez, mais au moins autant que de processeurs virtuels pour créer une contention) :
```
for i in {1..3}; do sha1sum /dev/zero & done
```
Ensuite, démarrez la quatrième instance avec un niveau nice de 10. Ce processus aura une priorité plus faible par rapport aux autres.
```
nice -n 10 sha1sum /dev/zero &
```
Vous verrez une sortie similaire à celle-ci, indiquant les PID des processus en arrière-plan :
```
[1] 5443
[2] 5444
[3] 5445
[4] 5446
```
(Remarque : Les valeurs PID dans votre sortie varieront.)
Utiliser les commandes ps et pgrep pour afficher le PID, le pourcentage d'utilisation du CPU, la valeur nice et le nom de l'exécutable pour chaque processus.
Observez les colonnes %CPU et NI. L'instance avec la valeur nice de 10 devrait afficher un pourcentage d'utilisation du CPU inférieur à celui des autres instances, car le planificateur lui accorde moins de temps CPU.
```
ps -o pid,pcpu,nice,comm $(pgrep sha1sum)
```
Recherchez le processus avec la valeur NI de 10. Son %CPU devrait être sensiblement inférieur à celui des autres.
```
    PID %CPU  NI COMMAND
   5443 56.8   0 sha1sum
   5444 58.0   0 sha1sum
   5445 56.5   0 sha1sum
   5446  6.7  10 sha1sum
```
(Remarque : Les valeurs %CPU exactes varieront en fonction de la charge du système et du nombre de cœurs, mais le processus avec nice 10 devrait avoir une part plus faible.)
Utiliser la commande sudo renice pour modifier le niveau nice de l'un des processus réguliers à 5.
La commande renice vous permet de modifier la valeur nice d'un processus déjà en cours d'exécution. Nous allons le démontrer en modifiant l'un des processus réguliers (valeur nice 0) à une valeur nice de 5.

Tout d'abord, identifiez le PID de l'un des processus sha1sum qui a une valeur nice de 0 à partir de la sortie de la commande ps précédente. Utilisons le premier de l'exemple ci-dessus (PID 5443).
```
sudo renice -n 5 <PID_of_regular_process>
```
Remplacez <PID_of_regular_process> par le PID réel que vous avez identifié. Par exemple :
```
sudo renice -n 5 5443
```
Vous devriez voir une sortie confirmant le changement de priorité :
```
5443 (process ID) old priority 0, new priority 5
```
Répéter les commandes ps et pgrep pour afficher le pourcentage d'utilisation du CPU et le niveau nice.
Observez le changement d'utilisation du CPU pour le processus dont vous avez modifié la valeur nice. Le processus avec la valeur nice 5 devrait maintenant avoir une utilisation du CPU légèrement inférieure à celle des processus avec la valeur nice 0, mais supérieure à celle du processus avec la valeur nice 10.
```
ps -o pid,pcpu,nice,comm $(pgrep sha1sum)
```
Vous devriez voir que la valeur NI pour le processus modifié est maintenant 5, et son utilisation du CPU reflète son nouveau niveau de priorité.
```
    PID %CPU  NI COMMAND
   5443 55.4   5 sha1sum
   5444 67.2   0 sha1sum
   5445 67.1   0 sha1sum
   5446  7.5  10 sha1sum
```
(Remarque : Les valeurs %CPU exactes varieront, mais vous devriez observer que les processus avec des valeurs nice plus faibles (priorité plus élevée) obtiennent plus de temps CPU.)

Nettoyer les processus en cours d'exécution

Dans cette dernière étape, vous vous assurerez que tous les processus en arrière-plan démarrés pendant le lab sont correctement terminés. Il s'agit d'une étape de nettoyage essentielle pour éviter une consommation de ressources involontaire et garantir que l'environnement du lab est réinitialisé pour une utilisation future.

Utiliser la commande pkill pour terminer tous les processus en cours d'exécution avec le motif de nom sha1sum.
La commande pkill est un moyen efficace d'envoyer un signal (par défaut, SIGTERM) aux processus en fonction de leur nom. Cela arrêtera tous les processus sha1sum que vous avez démarrés dans les étapes précédentes.
```
pkill sha1sum
```
Vous pourriez voir des messages indiquant que des processus ont été terminés.
```
[3]-  Terminated              sha1sum /dev/zero
[2]-  Terminated              sha1sum /dev/zero
[4]+  Terminated              nice -n 10 sha1sum /dev/zero
[1]+  Terminated              sha1sum /dev/zero
```
Vérifier qu'aucun processus sha1sum n'est encore en cours d'exécution.
Vous pouvez utiliser pgrep pour vérifier si des processus sha1sum sont encore actifs. Si pgrep ne renvoie aucune sortie, cela signifie qu'aucun de ces processus n'est en cours d'exécution.
```
pgrep sha1sum
```
Cette commande ne devrait renvoyer aucune sortie, indiquant que tous les processus sha1sum ont été terminés avec succès.
```
$ pgrep sha1sum
$
```

Résumé

Dans ce lab, nous avons appris à gérer et à utiliser tuned pour l'optimisation des performances du système sur RHEL. Nous avons commencé par vérifier l'installation et l'état du service tuned et en listant les profils de réglage disponibles, en comprenant que tuned adapte dynamiquement les paramètres du système pour des charges de travail spécifiques en utilisant ces profils. Nous avons ensuite pratiqué la connexion à un environnement servera simulé via SSH en tant qu'utilisateur labex et confirmé l'installation du paquet tuned en utilisant dnf list tuned.

Le lab nous a ensuite guidés à travers le changement des profils tuned pour observer leur impact sur les paramètres du système, démontrant comment différents profils peuvent modifier le comportement du système. Nous avons également acquis une expérience pratique dans le démarrage et la surveillance des processus gourmands en CPU, ce qui est crucial pour identifier les goulots d'étranglement des performances. Enfin, nous avons appris à ajuster les priorités des processus en utilisant les commandes nice et renice pour gérer efficacement l'allocation des ressources, et nous avons conclu en nettoyant les processus en cours d'exécution pour restaurer le système à son état initial.

Optimiser les Performances Système sous RHEL