Improving performance (Français)

From ArchWiki
État de la traduction: Cet article est la version francophone de Improving performance. Date de la dernière traduction: 2022-03-26. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

Related articles

Cet article fournit des informations sur les diagnostics de base d'un système en matière de performances, ainsi que sur les mesures qui peuvent être prises pour réduire la consommation de ressources ou pour optimiser le système, l'objectif final étant d'améliorer les performances du système de manière ressentie ou mesurable.

Les bases

Connaissez votre système

La meilleure façon de régler un système est de cibler les goulots d'étranglement ou les sous-systèmes qui limitent la vitesse globale. Les spécifications du système peuvent aider à les identifier.

  • Si l'ordinateur devient lent lorsque de grosses applications (comme LibreOffice et Firefox) tournent en même temps, vérifiez si la quantité de RAM est suffisante. Utilisez la commande suivante, et vérifiez la colonne "disponible" : 
    $ free -h
  • Si le temps de démarrage est lent et que les applications prennent beaucoup de temps à se charger au premier lancement (seulement), le disque dur est probablement en cause. La vitesse d'un disque dur peut être mesurée à l'aide de la commande hdparm : 
    # hdparm -t /dev/sdX
    Note: hdparm indique uniquement la vitesse de lecture pure d'un disque dur et ne constitue pas un point de référence valide. Une valeur supérieure à 40MB/s (en veille) est cependant acceptable sur un système moyen.
  • Si la charge du CPU est constamment élevée même avec suffisamment de RAM disponible, essayez de réduire l'utilisation du CPU en désactivant les daemons et/ou les processus en cours d'exécution. Ceci peut être contrôlé de plusieurs façons, par exemple avec htop, pstree ou tout autre outil de surveillance système : 
    $ htop
  • Si les applications utilisant le rendu direct sont lentes (c'est-à-dire celles qui utilisent le GPU, comme les lecteurs vidéo, les jeux, ou même un gestionnaire de fenêtres), l'amélioration des performances du GPU devrait aider. La première étape consiste à vérifier si le rendu direct est réellement activé. Ceci est indiqué par la commande glxinfo, qui fait partie du paquet mesa-utils, qui devrait renvoyer direct rendering : Yes lorsqu'elle est utilisée : 
    $ glxinfo | grep "direct rendering"
  • Lorsque vous utilisez un environnement de bureau, la désactivation des effets visuels de bureau (non utilisés) peut réduire l'utilisation du GPU. Utilisez un environnement plus léger ou créez un environnement sur mesure si l'actuel ne répond pas aux exigences matérielles et/ou personnelles.

Analyse comparative

Les effets de l'optimisation sont souvent difficiles à juger. Ils peuvent cependant être mesurés par des outils de benchmarking.

Périphériques de stockage

Chemins d'accès matériels multiples

Un chemin matériel interne décrit comment le périphérique de stockage est connecté à travers votre carte mère. Il existe différentes façons de se connecter à travers la carte mère, comme la carte d'interface réseau, PCIe, Firewire, carte Raid, USB, etc. En répartissant vos périphériques de stockage sur plusieurs points de connexion, vous pouvez éviter les goulots d'étranglement. En effet, chaque "voie d'entrée" dans la carte mère est "comme un tuyau", et il y a une limite à la quantité de données qui peut passer par ce tuyau à un même moment. Ce problème peut être évité car les cartes mères ont généralement plusieurs "tuyaux".

Un exemple concret de ceci serait si vous avez deux ports USB à l'avant de votre machine, quatre ports USB à l'arrière, et quatre disques : il sera généralement plus rapide de connecter deux disques à l'avant et deux à l'arrière plutôt que trois à l'arrière et un à l'avant. En effet, la plupart du temps, les ports avant et arrière sont connectés en interne à des concentrateurs USB racine distincts, ce qui signifie que vous pouvez envoyer plus de données en même temps en utilisant les deux au lieu d'un.

Les commandes suivantes vous aideront à déterminer les différents chemins sur votre machine. 

USB Device Tree
$ lsusb -t
PCI Device Tree
$ lspci -tv

Partitionnement

Assurez-vous que vos partitions sont correctement alignées.

Disques multiples

Si vous disposez de plusieurs disques, vous pouvez les configurer en RAID logiciel pour améliorer considérablement la vitesse.

La création d'un swap sur un disque séparé peut également être d'une grande aide, surtout si votre machine en fait fréquemment usage.

Disposition sur les disques durs

Si vous utilisez un disque dur rotatif traditionnel, la disposition de vos partitions peut influencer les performances du système. Les secteurs situés au début du disque (plus près de l'extérieur du disque) sont plus rapides que ceux situés à la fin. En outre, une partition plus petite nécessite moins de mouvements de la tête du disque, ce qui accélère les opérations du disque. Il est donc conseillé de créer une petite partition (10 Go, plus ou moins selon vos besoins) uniquement pour votre système, le plus près possible du début du disque. Les autres données (photos, vidéos) devraient être conservées sur une partition séparée, et ceci est généralement réalisé en séparant le répertoire personnel (/home/user) du système (/).

Choix et réglage de votre système de fichiers

Le choix du meilleur système de fichiers pour un système spécifique est très important car chacun a ses propres forces. L'article File systems fournit un bref résumé des systèmes les plus populaires. Vous pouvez également trouver des articles pertinents dans Category:File systems (Français).

Options de montage

L'option noatime est connue pour améliorer les performances du système de fichiers.

Les autres options de montage sont spécifiques au système de fichiers, consultez donc les articles pertinents pour les systèmes de fichiers :

Reiserfs

L'option de montage data=writeback améliore la vitesse, mais peut corrompre les données en cas de coupure de courant. L'option de montage notail augmente l'espace utilisé par le système de fichiers d'environ 5 %, mais améliore également la vitesse globale. Vous pouvez également réduire la charge du disque en plaçant le journal et les données sur des lecteurs séparés. Ceci est fait lors de la création du système de fichiers : 

# mkreiserfs -j /dev/sda1' /dev/sd'b1'

Remplacez /dev/sda1 par la partition réservée au journal, et /dev/sdb1 par la partition pour les données. Vous pouvez en apprendre plus sur reiserfs avec Guide du système de fichiers Funtoo.

Réglage des paramètres du noyau

Il existe plusieurs paramètres clés affectant les performances des périphériques de bloc, consultez Sysctl#Virtual memory pour plus d'informations.

Ordonnancements d'entrée/sortie

Informations de base

L'ordonnanceur d'entrée/sortie (E/S) est le composant du noyau qui décide de l'ordre dans lequel les opérations d'E/S en bloc sont soumises aux périphériques de stockage. Il est utile de rappeler ici quelques spécifications des deux principaux types de disques, car l'objectif de l'ordonnanceur d'E/S est d'optimiser la façon dont ceux-ci sont capables de traiter les demandes de lecture :

  • Un disque dur possède des disques tournants et une tête qui se déplace physiquement à l'endroit requis. Par conséquent, la latence aléatoire est assez élevée, variant entre 3 et 12 ms (qu'il s'agisse d'un disque de serveur haut de gamme ou d'un disque d'ordinateur portable et qu'il contourne le tampon d'écriture du contrôleur de disque), tandis que l'accès séquentiel offre un débit beaucoup plus élevé. Le débit typique d'un disque dur est d'environ 200 opérations E/S par seconde (IOPS).
  • Un SSD n'a pas de pièces mobiles, l'accès aléatoire est aussi rapide que l'accès séquentiel, généralement moins de 0,1 ms, et il peut gérer plusieurs demandes simultanées. Le débit typique d'un SSD est supérieur à 10 000 IOPS, ce qui est plus que nécessaire dans les situations de charge de travail courantes.

Si de nombreux processus effectuent des demandes d'E/S vers différents éléments de stockage, des milliers d'IOPS peuvent être générés alors qu'un disque dur typique ne peut gérer qu'environ 200 IOPS. Il y a une file d'attente de demandes qui doivent attendre l'accès au stockage. C'est là que les ordonnanceurs d'E/S jouent un rôle d'optimisation.

Les algorithmes d'ordonnancement

Une façon d'améliorer le débit est de linéariser l'accès : en classant les demandes en attente par leur adresse logique et en regroupant les plus proches. Historiquement, il s'agissait du premier ordonnanceur d'E/S de Linux appelé elevator.

L'un des problèmes de l'algorithme Elevator est qu'il n'est pas optimal pour un processus effectuant un accès séquentiel : lecture d'un bloc de données, traitement pendant plusieurs microsecondes puis lecture du bloc suivant et ainsi de suite. Le planificateur de l'ascenseur ne sait pas que le processus est sur le point de lire un autre bloc à proximité et, par conséquent, se déplace vers une autre demande par un autre processus à un autre endroit. L'ordonnanceur d'E/S anticipatory L'ordonnanceur d'E/S surmonte le problème : il fait une pause de quelques millisecondes en anticipant une autre opération de lecture à proximité avant de traiter une autre demande.

Bien que ces ordonnanceurs tentent d'améliorer le débit total, ils peuvent laisser certaines demandes malchanceuses en attente pendant un temps très long. À titre d'exemple, imaginons que la majorité des processus effectuent des demandes au début de l'espace de stockage alors qu'un processus malchanceux effectue une demande à l'autre extrémité du stockage. Ce report potentiellement infini du processus est appelé famine. Pour améliorer l'équité, l'algorithme deadline a été développé. Il dispose d'une file d'attente ordonnée par adresse, comme l'ascenseur, mais si une requête reste trop longtemps dans cette file, elle est déplacée vers une file d'attente "expirée" ordonnée par le temps d'expiration. L'ordonnanceur vérifie d'abord la file d'attente expirée et traite les demandes à partir de celle-ci, puis passe à la file d'attente de l'ascenseur. Notez que cette équité a un impact négatif sur le débit global.

La Completely Fair Queuing (CFQ) approche le problème différemment en allouant un tranche de temps (timeslice) et un nombre de requêtes autorisées par file d'attente en fonction de la priorité du processus qui les soumet. Elle prend en charge les cgroups qui permet de réserver une certaine quantité d'E/S à une collection spécifique de processus. C'est particulièrement utile pour l'hébergement mutualisé et en nuage : les utilisateurs qui ont payé pour un certain nombre d'IOPS veulent obtenir leur part quand ils en ont besoin. De plus, il tourne au ralenti à la fin d'une E/S synchrone en attendant d'autres opérations proches, reprenant cette fonctionnalité de l'ordonnanceur anticipatif et apportant quelques améliorations. Les ordonnanceurs "anticipatif" et "élévateur" ont été retirés du noyau Linux et remplacés par les alternatives plus avancées présentées ci-dessous.

Le Budget Fair Queuing (BFQ) est basé sur le code CFQ et apporte quelques améliorations. Il n'accorde pas le disque à chaque processus pour une tranche de temps fixe mais attribue un "budget" mesuré en nombre de secteurs au processus et utilise des heuristiques. Il s'agit d'un ordonnanceur relativement complexe, qui peut être plus adapté aux disques rotatifs et aux SSD lents, car sa surcharge élevée par opération, surtout si elle est associée à un CPU lent, peut ralentir les dispositifs rapides. L'objectif de BFQ sur les systèmes personnels est que, pour les tâches interactives, le périphérique de stockage soit pratiquement aussi réactif que s'il était inactif. Dans sa configuration par défaut, il s'efforce de fournir la latence la plus faible possible plutôt que d'atteindre le débit maximal.

Kyber est un ordonnanceur récent inspiré des techniques de gestion active des files d'attente utilisées pour le routage réseau. L'implémentation est basée sur des "jetons" qui servent de mécanisme pour limiter les demandes. Un jeton de mise en file d'attente est nécessaire pour allouer une demande, il est utilisé pour empêcher la famine des demandes. Un jeton de répartition est également nécessaire et limite les opérations d'une certaine priorité sur un dispositif donné. Enfin, une latence de lecture cible est définie et l'ordonnanceur s'adapte pour atteindre cet objectif de latence. L'implémentation de l'algorithme est relativement simple et il est jugé efficace pour les périphériques rapides.

Les ordonnanceurs d'E/S du noyau

Bien que certains des premiers algorithmes aient été mis hors service, le noyau Linux officiel prend en charge un certain nombre d'ordonnanceurs d'E/S qui peuvent être divisés en deux catégories :

  • Les ordonnanceurs multi-queues sont disponibles par défaut avec le noyau. Le Multi-Queueue Block I/O Queuing Mechanism (blk-mq) fait correspondre les requêtes d'E/S à des files d'attente multiples, les tâches étant réparties entre les threads et donc les cœurs de CPU. Dans ce cadre, les ordonnanceurs suivants sont disponibles :
    • None, où aucun algorithme de mise en file d'attente n'est appliqué.
    • mq-deadline, l'adaptation de l'ordonnanceur deadline (voir ci-dessous) au multi-threading.
    • Kyber
    • BFQ
  • Les single-queue schedulers sont des schedulers historiques :
    • NOOP est l'ordonnanceur le plus simple, il insère toutes les demandes d'E/S entrantes dans une simple file FIFO et implémente la fusion des demandes. Dans cet algorithme, il n'y a pas de réordonnancement de la demande basé sur le numéro de secteur. Il peut donc être utilisé si l'ordonnancement est traité à une autre couche, au niveau du périphérique par exemple, ou si cela n'a pas d'importance, pour les SSD par exemple.
    • Deadline
    • CFQ
Note: Les ordonnanceurs à file unique ont été supprimés du noyau depuis Linux 5.0.

Changement d'ordonnanceur d'E/S

Note: Le meilleur choix d'ordonnanceur dépend à la fois du périphérique et de la nature exacte de la charge de travail. De plus, le débit en Mo/s n'est pas la seule mesure des performances : les délais ou l'équité détériorent le débit global mais peuvent améliorer la réactivité du système. Le Benchmarking peut être utile pour indiquer les performances de chaque ordonnanceur d'E/S.

Pour lister les ordonnanceurs disponibles pour un périphérique et l'ordonnanceur actif (entre parenthèses) : 

$ cat /sys/block/sda/queue/scheduler
mq-deadline kyber [bfq] none

Pour lister les ordonnanceurs disponibles pour tous les périphériques : 

$ grep "" /sys/block/*/queue/scheduler
/sys/block/pktcdvd0/queue/scheduler:none
/sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
/sys/block/sr0/queue/scheduler : [mq-deadline] kyber bfq none

Pour changer l'ordonnanceur d'E/S actif en bfq pour le périphérique sda, utilisez : 

# echo bfq > /sys/block/sda/queue/scheduler

Le processus de changement de planificateur d'E/S, selon que le disque tourne ou non, peut être automatisé et persister à travers les redémarrages. Par exemple, la règle udev ci-dessous définit le planificateur à none pour NVMe, mq-deadline pour SSD/eMMC, et bfq pour les disques rotatifs : 

/etc/udev/rules.d/60-ioschedulers.rules
# définir le planificateur pour NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"
# définir le planificateur pour SSD et eMMC
ACTION=="add|change", KERNEL=="sd[a-z]*|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# définir le planificateur pour les disques rotatifs
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

Redémarrez ou forcez udev (Français)#Charger de nouvelles règles.

Réglage du planificateur d'E/S

Chaque ordonnanceur d'E/S du noyau possède ses propres paramètres de réglage, tels que le temps de latence, le délai d'expiration ou les paramètres FIFO. Ils sont utiles pour ajuster l'algorithme à une combinaison particulière de périphérique et de charge de travail. Il s'agit généralement d'obtenir un débit plus élevé ou une latence plus faible pour une utilisation donnée. Les paramètres et leur description se trouvent dans la kernel documentation.

Pour lister les paramètres disponibles pour un périphérique, dans l'exemple ci-dessous sdb qui utilise deadline, utilisez : 

$ ls /sys/block/sdb/queue/iosched
fifo_batch front_merges read_expire write_expire writes_starved

Pour améliorer le débit de deadline au prix de la latence, on peut augmenter fifo_batch avec la commande : 

# echo 32 > /sys/block/sdb/queue/iosched/'fifo_batch

Configuration de la gestion de l'alimentation

Lorsqu'il s'agit de disques rotatifs traditionnels (HDD), vous pouvez vouloir baisser ou désactiver complètement les fonctions d'économie d'énergie.

Réduire les lectures/écritures sur les disques

Éviter les accès inutiles aux disques de stockage lents est bon pour les performances et augmente également la durée de vie des dispositifs, bien que sur le matériel moderne, la différence d'espérance de vie soit généralement négligeable.

Note: Un SSD de 32 Go avec un facteur d'amplification d'écriture médiocre de 10x, un cycle d'écriture/effacement standard de 10000, et 10 Go de données écrites par jour, aurait une espérance de vie de 8 ans. Cela s'améliore avec des SSD plus grands et des contrôleurs modernes avec moins d'amplification d'écriture. Consultez également cette expérience d'endurance pour savoir si une stratégie particulière visant à limiter les écritures sur le disque est réellement nécessaire.

Afficher les écritures sur disque

Le paquet iotop permet de trier les écritures sur disque et de montrer la quantité et la fréquence d'écriture des programmes sur le disque. Consultez iotop(8) pour plus de détails.

Relocaliser des fichiers dans tmpfs

Déplacez des fichiers, tels que votre profil de navigateur, vers un système de fichiers tmpfs, pour améliorer la réponse des applications puisque tous les fichiers sont maintenant stockés en RAM :

Systèmes de fichiers

Référez-vous à la page système de fichiers correspondante au cas où il y aurait des instructions pour améliorer les performances, par exemple Ext4 (Français)#Améliorer les performances et XFS#Performance.

Espace swap

Consultez Swap (Français)#Performance.

Intervalle de réécriture et taille du tampon

Consultez Sysctl#Virtual memory pour plus de détails.

Planification des E/S de stockage avec ionice

De nombreuses tâches telles que les sauvegardes ne dépendent pas d'un court délai d'E/S de stockage ou d'une large bande passante d'E/S de stockage pour remplir leur tâche, elles peuvent être classées comme des tâches d'arrière-plan. D'autre part, des E/S rapides sont nécessaires pour une bonne réactivité de l'interface utilisateur sur le bureau. Il est donc avantageux de réduire la quantité de bande passante de stockage disponible pour les tâches d'arrière-plan, alors que d'autres tâches ont besoin d'E/S de stockage. Cela peut être réalisé en utilisant l'ordonnanceur d'E/S CFQ de Linux, qui permet de définir différentes priorités pour les processus.

La priorité d'E/S d'un processus d'arrière-plan peut être réduite au niveau "Idle" en le démarrant avec la commande suivante 

# commande ionice -c 3

Consultez une courte introduction à ionice et ionice(1) pour plus d'informations.

CPU

Overclocking

L'overclocking améliore les performances de calcul du CPU en augmentant sa fréquence d'horloge maximale. La capacité d'overclocking dépend de la combinaison du modèle de CPU et du modèle de carte mère. Elle s'effectue le plus souvent par le biais du BIOS. L'overclocking présente également des inconvénients et des risques. Il n'est ni recommandé ni déconseillé ici.

De nombreuses puces Intel ne communiquent pas correctement leur fréquence d'horloge à acpi_cpufreq et à la plupart des autres utilitaires. Il en résultera des messages excessifs dans dmesg, qui peuvent être évités en déchargeant et en mettant sur liste noire le module du noyau acpi_cpufreq. Pour lire leur vitesse d'horloge, utilisez i7z du paquet i7z. Pour vérifier le bon fonctionnement d'un CPU overclocké, il est recommandé de faire des stress testing.

Mise à l'échelle de la fréquence

Consultez CPU frequency scaling (Français).

Modification de l'ordonnanceur par défaut (CFS) pour plus de réactivité

L'ordonnanceur du processeur par défaut dans le noyau Linux principal est CFS.

Les paramètres par défaut en amont sont modifiés pour un débit élevé, ce qui rend les applications de bureau peu réactives en cas de fortes charges CPU.

Le paquet cfs-zen-tweaksAUR contient un script qui configure le CFS pour utiliser les mêmes paramètres que le noyau linux-zen. Pour exécuter le script au démarrage, activez set-cfs-tweaks.service.

Planificateurs de CPU alternatifs

  • MuQSS — Multiple Queue Skiplist Scheduler. Disponible avec le jeu de correctifs -ck développé par Con Kolivas.
Unofficial user repositories/Repo-ck || {AUR}}
  • PDS — Planificateur de files d'attente multiples basé sur la priorité et la date limite Skiplist, axé sur la réactivité du bureau.
https://cchalpha.blogspot.com/ || linux-pdsAUR[broken link: package not found]

Noyau temps réel

Certaines applications, telles que l'exécution d'une carte tuner TV en pleine résolution HD (1080p), peuvent bénéficier de l'utilisation d'un noyau temps réel.

Ajustement des priorités des processus

Consultez également nice(1) et renice(1).

Ananicy

Ananicy est un daemon, disponible en tant que ananicy-gitAUR ou ananicy-cppAUR, pour ajuster automatiquement les niveaux de priorité des exécutables. Le nice level représente la priorité de l'exécutable lors de l'allocation des ressources CPU.

cgroups

Consultez cgroups.

Cpulimit

Cpulimit est un programme permettant de limiter le pourcentage d'utilisation du CPU d'un processus spécifique. Après avoir installé cpulimitAUR, vous pouvez limiter l'utilisation du CPU du PID d'un processus en utilisant une échelle de 0 à 100 fois le nombre de cœurs du CPU de l'ordinateur. Par exemple, avec huit cœurs de CPU, la plage de pourcentage sera de 0 à 800. Utilisation : 

$ cpulimit -l 50 -p 5081

irqbalance

L'objectif de irqbalance est de répartir les interruptions matérielles entre les processeurs d'un système multiprocesseur afin d'augmenter les performances. Il peut être contrôlé par le service irqbalance.service fourni.

Désactiver les mesures d'atténuation des exploits du CPU

Attention: Ne pas appliquer ce paramètre sans tenir compte des vulnérabilités qu'il ouvre. Consultez ceci et cela pour plus d'informations.

La désactivation des mesures d'atténuation des exploits du CPU peut améliorer les performances. Utilisez le paramètre du noyau ci-dessous pour les désactiver toutes : 

mitigations=off

Les explications de tous les paramètres qu'il active sont données sur kernel.org. Vous pouvez utiliser spectre-meltdown-checkerAUR pour vérifier la vulnérabilité.

Note: Lorsque vous utilisez un processeur Intel de génération 10 et plus, ou AMD Ryzen 1 et plus, l'augmentation des performances résultant de la désactivation des mesures d'atténuation n'est que de 5% au lieu de 25% pour les générations précédentes de processeurs. Consultez la revue générale du début 2021, le test sur Rocket Lake et le test sur Alder Lake

Graphiques

Configuration d'Xorg

Les performances graphiques peuvent dépendre des paramètres dans xorg.conf(5) ; consultez les articles NVIDIA, AMDGPU et Intel. Des paramètres incorrects peuvent empêcher Xorg de fonctionner, la prudence est donc de mise.

Configuration Mesa

Les performances des pilotes Mesa peuvent être configurées via drirc. Des outils de configuration GUI sont disponibles :

  • adriconf (Advanced DRI Configurator) — Outil GUI pour configurer les pilotes Mesa en définissant des options et en les écrivant dans le fichier standard drirc.
https://gitlab.freedesktop.org/mesa/adriconf/ || adriconf
  • DRIconf — Application de configuration pour l'infrastructure de rendu direct. Elle permet de personnaliser les paramètres de performance et de qualité visuelle des pilotes OpenGL au niveau du pilote, de l'écran et/ou de l'application.
https://dri.freedesktop.org/wiki/DriConf/ || driconfAUR

Accélération vidéo matérielle

L'accélération vidéo matérielle permet à la carte vidéo de décoder/encoder la vidéo.

Overclocking

Comme pour les CPU, l'overclocking peut améliorer directement les performances, mais il est généralement déconseillé. Il existe plusieurs paquets dans l'AUR, comme rovclockAUR (cartes ATI), rocm-smi-lib (cartes AMD récentes), nvclockAUR (anciennes NVIDIA - jusqu'à Geforce 9), et nvidia-utils pour les cartes NVIDIA récentes.

Consultez AMDGPU#Overclocking ou NVIDIA/Tips and tricks#Enabling overclocking.

Activation du redimensionnement du BAR du PCI

Note:
  • Sur certains systèmes, l'activation de PCI Resizable BAR peut entraîner une perte significative de performances. Vérifiez pour votre système et assurez-vous qu'il gagne en performances.
  • Le Compatibility Support Module (CSM) doit être désactivé pour que cela fasse effet.

La spécification PCI permet d'utiliser des Base Address Registers plus grands pour exposer la mémoire des périphériques PCI au contrôleur PCI. Cela peut entraîner une augmentation des performances des cartes vidéo. Avoir accès à la totalité de la mémoire vidéo améliore les performances, mais permet également des optimisations dans le pilote graphique. La combinaison d'une BAR redimensionnable, d'un décodage supérieur à la 4G et de ces optimisations du pilote est ce qu'AMD appelle AMD Smart Access Memory, disponible d'abord sur les cartes mères à chipset AMD Series 500, puis étendu aux AMD Series 400 et Intel Series 300 et ultérieures à travers les mises à jour UEFI. Ce paramètre peut ne pas être disponible sur toutes les cartes mères et est connu pour causer parfois des problèmes de démarrage sur certaines cartes.

Si la BAR a une taille de 256M, la fonction n'est pas activée ou n'est pas prise en charge : 

# dmesg | grep BAR=
[drm] VRAM détectée RAM=8176M, BAR=256M

Pour l'activer, activez le paramètre nommé "Above 4G Decode" ou ">4GB MMIO" dans les paramètres de votre carte mère. Vérifiez que la BAR est maintenant plus grande : 

# dmesg | grep BAR=
[drm] VRAM détectée RAM=8176M, BAR=8192M

RAM, swap et gestion des OOM

Fréquence d'horloge et timings

La RAM peut fonctionner à des fréquences d'horloge et des timings différents, qui peuvent être configurés dans le BIOS. Les performances de la mémoire dépendent de ces deux valeurs. La sélection du préréglage le plus élevé présenté par le BIOS améliore généralement les performances par rapport au réglage par défaut. Notez que l'augmentation de la fréquence à des valeurs non prises en charge par le vendeur de la carte mère et de la mémoire vive est un overclocking, et les mêmes risques et inconvénients s'appliquent, consultez #Overclocking.

Root sur un overlay en RAM

Si vous utilisez un support à écriture lente (USB, disques durs en rotation) et que les besoins en stockage sont faibles, la racine peut être exécutée sur une superposition de RAM au-dessus de la racine en lecture seule (sur le disque). Cela peut améliorer considérablement les performances au prix d'un espace limité en écriture pour la racine. Voir liverootAUR.

zram ou zswap

Le module noyau zram (précédemment appelé compcache) fournit un périphérique de bloc compressé en RAM. Si vous l'utilisez comme périphérique de swap, la RAM peut contenir beaucoup plus d'informations mais utilise plus de CPU. Néanmoins, c'est beaucoup plus rapide que le swap sur un disque dur. Si un système revient souvent à l'échange, cela peut améliorer la réactivité. L'utilisation de zram est également un bon moyen de réduire les cycles de lecture/écriture du disque dus au swap sur les SSD.

Des avantages similaires (à des coûts similaires) peuvent être obtenus en utilisant zswap plutôt que zram. Les deux sont généralement similaires dans leur intention mais pas dans leur fonctionnement : zswap fonctionne comme un cache RAM compressé et ne nécessite (ni ne permet) une configuration étendue de l'espace utilisateur. Consultez zswap pour plus de détails sur les différences entre les deux.

Astuce: Puisqu'il est activé par défaut, désactivez zswap lorsque vous utilisez zram pour éviter qu'il agisse comme un cache de swap devant zram. Si les deux sont activés, les statistiques de zramctl(8) sont incorrectes car zram reste en grande partie inutilisé ; ceci est dû au fait que zswap intercepte et compresse les pages de mémoire qui sont échangées avant d'atteindre zram.

Exemple : Pour configurer un périphérique zram compressé lz4 avec une capacité de 32 Go et une priorité supérieure à la normale (uniquement pour la session en cours) : 

# modprobe zram
# echo lz4 > /sys/block/zram0/comp_algorithme
# echo 32G > /sys/block/zram0/disksize
# mkswap --label zram0 /dev/zram0
# swapon --priority 100 /dev/zram0

Pour le désactiver à nouveau, redémarrez ou exécutez 

# swapoff /dev/zram0
# rmmod zram

Une explication détaillée de toutes les étapes, options et problèmes potentiels est fournie dans la documentation officielle du module zram.

Le paquet zram-generator fournit une unité systemd-zram-setup@.service pour initialiser automatiquement les périphériques zram sans que les utilisateurs aient à activer/démarrer le modèle ou ses instances. Les ressources suivantes fournissent des informations sur la façon de l'utiliser :

"Le générateur sera invoqué par systemd dès le démarrage", donc l'utilisation est aussi simple que de créer le(s) fichier(s) de configuration approprié(s) et de redémarrer. Un exemple de configuration est fourni dans /usr/share/doc/zram-generator/zram-generator.conf.example. Vous pouvez également check the swap status de vos périphériques configurés /dev/zramN en vérifiant le statut de l'unité de la ou des instances systemd-zram-setup@zramN.service.

Le paquet zramswapAUR fournit un script automatisé pour configurer un swap avec une priorité plus élevée et une taille par défaut de 20% de la taille de la RAM de votre système. Pour le faire automatiquement à chaque démarrage, activez zramswap.service.

Alternativement, le paquet zramdAUR permet de configurer zram automatiquement en utilisant la compression zstd par défaut, sa configuration peut être modifiée dans /etc/default/zramd. Il peut être lancé au démarrage en activant l'unité zramd.service.

Swap sur zram en utilisant une règle udev

L'exemple ci-dessous décrit comment configurer l'échange sur zram automatiquement au démarrage avec une seule règle udev. Aucun paquet supplémentaire ne devrait être nécessaire pour que cela fonctionne.

Tout d'abord, activez le module : 

/etc/modules-load.d/zram.conf
zram

Configurez le nombre de noeuds /dev/zram dont vous avez besoin. 

/etc/modprobe.d/zram.conf
options zram num_devices=2

Créez la règle udev comme indiqué dans l'exemple. 

/etc/udev/rules.d/99-zram.rules
KERNEL=="zram0", ATTR{disksize}="512M" RUN="/usr/bin/mkswap /dev/zram0", TAG+="systemd"
KERNEL=="zram1", ATTR{disksize}="512M" RUN="/usr/bin/mkswap /dev/zram1", TAG+="systemd"

Ajoutez /dev/zram à votre fstab. 

/etc/fstab
/dev/zram0 none swap defaults 0 0
/dev/zram1 none swap defaults 0 0

Utilisation de la RAM de la carte graphique

Dans le cas peu probable où vous avez très peu de RAM et un surplus de mémoire vidéo, vous pouvez utiliser cette dernière comme swap. Consultez Swap on video RAM.

Amélioration de la réactivité du système dans des conditions de faible mémoire

Sur les systèmes GNU/Linux traditionnels, en particulier pour les stations de travail graphiques, lorsque la mémoire allouée est sur-utilisée, la réactivité globale du système peut se dégrader jusqu'à un état presque inutilisable avant de déclencher la fonction OOM-killer du noyau ou de libérer une quantité suffisante de mémoire (ce qui a peu de chances d'arriver rapidement lorsque le système ne répond pas, car vous pouvez difficilement fermer les applications gourmandes en mémoire qui peuvent continuer à allouer plus de mémoire). Le comportement dépend également de configurations et de conditions spécifiques, le retour à un état de réactivité normal peut prendre de quelques secondes à plus d'une demi-heure, ce qui peut être pénible à attendre dans un scénario sérieux, comme pendant une présentation de conférence.

Astuce: Vérifiez si /proc/sys/vm/oom_kill_allocating_task est 0 et envisagez de le modifier. [1]

Bien que le comportement du noyau et de l'espace utilisateur dans des conditions de faible mémoire puisse s'améliorer à l'avenir, comme discuté sur les listes de diffusion kernel et Fedora, les utilisateurs peuvent utiliser des options plus réalisables et efficaces que la réinitialisation du système ou le réglage de sysctl vm.overcommit_* :

  • Déclencher manuellement le kernel OOM-killer avec Magic SysRq key, à savoir Alt+SysRq+f.
  • Utilisez un daemon OOM en espace utilisateur pour traiter ces problèmes automatiquement (ou de manière interactive).
Attention: Déclencher le tueur OOM pour tuer les applications en cours d'exécution peut perdre vos travaux non sauvegardés. C'est à vous de voir si vous êtes assez patient pour attendre dans l'espoir que les applications libèrent enfin la mémoire normalement, ou si vous voulez rétablir un système qui ne répond pas dès que possible.

Parfois, un utilisateur peut préférer le daemon OOM à SysRq parce qu'avec le kernel OOM-killer vous ne pouvez pas donner la priorité au processus à terminer (ou non). Pour lister quelques daemons OOM :

  • systemd-oomd — Fourni par systemd en tant que systemd-oomd.service qui utilise cgroups-v2 et pressure stall information (PSI) pour surveiller et prendre des mesures sur les processus avant qu'une OOM ne se produise dans l'espace noyau.
https://github.com/systemd/systemd, systemd-oomd(8) || systemd
  • earlyoom — Implémentation simple du tueur d'OOM en espace utilisateur écrite en C.
https://github.com/rfjakob/earlyoom || earlyoom
  • oomd — Mise en oeuvre de OOM-killer basée sur PSI, nécessite un noyau Linux version 4.20+. La configuration est en JSON et est assez complexe. Le fonctionnement est confirmé dans l'environnement de production de Facebook.
https://github.com/facebookincubator/oomd || oomdAUR
  • nohang — Gestionnaire d'OOM sophistiqué écrit en Python, avec support PSI optionnel, plus configurable que earlyoom.
https://github.com/hakavlad/nohang || nohang-gitAUR
  • low-memory-monitor — L'effort du développeur de GNOME qui vise à fournir une meilleure communication aux applications de l'espace utilisateur pour indiquer l'état de mémoire faible, en plus du fait qu'il pourrait être configuré pour déclencher le kernel OOM-killer. Basé sur PSI, nécessite Linux 5.2+.
https://gitlab.freedesktop.org/hadess/low-memory-monitor/ || low-memory-monitor-gitAUR
  • uresourced — Un petit daemon qui active la protection des ressources basée sur le cgroup pour la session utilisateur graphique active.
https://gitlab.freedesktop.org/benzea/uresourced || uresourcedAUR

Réseau

Watchdogs

Selon Wikipedia:Watchdog timer :

Un «watchdog» (chien de garde) [...] est une minuterie électronique qui est utilisée pour détecter et récupérer des dysfonctionnements de l'ordinateur. En fonctionnement normal, l'ordinateur réinitialise régulièrement le chien de garde [...]. Si, [...], l'ordinateur ne parvient pas à réinitialiser le chien de garde, la minuterie s'écoule et génère un signal de dépassement de délai [...] utilisé pour lancer des actions correctives [...] qui consistent généralement à placer le système informatique dans une configuration sûre et à rétablir son fonctionnement normal.

De nombreux utilisateurs ont besoin de cette fonction en raison du rôle critique de leur système (par exemple, les serveurs) ou de l'absence de réinitialisation de l'alimentation (par exemple, les appareils embarqués). Ainsi, cette fonction est nécessaire pour un bon fonctionnement dans certaines situations. D'autre part, les utilisateurs normaux (c'est-à-dire les ordinateurs de bureau et les ordinateurs portables) n'ont pas besoin de cette fonction et peuvent la désactiver.

Pour désactiver les watchdog (logiciels et matériels), ajoutez nowatchdog à vos paramètres de démarrage.

Pour vérifier la nouvelle configuration, faites : 

# cat /proc/sys/kernel/watchdog

ou utilisez : 

# wdctl

Après avoir désactivé les watchdogs, vous pouvez optionnellement éviter le chargement du module responsable du watchdog matériel, aussi. Faites-le en mettant en liste noire le module concerné, par exemple iTCO_wdt.

Note: Certains utilisateurs [2] ont signalé que le paramètre nowatchdog ne fonctionne pas comme prévu mais qu'ils ont réussi à désactiver le watchdog (au moins celui du matériel) en mettant sur liste noire le module susmentionné.

L'une ou l'autre de ces actions accélérera votre démarrage et votre arrêt, car un module de moins sera chargé. De plus, la désactivation du chien de garde augmente les performances et baisse la consommation d'énergie.

Consultez [3], [4], [5], et [6] pour plus d'informations.

Consulter également

Retrieved from "https://wiki.archlinux.org/index.php?title=Improving_performance_(Français)&oldid=804208"