Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
Guide de gestion de l'alimentation
Gestion de l'alimentation sur Red Hat Enterprise Linux 7
Red Hat Inc.
Jana Heves
Jacquelynn East
Don Domingo
Rüdiger Landmann
Jack Reed
Résumé
Chapitre 1. Vue d'ensemble
1.1. Importance de la gestion de l'alimentation
- la réduction de la consommation d'énergie en général dans le but de réduire les coûts
- une réduction de chaleur pour les serveurs et les centres de calcul
- des coûts secondaires réduits, y compris le refroidissement, l'espace, les cables, les générateurs, et les systèmes d'alimentation sans coupure (UPS)
- une augmentation de l'autonomie de la batterie pour les ordinateurs portables
- une baisse de la production de dioxyde de carbone
- conformité avec la réglementation du gouvernement ou avec les exigences légales concernant l'IT verte, par exemple Energy Star
- conformité avec la ligne de conduite de la compagnie sur les nouveaux systèmes
- Q : Est-ce que je dois vraiment optimiser ?
- Q : À quel point devrais-je optimiser ?
- Q : Est-ce que l'optimisation va réduire la performance du système à un niveau inacceptable ?
- Q : Le temps pris et les ressources utilisées pour optimiser le système sont-ils plus importants que les gains à obtenir ?
1.2. Bases de la gestion de l'alimentation
Depuis Red Hat Enterprise Linux 6, le noyau exécute tickless qui remplace les anciennes interruptions de l'horloge périodique par des interruptions à la demande. Ainsi, les CPU inactifs peuvent rester inactifs jusqu'à ce qu'une nouvelle tâche soit placée en file d'attente pour traitement, et les CPU se trouvant dans des états de basse alimentation peuvent rester dans ces états plus longtemps. Cependant, les avantages de ce système peuvent être compromis si votre système possède des applications qui créent des événements de minuterie inutiles, comme par exemple, des événements d'interrogation de l'hôte, comme vérifier des changements de volume ou des mouvements du pointeur.
Ceci est particulièrement vrai pour les périphériques possédant des pièces amovibles (par exemple des disques durs). En outre, certaines applications peuvent laisser un périphérique inutilisé mais activé « ouvert ». Lorsque cela se produit, le noyau suppose que le périphérique est en cours d'utilisation, ce qui peut empêcher le périphérique de se mettre en état d'économie d'énergie.
Dans de nombreux cas, ceci dépend d'un matériel moderne et d'une configuration BIOS correcte. Les composants de système plus anciens ne prennent pas en charge certaines des nouvelles fonctionnalités prises en charge dans Red Hat Enterprise Linux 7. Assurez-vous de bien utiliser le microprogramme le plus récent dans vos systèmes et que les fonctionnalités de gestion de l'alimentation dans les sections de gestion de l'alimentation ou de configuration de périphériques soient activées. Ci-dessous figurent quelques-unes des fonctionnalités à rechercher :
- SpeedStep
- PowerNow!
- Cool'n'Quiet
- ACPI (C state)
- Smart
Les CPUs modernes ainsi que l'ACPI (de l'anglais, Advanced Configuration and Power Interface) offrent différents états d'alimentation. Les trois différents états sont :
- Veille (C-states)
- Fréquence (P-states)
- Sortie de chaleur (« T-states » ou « états thermaux »)
Aussi évident que cela puisse paraître, l'une des meilleures manières d'économiser de l'énergie est d'éteindre les systèmes. Par exemple, votre compagnie peut développer une culture d'entreprise se concentrant sur une informatique « verte », avec comme conseil d'éteindre les machines lors de la pause déjeuner ou après le travail. Vous pourriez aussi consolider plusieurs serveurs physiques en un grand serveur et les virtualiser en utilisant la technologie de virtualisation fournie avec Red Hat Enterprise Linux 7.
Chapitre 2. Audit et analyse de la gestion de l'alimentation
2.1. Aperçu général - Auditing et Analyse
2.2. PowerTOP
root
, la commande suivante :
yum install powertop
root
, la commande suivante :
powertop
root
, la commande suivante :
powertop --calibrate
systemctl disable servicename.service
root
, les commandes suivantes :
ps -awux | grep processname
strace -p processid
C4
étant plus élevé que C3
). C'est une bonne indication pour savoir si l'utilisation du CPU a été optimisée correctement. La résidence doit correspondre à 90% ou plus, and un état C- ou P- quand le système est inactif.
Figure 2.1. Opération de PowerTOP
--html
. Remplacer le paramètre htmlfile.html par le nom désiré dans le fichier de sortie :
powertop --html=htmlfile.html
--time
:
powertop --html=htmlfile.html --time=seconds
turbostat
(8) ou lire le guide Performance Tuning Guide.
2.3. Diskdevstat et netdevstat
root
:
yum install tuned-utils-systemtap kernel-debuginfo
diskdevstat
netdevstat
diskdevstat update_interval total_duration display_histogram
netdevstat update_interval total_duration display_histogram
- update_interval
- Le temps en secondes entre les mises à jour de l'affichage. Par défaut :
5
- total_duration
- Le temps en secondes pour la totalité de l'exécution. Par défaut :
86400
(1 jour) - display_histogram
- Indiquez s'il faut inclure toutes les données collectées dans l'histogramme à la fin de l'exécution.
PID UID DEV WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG READ_CNT READ_MIN READ_MAX READ_AVG COMMAND 2789 2903 sda1 854 0.000 120.000 39.836 0 0.000 0.000 0.000 plasma 5494 0 sda1 0 0.000 0.000 0.000 758 0.000 0.012 0.000 0logwatch 5520 0 sda1 0 0.000 0.000 0.000 140 0.000 0.009 0.000 perl 5549 0 sda1 0 0.000 0.000 0.000 140 0.000 0.009 0.000 perl 5585 0 sda1 0 0.000 0.000 0.000 108 0.001 0.002 0.000 perl 2573 0 sda1 63 0.033 3600.015 515.226 0 0.000 0.000 0.000 auditd 5429 0 sda1 0 0.000 0.000 0.000 62 0.009 0.009 0.000 crond 5379 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 5473 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 5415 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 5433 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 5425 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 5375 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 5477 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 5469 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 5419 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 5481 0 sda1 0 0.000 0.000 0.000 61 0.000 0.001 0.000 crond 5355 0 sda1 0 0.000 0.000 0.000 37 0.000 0.014 0.001 laptop_mode 2153 0 sda1 26 0.003 3600.029 1290.730 0 0.000 0.000 0.000 rsyslogd 5575 0 sda1 0 0.000 0.000 0.000 16 0.000 0.000 0.000 cat 5581 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 5582 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 5579 0 sda1 0 0.000 0.000 0.000 12 0.000 0.001 0.000 perl 5580 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 5354 0 sda1 0 0.000 0.000 0.000 12 0.000 0.170 0.014 s h 5584 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 5548 0 sda1 0 0.000 0.000 0.000 12 0.001 0.014 0.001 perl 5577 0 sda1 0 0.000 0.000 0.000 12 0.001 0.003 0.000 perl 5519 0 sda1 0 0.000 0.000 0.000 12 0.001 0.005 0.000 perl 5578 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 5583 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 5547 0 sda1 0 0.000 0.000 0.000 11 0.000 0.002 0.000 perl 5576 0 sda1 0 0.000 0.000 0.000 11 0.001 0.001 0.000 perl 5518 0 sda1 0 0.000 0.000 0.000 11 0.000 0.001 0.000 perl 5354 0 sda1 0 0.000 0.000 0.000 10 0.053 0.053 0.005 lm_lid.sh
- PID
- l'ID du processus de l'application
- UID
- l'ID utilisateur sous lequel l'application est exécutée
- DEV
- le périphérique sur lequel les E/S ont eu lieu
- WRITE_CNT
- le nombre total des opérations d'écriture
- WRITE_MIN
- le temps le moins long pris pour deux écritures consécutives (en secondes)
- WRITE_MAX
- le temps le plus long pris pour deux écritures consécutives (en secondes)
- WRITE_AVG
- le temps moyen pris pour deux écritures consécutives (en secondes)
- READ_CNT
- le nombre total des opérations de lecture
- READ_MIN
- le temps le moins long pris pour deux lectures consécutives (en secondes)
- READ_MAX
- le temps le plus long pris pour deux lectures consécutives (en secondes)
- READ_AVG
- le temps moyen pris pour deux lectures consécutives (en secondes)
- COMMANDE
- le nom du processus
PID UID DEV WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG READ_CNT READ_MIN READ_MAX READ_AVG COMMAND 2789 2903 sda1 854 0.000 120.000 39.836 0 0.000 0.000 0.000 plasma 2573 0 sda1 63 0.033 3600.015 515.226 0 0.000 0.000 0.000 auditd 2153 0 sda1 26 0.003 3600.029 1290.730 0 0.000 0.000 0.000 rsyslogd
WRITE_CNT
plus important que 0
, ce qui veut dire qu'elles ont effectué une sorte d'écriture pendant la mesure. De celles-ci, plasma fut la pire et de loin : cette application a effectuée la plupart des opérations d'écriture, et bien sûr le temps moyen entre les écritures était le plus bas. Plasma serait donc l'application idéale à étudier si vous vous sentiez concerné par les applications inefficaces au niveau de la consommation d'énergie.
strace -p 2789
strace
contient un schéma se répétant toutes les 45 secondes qui ouvre le fichier cache de l'icône KDE de l'utilisateur pour une écriture, suivi par la fermeture immédiate du fichier. Ceci a nécessairement conduit à une écriture physique sur le disque dur puisque les métadonnées du fichier (plus spécifiquement l'heure de la modification) avaient changées. Le correctif final servait à prévenir ces appels inutiles lorsqu'il n'y avait pas eu de mises à jour des icônes.
2.4. Battery Life Tool Kit
-a
.
office
écrit un texte, le corrige, et refera la même chose sur une feuille de calcul. L'exécution de BLTK, combinée avec PowerTOP, ou tout autre outil d'audit ou d'analyse, vous permettra de vérifier si l'optimisation que vous avez effectuée a un effet quand la machine est active par rapport à quand elle n'est pas active. Comme vous pouvez exécuter la même charge de travail de multiples fois avec différents paramètres, vous pourrez comparer les résultats.
yum install bltk
bltk workload options
inactive
pendant 120 secondes :
bltk -I -T 120
-I
,--idle
- système est inactif, pour utiliser comme ligne de base pour comparer avec d'autres charges de travail
-R
,--reader
- simule la lecture de documents (par défaut avec Firefox)
-P
,--player
- simule la lecture de fichiers multimédia depuis un lecteur CD ou DVD (par défaut avec mplayer)
-O
,--office
- simule la modification de documents avec la suite bureautique OpenOffice.org
-a
,--ac-ignore
- ignore si l'alimentation secteur est disponible (nécessaire pour l'utilisation d'ordinateurs de bureau)
-T nombre_de_secondes
,--time nombre_de_secondes
- le temps (en secondes) pris pour l'exécution du test ; utilisez cette option avec la charge de travail
inactive
-F nom_de_fichier
,--file nom_de_fichier
- spécifie un fichier devant être utilisé par une charge de travail en particulier, par exemple, un fichier pour la charge de travail
player
pour lire au lieu d'accéder au lecteur CD ou DVD. -W application
,--prog application
- spécifie une application devant être utilisée par une charge de travail, par exemple, un navigateur autre que Firefox pour la charge de travail
reader
bltk
.
/etc/bltk.conf
— par défaut, ~/.bltk/workload.results.number/
. Par exemple, le répertoire ~/.bltk/reader.results.002/
contient les résultats du troisième test avec la charge de travail reader
(le premier test n'est pas numéroté). Les résultats sont éparpillés sur plusieurs fichiers texte. Pour convertir ces résultats dans un format facile à lire, exécutez :
bltk_report chemin_vers_le_répertoire_des_résultats
Report
dans le répertoire des résultats. Pour voir les résultats dans un émulateur de terminal, utilisez l'option -o
:
bltk_report -o chemin_vers_le_répertoire_des_résultats
2.5. UPower
upower
et les options suivantes :
--enumerate
,-e
- affiche un chemin d'objet pour chaque périphérique d'alimentation sur le système, par exemple :
/org/freedesktop/UPower/devices/line_power_AC
/org/freedesktop/UPower/devices/battery_BAT0
--dump
,-d
- affiche les paramètres pour tous les périphériques d'alimentation sur le système.
--wakeups
,-w
- affiche les réveils CPU sur le système.
--monitor
,-m
- surveille les modifications apportées aux périphériques d'alimentation sur le système. Par exemple, la connexion ou déconnexion de la source d'alimentation secteur, ou l'épuisement d'une batterie. Pressez sur Ctrl+C pour arrêter la surveillance du système.
--monitor-detail
- surveille les modifications apportées aux périphériques d'alimentation sur le système. Par exemple, la connexion ou déconnexion de la source d'alimentation secteur, ou l'épuisement d'une batterie. L'option
--monitor-detail
présente davantage de détails que l'option--monitor
. Pressez sur Ctrl+C pour arrêter la surveillance du système. --show-info chemin_de_l'objet
,-i chemin_de_l'objet
- affiche toutes les informations disponibles sur un chemin d'objet particulier. Par exemple, pour obtenir des informations sur une batterie de votre système représentée par le chemin d'objet
/org/freedesktop/UPower/devices/battery_BAT0
, exécutez :upower -i /org/freedesktop/UPower/devices/battery_BAT0
2.6. Gestionnaire d'alimentation GNOME
2.7. Autres outils d'auditing
- vmstat
- vmstat vous donne des informations détaillées sur les processus, la mémoire, la pagination, les E/S de bloc, les déroutements, et l'activité du CPU. Utilisez cette commande pour voir de plus près ce que le système fait et où il est actif.
- iostat
- iostat est similaire à vmstat, mais seulement pour les E/S des périphériques de bloc. Cette commande fournit aussi une sortie et des statistiques plus verbeuses.
- blktrace
- blktrace est un programme de suivi détaillé des E/S de bloc. Il décompose les informations en blocs uniques associés à des applications. Il se révèle très utile en conjonction avec diskdevstat.
Chapitre 3. Infrastructure principale et mécanismes
Important
cpupower
expliquée dans ce chapitre, assurez-vous que le paquetage kernel-tools soit bien installé.
3.1. États inactifs du CPU
- C0
- l'état d'opération, ou d'exécution. Dans cet état, le CPU fonctionne et n'est pas inactif.
- C1, Arrêter
- un état dans lequel le processeur n'exécute pas d'instructions mais n'est habituellement pas dans un état de basse alimentation. Le CPU peut continuer ses calculs avec pratiquement aucun délai. Tous les processeurs offrant des états C-States doivent pouvoir prendre cet état en charge. Les processeurs Pentium 4 prennent en charge un état C1 amélioré nommé C1E qui est en fait un état de consommation d'électricité moindre.
- C2, Stop-Clock
- un état où l'horloge est gelée pour le processeur, mais qui reste dans son état complet pour ses registres et caches, de manière à ce que les processeurs recommencent leurs calculs dès le démarrage de l'horloge. Il s'agit d'un état optionnel.
- C3, Mise en veille
- un état où le processeur s'endort réellement et n'a pas besoin de conserver son cache à jour. Le réveil à partir de cet état prend considérablement plus longtemps que de l'état C2. Une fois de plus, cet état est optionnel.
cpupower idle-info
3.2. Utilisation des gouverneurs CPUfreq
3.2.1. Types de gouverneurs CPUfreq
Le gouverneur Performance force le CPU à utiliser la plus haute fréquence d'horloge possible. Cette fréquence est statiquement réglée, et ne changera pas. Ainsi, ce gouverneur en particulier n'offre aucune économie d'énergie. Il n'est utile que pour de longues heures de charges de travail intensives, et lorsque le CPU est rarement (ou n'est pas) inactif.
En revanche, le gouverneur Powersave force le CPU à utiliser la plus basse fréquence d'horloge possible. Cette fréquence est réglée statiquement, et ne changera pas. Ainsi, ce gouverneur en particulier offre une économie d'énergie maximale, mais ceci au prix d'une performance de CPU plus basse.
Le gouverneur Ondemand est un gouverneur dynamique qui permet au CPU d'atteindre une fréquence d'horloge maximale lorsque la charge du système est importante, et d'atteindre une fréquence minimale lorsque le système est inactif. Tandis que ceci permet d'ajuster la consommation d'énergie en fonction de la charge du système, cette opération se produit au détriment de la latence entre les changements de fréquences. Ainsi, la latence peut contrebalancer les bénéfices de performance/d'énergie du gouverneur Ondemand si le système change trop souvent entre inactivité et charges de travail intenses.
Le gouverneur Userspace permet aux programmes de l'espace utilisateur (ou à tout autre processus exécuté en tant que root) de définir la fréquence. De tous les gouverneurs, Userspace est le plus personnalisable ; et selon sa configuration, il peut fournir le meilleur équilibre entre performance et consommation pour votre système.
Tout comme le gouverneur Ondemand, le gouverneur Conservative ajuste aussi la fréquence de l'horloge en fonction de l'utilisation (comme le gouverneur Ondemand). Cependant, tandis que gouverneur le fait d'une manière plus aggressive (du maximum au minimum, et vice-versa), le gouverneur Conservative change de fréquence de manière plus graduelle.
Note
cron
. Ceci vous permettra de définir automatiquement des gouverneurs particuliers à des moments spécifiques de la journée. Ainsi, vous pouvez spécifier un gouverneur de basse latence pendant les périodes d'inactivité (par exemple hors des heures de travail traditionnelles), puis retourner à un gouverneur de fréquence plus importante durant les heures de charges de travail plus importantes.
3.2.2. Installation de CPUfreq
cpupower frequency-info --governors
cpupower frequency-set --governor [governor]
-c
en précisant une plage ou une liste séparée par des virgules de numéros de CPU. Par exemple, pour activer le gouverneur Userspace pour les CPUs 1-3 et 5, voici la commande :
cpupower -c 1-3,5 frequency-set --governor cpufreq_userspace
3.2.3. Paramétrer la politique CPUfreq et la vitesse
cpupower frequency-info
, vous pourrez aussi régler la vitesse de chaque processeur plus précisément avec des options pour cpupower frequency-set
.
cpupower frequency-info
, les options suivantes sont disponibles :
--freq
— Affiche la vitesse actuelle du CPU en fonction du cœur de CPUfreq, en KHz.--hwfreq
— Affiche la vitesse actuelle du CPU en fonction du matériel, en KHz (uniquement disponible en tant que root).--driver
— Affiche quel pilote de CPUfreq est utilisé pour paramétrer la fréquence sur ce CPU.--governors
— Affiche les gouverneurs CPUfreq disponibles dans ce noyau. Si vous souhaitez utiliser un gouverneur CPUfreq qui n'est pas listé dans ce fichier, voir Section 3.2.2, « Installation de CPUfreq » pour obtenir des instructions.--affected-cpus
— Répertorie les CPU nécessitant un logiciel de coordination de fréquence.--policy
— Affiche la portée de la stratégie CPUfreq actuelle, en KHz, ainsi que le gouverneur actuellement actif.--hwlimits
— Répertorie les fréquences disponibles pour le CPU, en KHz.
cpupower frequency-set
, les options suivantes sont disponibles :
--min <freq>
et--max <freq>
— Définit les limites de la stratégie du CPU, en KHz.--freq <freq>
— Définit une vitesse d'horloge spécifique pour le CPU, en KHz. Vous pouvez uniquement définir une vitesse située dans les limites de la stratégie du CPU (selon--min
et--max
).--governor <gov>
— Définit un nouveau gouverneur CPUfreq.
Note
/sys/devices/system/cpu/[cpuid]/cpufreq/
. Les paramètres et valeurs peuvent être modifiés en écrivant sur ces réglables. Par exemple, pour définir la vitesse d'horloge minimum du cpu0 sur 360 KHz, veuillez utiliser :
echo 360000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
3.3. Moniteurs CPU
cpupower-monitor
pour plus de détails sur ce que chaque analyseur mesure et avec quels systèmes ils sont compatibles.
cpupower monitor
:
-l
— répertorie tous les moniteurs disponibles sur votre système.-m <monitor1>, <monitor2>
— affiche des moniteurs spécifiques. Leurs identifiants peuvent être trouvés en exécutant-l
.command
— affiche les statistiques d'inactivité et les demandes de processeur d'une commande spécifique.
3.4. Stratégies d'économie d'énergie de processeur
cpupower set
:
- --perf-bias <0-15>
- Permet au logiciel sur processeurs Intel pris en charge de contribuer de manière plus active à déterminer l'équilibre entre une performance optimale et de meilleures économies d'énergie. Ceci ne remplace pas les autres stratégies d'économies d'énergie. Les valeurs assignées vont de 0 à 15, où 0 représente une performance optimale et 15 représente une efficacité énergétique optimale.Par défaut, cette option s'applique à tous les cœurs. Pour l'appliquer à un coeur en particulier, veuillez ajouter l'option
--cpu <cpulist>
. - --sched-mc <0|1|2>
- Restreint l'utilisation d'énergie par les processus systèmes aux cœurs dans un seul paquetage processeur (aussi appelé paquetage CPU) avant de puiser dans d'autres paquetages CPU. 0 définit aucune restriction, 1 utilise un seul paquetage CPU, et 2 réalise ceci en plus de favoriser les paquetages CPU semi-inactifs pour gérer les réveils des tâches.
- --sched-smt <0|1|2>
- Restreint l'utilisation d'énergie par les processus systèmes aux frères du fil d'un cœur de CPU avant de puiser dans d'autres cœurs. 0 définit aucune restriction, 1 utilise un seul paquetage CPU, et 2 réalise ceci en plus de favoriser les paquetages CPU semi-inactifs pour gérer les réveils des tâches.
3.5. Suspension et reprise
3.6. Gestion de l'alimentation des périphériques en cours d'exécution
/sys/devices/device/power/
, où device remplace le chemin qui mène au répertoire d'un périphérique particulier.
/sys/devices/system/cpu/power/
/sys/devices/device/power
contient les fichiers de configuration suivants :
control
control
:
auto
- valeur par défaut pour tous les périphériques, qui peuvent être en RDPM automatique, suivant le pilote
on
- empêche le pilote de gérer l'état d'alimentation du périphérique en cours d'exécution
autosuspend_delay_ms
/sys/devices/device/power/control
à on
. Les valeurs supérieures à 1000 secondes sont arrondies à la seconde la plus proche.
3.7. Gestion de l'alimentation en état actif
- défaut
- établit les états d'alimentation du lien PCIe en fonction des valeurs par défaut spécifiées par le microprogramme du système (par exemple, BIOS). Ceci est l'état par défaut d'ASPM.
- powersave
- règle ASPM de manière à économiser de l'énergie à chaque occasion, sans tenir compte de la performance en résultant.
- performance
- désactive ASPM afin de permettre aux liens PCIe d'opérer avec une performance maximale.
pcie_aspm
, dans lequel pcie_aspm=off
désactive ASPM et pcie_aspm=force
active ASPM, même sur les périphériques ne prenant pas en charge ASPM.
/sys/module/pcie_aspm/parameters/policy
, mais peuvent aussi être spécifiées lors du démarrage avec le paramètre de noyau pcie_aspm.policy
, dans lequel pcie_aspm.policy=performance
définira par exemple la stratégie de performance ASPM.
Avertissement
pcie_aspm=force
est défini, le matériel qui ne prend pas en charge ASPM peut provoquer une cessation de réponse du système. Avant de définir pcie_aspm=force
, assurez-vous que tout le matériel PCIe sur le système prend en charge ASPM.
3.8. Aggressive Link Power Management
Ce mode définit le lien sur son état le plus bas (SLUMBER) lorsqu'il n'y a pas d'E/S sur le disque. Ce mode est utile lorsque de longues périodes d'inactivité sont à prévoir.
Ce mode définit le lien sur le second état le plus bas (PARTIAL) lorsqu'il n'y a pas d'E/S sur le disque. Ce mode est conçu afin de permettre des transitions entre états d'alimentation (par exemple lorsqu'il y a des alternances entre une utilisation intense d'E/S et une période d'inactivité d'E/S) tout en limitant au maximum l'impact sur la performance.
medium_power
permet au lien de faire une transition entre les états « PARTIAL » (partiels) et les états « ACTIVES » (états actifs, aussi nommés « fully-powered » en anglais) selon la charge. Remarquez qu'il n'est pas possible de faire une transition de « PARTIAL » à « SLUMBER » et vice-versa. Dans ce cas, soit l'état de l'alimentation ne peut pas faire de transition vers l'autre sans que la transition ne passe par l'état « ACTIVE » en premier.
ALPM est désactivé, le lien ne peut pas entrer dans un état de faible alimentation lorsqu'il n'y a pas d'E/S sur le disque.
/sys/class/scsi_host/host*/link_power_management_policy
existe. Pour changer les paramètres, écrivez simplement les valeurs décrites dans cette section sur ces fichiers, ou affichez les fichiers pour vérifier le paramètre actuel.
3.9. Optimisation d'accès au disque Relatime
atime
, et la maintenir requiert une constante série d'opérations d'écriture sur le stockage. Ces écritures gardent les périphériques de stockage et leurs liens occupés et allumés. Comme peu d'applications utilisent les données atime
, l'activité de ce périphérique de stockage gaspille de l'énergie. De plus, l'écriture sur le stockage se produirait même si le fichier n'était pas lu à partir du stockage, mais à partir du cache. Depuis quelques temps, le noyau Linux prend en charge une option noatime
pour mount et n'écrirait pas de données atime
sur les systèmes de fichiers montés avec cette option. Cependant, l'arrêt de cette fonctionnalité est problématique car certaines applications reposent sur les données atime
, et elles échoueront si ces données ne sont pas disponibles.
relatime
. Relatime
effectue la maintenance de atime
, mais pas à chaque fois qu'on accède à un fichier. Avec l'activation de cette option, les données atime
sont écrites sur le disque seulement si le fichier a été modifié depuis que la dernière fois que les données atime
ont été mises à jour (mtime
), ou si le dernier accès au fichier a eu lieu depuis plus d'un certain temps (par défaut, un jour).
relatime
activée. Vous pouvez la supprimer pour n'importe quel système de fichiers avec l'option norelatime
.
3.10. Limitation de la consommation
Le Dynamic Power Capping est une fonctionnalité disponible sur les serveurs sélectionnés ProLiant et BladeSystem. Elle permet aux administrateurs systèmes de limiter la consommation de l'alimentation d'un serveur ou d'un groupe de serveurs. Cette limitation est une limite définitive que le serveur ne pourra pas dépasser, peu importe sa charge de travail. Celle-ci n'aura aucun effet jusqu'à ce que le serveur n'atteigne la limite de consommation. À ce moment, un processeur de gestion ajustera les états P (ou P-states) du CPU, et la limitation d'horloge afin de limiter l'énergie consommée.
/dev/hpilo/dXccbN
. Le noyau inclut aussi une extension de l'interface hwmon
sysfs
pour prendre en charge les fonctionnalités de limitation de l'alimentation (« Power capping ») et un pilote hwmon
pour les jauges d'alimentation ACPI 4.0 qui utilisent l'interface sysfs
. Ensemble, ces fonctionnalités permettent au système d'exploitation et aux outils de l'espace utilisateur de lire la valeur configurée pour la limitation de l'alimentation ainsi que l'utilisation actuelle de l'alimentation du système.
Le gestionnaire de nœuds Intel impose une limitation de la consommation aux systèmes, à l'aide du processeur des états P et T (T-states et P-states) pour limiter la performance du CPU et par conséquent la consommation de l'alimentation. En définissant une politique de gestion de l'alimentation, les administrateurs peuvent configurer les systèmes afin qu'ils utilisent moins d'énergie lorsque les charges du système sont basses, par exemple pendant la nuit ou les week-ends.
3.11. Gestion améliorée de l'alimentation des graphismes
La signalisation différentielle à basse tension (de l'anglais, low-voltage differential signalling, ou LVDS) est un système transportant des signaux électroniques sur des fils de cuivre. Une application importante de ce système est la transmission d'informations de pixels sur les écrans LCD (de l'anglais, liquid crystal display) d'ordinateurs portables. Tous les affichages possèdent des fréquences de rafraîchissement — la fréquence à laquelle ils reçoivent des nouvelles données depuis un contrôleur graphique et redessinent l'image à l'écran. Habituellement, l'écran reçoit de nouvelles données soixante fois par seconde (une fréquence de 60 Hz). Lorsqu'un écran et un contrôleur graphique sont liés par LVDS, le système LVDS utilise de l'énergie à chaque cycle de rafraîchissement. En période d'inactivité, la fréquence de rafraîchissement de nombreux écrans LCD peut descendre jusqu'à 30 Hz sans que cela ne puisse particulièrement se remarquer (contrairement aux moniteurs à tube cathodique (ou CRT), pour lesquels la baisse de la fréquence de rafraîchissement produit un scintillement distinct). Le pilote des adaptateurs graphiques Intel, qui est intégré dans le noyau utilisé dans Red Hat Enterprise Linux 7 effectue cette baisse d'horloge automatiquement, et permet d'économiser environ 0.5 W lorsque l'écran est inactif.
La mémoire vive dynamique synchrone (ou SDRAM) — comme celle utilisée pour la mémoire vidéo dans les adaptateurs graphiques — est rechargée des milliers de fois par seconde de manière à ce que les cellules de mémoire individuelles puissent retenir les données stockées en elles. À part sa fonction principale de gestion de données circulant vers et hors de la mémoire, le contrôleur de mémoire est habituellement responsable de l'initiation de ces cycles de rafraîchissement. Toutefois, SDRAM possède aussi un mode de rafraîchissement de basse consommation. Dans ce mode, la mémoire utilise un compteur interne pour générer ses propres cycles de rafraîchissement, permettant ainsi au système de fermer le contrôleur de mémoire sans pour mettre en danger les données présentes en mémoire. Le noyau utilisé dans Red Hat Enterprise Linux 7 peut ainsi déclencher le rafraîchissement automatique de la mémoire avec les adaptateurs graphiques d'Intel lorsqu'ils sont inactifs, ce qui permet déconomiser autour de 0,8 W.
Les GPUs (de l'anglais, graphical processing units) typiques contiennent des horloges internes gouvernant différentes parties de leur circuiterie interne. Le noyau utilisé dans Red Hat Enterprise Linux 7 peut réduire la fréquence de certaines horloges internes des GPUs d'Intel et d'ATI. La réduction du nombre de cycles effectués par les composants GPU sur un temps donné permet d'économiser de l'énergie qu'ils auraient consommé lors de cycles qu'ils n'avaient pas à effectuer. Le noyau réduit automatiquement la vitesse de ces horloges lorsque le GPU est inactif, et l'augmente lorsque l'activité de celui-ci augmente. La réduction des cycles d'horloge des GPUs peut vous économiser jusqu'à 5 W.
Les pilotes graphiques Intel et ATI dans Red Hat Enterprise Linux 7 peuvent détecter lorsqu'aucun moniteur n'est attaché à un adaptateur et éteint ainsi complètement le GPU. Cette fonctionnalité est particulièrement significative pour les serveurs ne possédant pas de moniteur de manière régulière.
3.12. RFKill
/dev/rfkill
, qui contient l'état actuel de tous les transmetteurs radio sur le système. Chaque périphérique possède son propre état RFKill enregistré dans sysfs
. De plus, RFKill fournit des uevents pour chaque changement d'état dans un périphérique pour lequel RFKill est activé.
rfkill list
pour obtenir une liste des périphériques, chacun d'entre eux aura un numéro d'index qui lui est associé, commençant par 0
. Vous pourrez utiliser ce numéro d'index pour dire à rfkill de bloquer ou débloquer un service, par exemple :
rfkill block 0
rfkill block wifi
rfkill block all
rfkill unblock
au lieu de rfkill block
. Pour obtenir la liste complète des catégories de périphériques que rfkill peut bloquer, exécutez rfkill help
Chapitre 4. Cas d'utilisation
4.1. Exemple — Serveur
Un serveur web nécessite un réseau et une E/S de disque. Selon la vitesse de connexion extérieure, 100 Mo/s peut suffire. Si la machine sert principalement à des pages statiques, la performance du CPU peut ne pas être très importante. Ainsi, les choix de gestion de l'alimentation qui s'offrent à vous incluent :
- aucun plugin de réseau ou de disque pour tuned.
- ALPM en marche.
- Gouverneur
ondemand
en marche. - carte réseau limitée à 100 Mo/s.
Un serveur de calcul nécessite principalement des CPU. Les choix de gestion de l'alimentation s'offrant à vous incluent :
- des plugins de réseau ou de disque pour tuned selon les tâches et l'endroit où sont stockées les données ; ou pour des systèmes en mode batch, tuned est totalement actif.
- selon l'utilisation, le gouverneur
performance
.
Un serveur mail nécessite principalement des E/S de disque et des CPU. Les choix de gestion de l'alimentation s'offrant à vous incluent :
- Le gouverneur
ondemand
activé, car les derniers pourcentages de la performance du CPU ne sont pas importants. - aucun plugin de réseau ou de disque pour tuned.
- la vitesse du réseau ne devrait pas être limitée, car les mails sont souvent internes et peuvent ainsi bénéficier d'un lien de 1 Go/s ou de 10 Go/s.
Les prérequis d'un serveur de fichiers sont similaires à ceux d'un serveur mail, mais selon le protocole utilisé, celui-ci peut nécessiter une meilleure performance CPU. Typiquement, les serveurs basés sur Samba requièrent davantage de CPU que NFS, et NFS en requiert plus que iSCSI. Même ainsi, vous devriez être en mesure d'utiliser le gouverneur ondemand
.
Typiquement, un serveur d'annuaire requiert moins d'E/S de disque, particulièrement s'il est équipé de suffisamment de RAM. La latence du réseau est importante, les E/S de réseau le sont moins. Prenez en considération le paramétrage de la latence du réseau à une vitesse de lien moindre, mais testez soigneusement ceci pour le réseau en question.
4.2. Exemple — Ordinateur portable
- La configuration du BIOS du système afin de désactiver tout le matériel que vous n'utilisez pas. Par exemple, les ports parallèles ou sériels, lecteurs de cartes, webcams, WiFi, Bluetooth, etc.
- Atténuez l'affichage dans des environnements plus sombres, lorsque vous n'avez pas besoin d'un éclairage maximum pour lire l'écran de manière confortable. Utilisez Système+Préférences → Gestion de l'alimentation sur le bureau GNOME, Lanceur d'application Kickoff+Ordinateur+Paramètres système+Avancé → Gestion de l'alimentation sur le bureau KDE ; ou gnome-power-manager ou xbacklight dans la ligne de commande ; ou utilisez les touches de fonction sur votre ordinateur portable.
- utilisez le gouverneur
ondemand
(par défaut activé dans Red Hat Enterprise Linux 7) - active l'économie d'énergie AC97 (activé par défaut dans Red Hat Enterprise Linux 7) :
echo Y > /sys/module/snd_ac97_codec/parameters/power_save
- active l'auto-suspension USB :
for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 1 > $i; done
Remarquez que l'auto-suspension USB ne fonctionne pas correctement avec tous les périphériques USB. - monte un système de fichiers à l'aide de relatime (par défaut dans Red Hat Enterprise Linux 7) :
mount -o remount,relatime point_de_montage
- réduit la luminosité de l'écran à
50
ou moins, par exemple :xbacklight -set 50
- active DPMS pour écran inactif :
xset +dpms; xset dpms 0 0 300
- désactive le Wi-Fi :
echo 1 > /sys/bus/pci/devices/*/rf_kill
Annexe A. Astuces pour les développeurs
- l'utilisation de threads.
- les réveils CPU inutiles et l'utilisation incorrecte des réveils. Si vous devez effectuer un réveil, faites-le en une seule fois et aussi vite que possible (en anglais, « race to idle »).
- l'utilisation de
[f]sync()
sans que cela ne soit nécessaire. - les interrogations actives inutiles, ou l'utilisation de délais d'attente réguliers et de courtes durées (réagit aux événements à la place).
- une utilisation des réveils inefficace.
- un accès disque inefficace. Utilisez des mémoires-tampons de grande taille pour éviter un accès au disque trop fréquent. N'écrivez qu'un grand bloc à la fois.
- une utilisation inefficace des minuteurs. Groupez les minuteurs sur plusieurs applications (ou même sur plusieurs systèmes) si possible.
- des E/S, ou une consommation d'énergie ou utilisation de mémoire excessive (y compris les fuites mémoires)
- l'exécution de calculs inutiles.
A.1. Utilisation de threads
Python uses the Global Lock Interpreter[1], so threading is profitable only for larger I/O operations. Unladen-swallow [2] is a faster implementation of Python with which you might be able to optimize your code.
Perl threads were originally created for applications running on systems without forking (such as systems with 32-bit Windows operating systems). In Perl threads, the data is copied for every single thread (Copy On Write). Data is not shared by default, because users should be able to define the level of data sharing. For data sharing the threads::shared module has to be included. However, data is not only then copied (Copy On Write), but the module also creates tied variables for the data, which takes even more time and is even slower. [3]
C threads share the same memory, each thread has its own stack, and the kernel does not have to create new file descriptors and allocate new memory space. C can really use the support of more CPUs for more threads. Therefore, to maximize the performance of your threads, use a low-level language like C or C++. If you use a scripting language, consider writing a C binding. Use profilers to identify poorly performing parts of your code. [4]
A.2. Réveils
#include <stdio.h> #include <stdlib.h> #include <sys/time.h> #include <sys/types.h> #include <sys/inotify.h> #include <unistd.h> int main(int argc, char *argv[]) { int fd; int wd; int retval; struct timeval tv; fd = inotify_init(); /* checking modification of a file - writing into */ wd = inotify_add_watch(fd, "./myConfig", IN_MODIFY); if (wd < 0) { printf("inotify cannot be used\n"); /* switch back to previous checking */ } fd_set rfds; FD_ZERO(&rfds); FD_SET(fd, &rfds); tv.tv_sec = 5; tv.tv_usec = 0; retval = select(fd + 1, &rfds, NULL, NULL, &tv); if (retval == -1) perror("select()"); else if (retval) { printf("file was modified\n"); } else printf("timeout\n"); return EXIT_SUCCESS; }
/proc/sys/fs/inotify/max_user_watches
et même s'il peut être changé, ceci n'est pas recommandé. De plus, au cas où inotify échouerait, le code devra utiliser une différente méthode de vérification, ce qui devrait signifier qu'il y aura de nombreuses occurrences de #if #define
dans le code source.
A.3. Fsync
Fsync
est connu pour être une opération utilisant beaucoup d'E/S, mais cela n'est pas totalement vrai.
fsync
et à cause des paramètres du système de fichiers (principalement ext3 avec le mode data-ordered), il y avait une longue latence lorsque rien ne se passait. Ceci pouvait ainsi prendre longtemps (jusqu'à 30 secondes) si un autre processus copiait un fichier de grande taille au même moment.
fsync
n'était pas du tout utilisé, des problèmes sont survenus lors du passage au système de fichiers ext4. Ext3 était réglé sur un mode de données ordonnées, qui vidait la mémoire toutes les quelques secondes et l'enregistrait sur un disque. Mais avec ext4 et laptop_mode, l'intervalle entre les sauvegardes est devenu plus long et des données pourvaient se perdre lorsque le système était éteint de manière inattendue. Maintenant ext4 est corrigé, mais nous devons quand même prendre en considération le design de nos applications en faisant attention, et utiliser fsync
lorsqu'approprié.
/* open and read configuration file e.g. ./myconfig */ fd = open("./myconfig", O_RDONLY); read(fd, myconfig_buf, sizeof(myconfig_buf)); close(fd); ... fd = open("./myconfig", O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR); write(fd, myconfig_buf, sizeof(myconfig_buf)); close(fd);
/* open and read configuration file e.g. ./myconfig */ fd = open("./myconfig", O_RDONLY); read(fd, myconfig_buf, sizeof(myconfig_buf)); close(fd); ... fd = open("./myconfig.suffix", O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR write(fd, myconfig_buf, sizeof(myconfig_buf)); fsync(fd); /* paranoia - optional */ ... close(fd); rename("./myconfig", "./myconfig~"); /* paranoia - optional */ rename("./myconfig.suffix", "./myconfig");
Annexe B. Historique des versions
Historique des versions | |||
---|---|---|---|
Version 2.1-3.1 | Thu Jun 22 2017 | Terry Chuang | |
| |||
Version 2.1-3 | Mon Oct 24 2016 | Marie Doleželová | |
| |||
Version 2.0-1 | Wed 11 Nov 2015 | Jana Heves | |
| |||
Version 1-3 | Fri 19 Jun 2015 | Jacquelynn Est | |
| |||
Version 1-2 | Wed 18 Feb 2015 | Jacquelynn Est | |
| |||
Version 1-1 | Thu Dec 4 2014 | Jacquelynn Est | |
| |||
Version 0.9-9 | Tue Jun 9 2014 | Yoana Ruseva | |
| |||
Version 0.9-1 | Fri May 9 2014 | Yoana Ruseva | |
| |||
Version 0.9-0 | Wed May 7 2014 | Yoana Ruseva | |
| |||
Version 0.1-1 | Thu Jan 17 2013 | Jack Reed | |
|