Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : ✔️ Machines virtuelles Linux
Résumé
Résolvez les problèmes de performances d’entrée et de sortie du processeur, de la mémoire et du disque et isolez les goulots d’étranglement sur les machines virtuelles Linux dans Azure.
Problèmes de performances et goulots d’étranglement
Les problèmes de performances peuvent se produire sur différents systèmes d’exploitation et applications. Chaque scénario nécessite une approche de résolution des problèmes ciblée. Dans les machines virtuelles Linux, les problèmes de performances apparaissent généralement dans une ou plusieurs zones de ressources principales : PROCESSEUR, mémoire, mise en réseau et entrée/sortie (E/S). Chaque ressource présente des symptômes distincts, qui se chevauchent souvent et nécessite différentes méthodes de diagnostic et stratégies de correction.
Dans de nombreux cas, les problèmes d’application ou de configuration provoquent une dégradation des performances, et non la plateforme elle-même. Par exemple, une application web avec une couche de mise en cache mal configurée peut acheminer des requêtes excessives vers le serveur d’origine au lieu de les traiter à partir du cache. Cette mauvaise configuration augmente la charge du processeur et les temps de réponse. De même, le placement du stockage peut affecter les charges de travail de base de données. Si le journal de rétablissement d’une base de données MySQL ou MariaDB réside sur le disque du système d’exploitation ou sur le stockage qui ne répond pas aux exigences de performances de la base de données, la contention d’E/S peut entraîner une latence accrue et une réduction des transactions par seconde (TPS).
La résolution efficace des problèmes commence par comprendre le problème et identifier l’emplacement du goulot d’étranglement dans la pile, qu’il s’agisse de processeur, de mémoire, de mise en réseau ou d’E/S. L’établissement d’une base de référence de performances est essentiel, car il vous permet de comparer les métriques avant et après les modifications et de déterminer si ces modifications entraînent une amélioration mesurable.
La résolution des problèmes de performances sur une machine virtuelle est fondamentalement la même que sur un système physique : l’objectif est de déterminer quelle ressource limite les performances globales. Les goulots d’étranglement existent toujours dans n’importe quel système. La résolution des problèmes de performances consiste à identifier le goulot d’étranglement actuel et, dans la mesure du possible, à le déplacer vers une ressource moins restrictive.
Ce guide vous aide à identifier et à résoudre les problèmes de performances dans les machines virtuelles Azure linux en vous concentrant sur l’isolation des goulots d’étranglement et l’application de diagnostics ciblés.
Identifier le goulot d’étranglement probable
Commencez à résoudre les problèmes en observant le comportement du système et les relations de métriques, et non l’utilisation individuelle des ressources en isolation. Les goulots d'étranglement des performances se manifestent souvent indirectement, et la ressource limitée n'est pas toujours la plus évidente.
Le tableau suivant associe les observations courantes et les modèles de métriques à la ressource la plus susceptible d'être examinée en premier.
| Observation ou signal | Possibles goulots d’étranglement à examiner | Justification |
|---|---|---|
| Moyenne de charge élevée avec faible utilisation du processeur | Disque (E/S) | Les processus sont bloqués en attente d’E/S plutôt que d’exécuter sur l’UC |
| Utilisation élevée du processeur avec une moyenne de charge faible | Conception d'applications ou charge de travail monofil | Le processeur est occupé, mais pas saturé sur les cœurs disponibles |
| Augmentation de la latence des requêtes sous charge, le processeur n’est pas saturé | Disque ou réseau | La latence augmente souvent avant que les limites d’utilisation ne soient atteintes |
| Fluctuations nettes de l’utilisation du processeur avec une charge de travail stable | Restrictions ou limites de rafale du processeur | La disponibilité du processeur peut varier en raison de contraintes de plateforme |
| Latence d’E/S élevée avec un débit faible | Saturation ou étranglement de disque | La latence augmente avant que les limites de bande passante ne soient atteintes |
| Augmentation progressive de l’utilisation de la mémoire au fil du temps | Fuite de mémoire ou croissance du cache | La pression de la mémoire se développe progressivement plutôt que immédiatement |
| Événements hors mémoire (OOMKilled) malgré l’espace disque disponible | Mémoire | La disponibilité du disque n’atténue pas l’épuisement de la RAM |
| Métriques de disque acceptables, mais les E/S d’application lentes | Modèle d’E/S d’application | Les petites opérations d'E/S ou les opérations synchrones limitent les performances. |
| Débit réseau inférieur aux attentes | Limites de taille de machine virtuelle ou de carte d’interface réseau | La bande passante réseau est limitée par la référence SKU de machine virtuelle |
| Dégradation des performances uniquement pendant les pics d’utilisation | Contrainte de capacité | Les limites de ressources sont atteintes uniquement en cas d’accès concurrentiel |
Après avoir identifié le modèle le plus pertinent, passez à la section de ressource correspondante pour obtenir des diagnostics et une validation détaillés.
Important
Les goulots d’étranglement sont identifiés par les relations entre les métriques, et non par les valeurs d’utilisation individuelles. Interpréter toujours les données processeur, mémoire, disque et réseau ensemble.
Collecter des insights sur les performances
Utilisez ces insights sur les performances pour vérifier si un goulot d’étranglement des ressources existe.
Différents outils collectent des données de performances en fonction de la ressource en cours d’examen. Le tableau suivant présente des exemples d’outils pour les ressources principales.
| Ressource | Outil |
|---|---|
| UC |
top, , htopmpstat, , pidstatvmstat |
| Disque |
iostat, iotop, vmstat |
| Network (Réseau) |
ip, vnstat, iperf3 |
| Mémoire |
free, top, vmstat |
Les sections suivantes décrivent les données de performances et les outils que vous pouvez utiliser pour l’examen.
Ressource processeur
L’utilisation du processeur représente le pourcentage de temps pendant lequel le processeur exécute activement le travail et le reste inactif. De même, les processus passent du temps dans le processeur (par exemple, 80 % usr d’utilisation) ou ne le font pas (comme 80 % d’inactivité). L’outil principal pour confirmer l’utilisation du processeur est top.
L’outil top s’exécute en mode interactif par défaut. Il actualise toutes les secondes et affiche les processus comme triés par utilisation du processeur :
top
top - 19:02:00 up 2:07, 2 users, load average: 1.04, 0.97, 0.96
Tasks: 191 total, 3 running, 188 sleeping, 0 stopped, 0 zombie
%Cpu(s): 29.2 us, 22.0 sy, 0.0 ni, 48.5 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem : 7990204 total, 6550032 free, 434112 used, 1006060 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7243640 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22804 root 20 0 108096 616 516 R 99.7 0.0 1:05.71 dd
1680 root 20 0 410268 38596 5644 S 3.0 0.5 2:15.10 python
772 root 20 0 90568 3240 2316 R 0.3 0.0 0:08.11 rngd
1472 root 20 0 222764 6920 4112 S 0.3 0.1 0:00.55 rsyslogd
10395 theuser 20 0 162124 2300 1548 R 0.3 0.0 0:11.93 top
1 root 20 0 128404 6960 4148 S 0.0 0.1 0:04.97 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.56 ksoftirqd/0
7 root rt 0 0 0 0 S 0.0 0.0 0:00.07 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root 20 0 0 0 0 S 0.0 0.0 0:06.00 rcu_sched
10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 lru-add-drain
11 root rt 0 0 0 0 S 0.0 0.0 0:00.05 watchdog/0
12 root rt 0 0 0 0 S 0.0 0.0 0:00.04 watchdog/1
13 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/1
14 root 20 0 0 0 0 S 0.0 0.0 0:00.21 ksoftirqd/1
16 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H
18 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
19 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd
21 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback
22 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kintegrityd
À présent, examinez la ligne du dd processus dans ce résultat :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22804 root 20 0 108096 616 516 R 99.7 0.0 1:05.71 dd
Vous pouvez voir que le dd processus consomme 99,7 % du processeur.
Note
Vous pouvez afficher l’utilisation par CPU dans l’outil
topen sélectionnant 1.L'outil
topaffiche une utilisation totale de plus de 100 % si le processus est multithread et s'étend sur plusieurs CPU.
Une autre référence utile est la moyenne de charge. La moyenne de charge indique une charge système moyenne en 1 minute, 5 minutes et intervalles de 15 minutes. La valeur indique le niveau de charge du système. L’interprétation de cette valeur dépend du nombre de processeurs disponibles. Par exemple, si la moyenne de charge est de 2 sur un système à processeur unique, le système est ainsi chargé que les processus commencent à mettre en file d’attente. S’il existe une moyenne de charge de 2 sur un système à quatre processeurs, il y a environ 50 % d’utilisation globale du processeur.
Note
Vous pouvez rapidement obtenir le nombre d’UC en exécutant la nproc commande.
Dans l’exemple précédent, la moyenne de charge est de 1,04. Il s’agit d’un système à deux processeurs, ce qui signifie qu’il existe environ 50 % d’utilisation du processeur. Vous pouvez vérifier ce résultat si vous remarquez la valeur du processeur inactive de 48,5 %. (Dans la sortie de la commande top, la valeur de l’UC inactive est affichée avant l’étiquette id.)
Utilisez la moyenne de charge comme vue d’ensemble rapide de l’exécution du système.
Exécutez la uptime commande pour obtenir la moyenne de charge.
Important
La moyenne de charge fournit un contexte pour l’utilisation du processeur. Une charge élevée avec un faible temps d'inactivité du processeur indique la saturation, tandis qu'une charge élevée avec un processeur inactif pointe souvent vers des goulots d'étranglement autres que le processeur.
Ressource disque (E/S)
Les termes suivants expliquent comment identifier et comprendre les compteurs de performances d’E/S.
| Terme | Description |
|---|---|
| Taille des E/S | Quantité de données traitées par transaction, généralement définies en octets. |
| Threads d’E/S | Nombre de processus qui interagissent avec l’appareil de stockage. Cette valeur dépend de l’application. |
| Taille des blocs | Taille d’E/S telle que définie par le périphérique de bloc sous-jacent. |
| Taille du secteur | Taille de chacun des secteurs au niveau du disque. Cette valeur est généralement de 512 octets. |
| IOPS (OPÉRATIONS D’E/S PAR SECONDE) | Opérations d'entrées/sorties par seconde. |
| Latence | Le temps nécessaire à une opération d’E/S pour se terminer. Cette valeur est généralement mesurée en millisecondes (ms). |
| Débit | Fonction de la quantité de données transférées sur une durée spécifique. Cette valeur est généralement définie en mégaoctets par seconde (Mo/s). |
IOPS
Les opérations de sortie d’entrée par seconde (IOPS) mesurent le nombre d’opérations d’entrée et de sortie (E/S) sur une durée spécifique, généralement en secondes. Les opérations d’E/S incluent à la fois des lectures et des écritures. Le système peut également compter les suppressions ou les mises au rebut comme des opérations contre le système de stockage. Chaque opération dispose d'une unité d'allocation correspondant à la taille des E/S.
Les applications définissent généralement la taille des E/S comme la quantité de données écrites ou lues par transaction. Une taille d’E/S courante est de 4 Ko. Toutefois, une plus petite taille d’E/S avec plus de threads entraîne un IOPS plus élevé. Étant donné que chaque transaction se termine rapidement en raison de sa petite taille, une taille d’E/S plus petite permet d’effectuer plus de transactions dans le même temps.
En revanche, si vous utilisez le même nombre de threads mais choisissez une taille d’E/S supérieure, les IOPS diminuent, car chaque transaction prend plus de temps. Toutefois, le débit augmente.
Prenons l’exemple suivant :
1 000 IOPS signifie que chaque seconde, mille opérations se terminent. Chaque opération prend environ une milliseconde. (Il y a 1 000 millisecondes en une seconde.) En théorie, chaque transaction a environ une milliseconde pour se terminer, ou environ une latence de 1 ms.
Si vous connaissez la valeur IOSize et les IOPS, vous pouvez calculer le débit en multipliant IOSize par IOPS.
Par exemple :
1 000 IOPS à 4 Ko IOSize = 4 000 Ko/s, ou 4 Mo/s (3,9 Mo/s pour être précis)
1 000 IOPS à 1M IOSize = 1 000 Mo/s, ou 1 Go/s (976 Mo/s pour être précis)
Vous pouvez écrire une version plus conviviale d’équation comme suit :
IOPS * IOSize = IOSize/s (Throughput)
Débit
Contrairement aux IOPS, le débit est une fonction de la quantité de données au fil du temps. Cette mesure signifie qu’au cours de chaque seconde, une certaine quantité de données est écrite ou lue. Vous mesurez cette vitesse en <quantité de données>/<>, ou mégaoctets par seconde (Mo/s).
Lorsque vous connaissez le débit et les valeurs de taille d’E/S, vous pouvez calculer les E/S par seconde en divisant le débit par la taille des E/S. Vous devez normaliser les deux valeurs dans la même unité de mesure. Par exemple, si la taille d’E/S est définie en kilo-octets (Ko), vous devez convertir le débit en Ko avant d’effectuer le calcul.
Le format d’équation est écrit comme suit :
Throughput / IOSize = IOPS
Pour mettre cette équation dans le contexte, envisagez un débit de 10 Mo/s à un IOSize de 4 Ko. Lorsque vous entrez les valeurs dans l’équation, le résultat est de 10 240/4 = 2 560 IOPS.
Note
10 Mo est exactement égal à 10 240 Ko.
Latence
La latence est la mesure du temps moyen nécessaire pour terminer chaque opération. Les E/S par seconde et la latence sont liées, car les deux concepts sont une fonction du temps. Par exemple, à 100 IOPS, chaque opération prend environ 10 ms. Mais la même quantité de données peut être récupérée encore plus rapidement à des E/S par seconde inférieures. La latence est également appelée temps de recherche.
Comprendre la sortie iostat
Dans le cadre du package sysstat, l’outil iostat fournit des insights sur les métriques de performances du disque et d’utilisation.
iostat peut aider à identifier les goulots d’étranglement liés au sous-système de disque.
Vous pouvez exécuter l’utilitaire à l’aide d’une iostat commande simple. La syntaxe de base est illustrée comme suit :
iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>
Les paramètres déterminent les informations iostat fournies. Sans paramètre de commande, iostat affiche les détails de base :
iostat
Linux 3.10.0-957.21.3.el7.x86_64 (rhel76) 08/05/2019 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
41.06 0.00 30.47 21.00 0.00 7.47
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 182.77 5072.69 1066.64 226090 47540
sdd 2.04 42.56 22.98 1897 1024
sdb 12.61 229.23 96065.51 10217 4281640
sdc 2.56 46.16 22.98 2057 1024
md0 2.67 73.60 45.95 3280 2048
Par défaut, iostat affiche les données de tous les dispositifs de bloc existants, bien qu’il fournisse des données minimales pour chaque dispositif. Pour identifier les problèmes, utilisez des paramètres qui fournissent des données étendues, comme le débit, les IOPS, la taille de file d’attente et la latence.
Lancez iostat en spécifiant des déclencheurs :
iostat -dxctm 1
Pour développer davantage les iostat résultats, utilisez les paramètres suivants.
| Paramètre | Action |
|---|---|
-d |
Affichez le rapport d’utilisation de l’appareil. |
-x |
Afficher les statistiques étendues. Ce paramètre est important, car il fournit des tailles d’IOPS, de latence et de file d’attente. |
-c |
Affichez le rapport d’utilisation du processeur. |
-t |
Imprimez l’heure de chaque rapport affiché. Ce paramètre est utile pour les longues exécutions. |
-m |
Affichez des statistiques en mégaoctets par seconde, une forme plus lisible par l’homme. |
Le chiffre 1 dans la commande indique iostat d’actualiser toutes les secondes. Pour arrêter l’actualisation, sélectionnez Ctrl+C.
Si vous incluez les paramètres supplémentaires, la sortie ressemble au texte suivant :
iostat -dxctm 1
Linux 3.10.0-957.21.3.el7.x86_64 (rhel76) 08/05/2019 _x86_64_ (1 CPU)
08/05/2019 07:03:36 PM
avg-cpu: %user %nice %system %iowait %steal %idle
3.09 0.00 2.28 1.50 0.00 93.14
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.02 0.52 9.66 2.46 0.31 0.10 70.79 0.27 23.97 6.68 91.77 2.94 3.56
sdd 0.00 0.00 0.12 0.00 0.00 0.00 64.20 0.00 6.15 6.01 12.50 4.44 0.05
sdb 0.00 22.90 0.47 0.45 0.01 5.74 12775.08 0.17 183.10 8.57 367.68 8.01 0.74
sdc 0.00 0.00 0.15 0.00 0.00 0.00 54.06 0.00 6.46 6.24 14.67 5.64 0.09
md0 0.00 0.00 0.15 0.01 0.00 0.00 89.55 0.00 0.00 0.00 0.00 0.00 0.00
Comprendre les valeurs
Les colonnes principales de la iostat sortie sont indiquées dans le tableau suivant.
| Colonne | Description |
|---|---|
r/s |
Lectures par seconde (IOPS) |
w/s |
Écritures par seconde (IOPS) |
rMB/s |
Lecture de mégaoctets par seconde (débit) |
wMB/s |
Écrire des mégaoctets par seconde (débit) |
avgrq-sz |
Taille moyenne des E/S dans les secteurs ; multipliez ce nombre par la taille du secteur, qui est généralement de 512 octets, pour obtenir la taille d’E/S en octets (taille d’E/S) |
avgqu-sz |
Taille moyenne de la file d’attente (nombre d’opérations d’E/S en attente de service) |
await |
Temps moyen en millisecondes pour les E/S servies par l’appareil (latence) |
r_await |
Temps de lecture moyen en millisecondes pour les E/S servies par l’appareil (latence) |
w_await |
Temps de lecture moyen en millisecondes pour les E/S servies par l’appareil (latence) |
Les données présentées par iostat sont informationnelles, mais la présence de certaines données dans certaines colonnes ne signifie pas qu’il existe un problème. Capturez et analysez toujours les données à partir de iostat pour identifier d'éventuels goulots d'étranglement. Une latence élevée peut indiquer que le disque atteint un point de saturation.
Note
Vous pouvez utiliser la pidstat -d commande pour afficher les statistiques d’E/S par processus.
Important
Les valeurs individuelles iostat n’indiquent pas de problème par eux-mêmes. Une latence élevée ou une profondeur de file d’attente soutenue sous charge est un indicateur plus fort de la saturation du disque.
Ressource de réseau
Les réseaux peuvent rencontrer deux goulots d’étranglement principaux : une bande passante faible et une latence élevée.
Vous pouvez utiliser vmstat pour capturer les détails de la bande passante en direct. Toutefois, vnstat n’est pas disponible dans toutes les distributions. L’outil largement disponible iptraf-ng est une autre option permettant d’afficher le trafic d’interface en temps réel.
Latence du réseau
Vous pouvez déterminer la latence réseau entre deux systèmes différents à l’aide de la commande simple ping dans INTERNET Control Message Protocol (ICMP) :
ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=5.33 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=5.24 ms
^C
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 5.240/5.291/5.339/0.035 ms
Pour arrêter l’activité ping, sélectionnez Ctrl+C.
Bande passante réseau
Vérifiez la bande passante réseau à l’aide d’outils tels que iperf3. L’outil iperf3 fonctionne sur le modèle serveur/client. Démarrez l’application en spécifiant l’indicateur -s sur le serveur. Les clients se connectent ensuite au serveur en spécifiant l’adresse IP ou le nom de domaine complet (FQDN) du serveur conjointement avec l’indicateur -c . Les extraits de code suivants montrent comment utiliser l’outil iperf3 sur le serveur et le client.
Serveur
iperf3 -s----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------Client
iperf3 -c 10.1.0.4
Connecting to host 10.1.0.4, port 5201
[ 5] local 10.1.0.4 port 60134 connected to 10.1.0.4 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 5.78 GBytes 49.6 Gbits/sec 0 1.25 MBytes
[ 5] 1.00-2.00 sec 5.81 GBytes 49.9 Gbits/sec 0 1.25 MBytes
[ 5] 2.00-3.00 sec 5.72 GBytes 49.1 Gbits/sec 0 1.25 MBytes
[ 5] 3.00-4.00 sec 5.76 GBytes 49.5 Gbits/sec 0 1.25 MBytes
[ 5] 4.00-5.00 sec 5.72 GBytes 49.1 Gbits/sec 0 1.25 MBytes
[ 5] 5.00-6.00 sec 5.64 GBytes 48.5 Gbits/sec 0 1.25 MBytes
[ 5] 6.00-7.00 sec 5.74 GBytes 49.3 Gbits/sec 0 1.31 MBytes
[ 5] 7.00-8.00 sec 5.75 GBytes 49.4 Gbits/sec 0 1.31 MBytes
[ 5] 8.00-9.00 sec 5.75 GBytes 49.4 Gbits/sec 0 1.31 MBytes
[ 5] 9.00-10.00 sec 5.71 GBytes 49.1 Gbits/sec 0 1.31 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 57.4 GBytes 49.3 Gbits/sec 0 sender
[ 5] 0.00-10.04 sec 57.4 GBytes 49.1 Gbits/sec receiver
iperf Done.
Le tableau suivant présente certains paramètres courants iperf3 pour le client.
| Paramètre | Description |
|---|---|
-P |
Spécifie le nombre de flux clients parallèles à exécuter. |
-R |
Renverse le sens du trafic. Par défaut, le client envoie des données au serveur. |
--bidir |
Teste à la fois le chargement et le téléchargement. |
Important
Les performances réseau dans Azure sont limitées par taille de machine virtuelle. Les limitations de débit proviennent souvent de limites de machine virtuelle ou de disque plutôt que du réseau lui-même.
Ressource mémoire
La mémoire est une autre ressource de résolution des problèmes à vérifier, car les applications peuvent ou ne pas utiliser une partie de la mémoire. Vous pouvez utiliser des outils comme free et top pour examiner l’utilisation globale de la mémoire et déterminer la quantité de mémoire consommée par différents processus :
free -m
total used free shared buff/cache available
Mem: 7802 435 5250 9 2117 7051
Swap: 0 0 0
Dans les systèmes Linux, il est courant de voir une utilisation de la mémoire de 99 %. Dans la free sortie, il existe une colonne nommée buff/cache. Le noyau Linux utilise la mémoire libre (inutilisée) pour mettre en cache les demandes d’E/S pour améliorer les temps de réponse. Ce processus est appelé cache de page. Pendant la pression de la mémoire (scénarios de faible mémoire), le noyau libère la mémoire du cache de pages pour que les applications puissent utiliser cette mémoire.
Dans la sortie, la freecolonne disponible indique la quantité de mémoire disponible pour les processus à consommer. Cette valeur est calculée en ajoutant les quantités de mémoire buff/cache et de mémoire libre.
Vous pouvez configurer la top commande pour trier les processus en fonction de l’utilisation de la mémoire. Par défaut, top trie par pourcentage de processeur (%). Pour trier par utilisation de la mémoire (%), sélectionnez Maj+M lorsque vous exécutez top. Le texte suivant montre la sortie de la top commande :
top
top - 22:40:15 up 5:45, 2 users, load average: 0.08, 0.08, 0.06
Tasks: 194 total, 2 running, 192 sleeping, 0 stopped, 0 zombie
%Cpu(s): 12.3 us, 41.8 sy, 0.0 ni, 45.4 id, 0.0 wa, 0.0 hi, 0.5 si, 0.0 st
KiB Mem : 7990204 total, 155460 free, 5996980 used, 1837764 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 1671420 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
45283 root 20 0 5655348 5.3g 512 R 99.7 69.4 0:03.71 tail
3124 omsagent 20 0 415316 54112 5556 S 0.0 0.7 0:30.16 omsagent
1680 root 20 0 413500 41552 5644 S 3.0 0.5 6:14.96 python
[...]
La RES colonne indique la mémoire résidente. Cette valeur représente l’utilisation réelle du processus. L’outil top fournit une sortie similaire à free en termes de kilo-octets (ko).
L’utilisation de la mémoire peut augmenter plus que prévu si l’application rencontre des fuites de mémoire. Dans un scénario de fuite de mémoire, les applications ne peuvent pas libérer de pages de mémoire qui ne sont plus utilisées.
Voici une autre commande utilisée pour afficher les principaux processus consommant de la mémoire :
ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
Le texte suivant montre l’exemple de sortie de la commande :
ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
PID COMMAND USER COMMAND %CPU %MEM
45922 tail root tail -f /dev/zero 82.7 61.6
[...]
Vous pouvez identifier la pression de la mémoire à partir des événements OOM (Out of Memory) Kill, comme le montre l'exemple de sortie suivant :
Jun 19 22:42:14 rhel78 kernel: Out of memory: Kill process 45465 (tail) score 902 or sacrifice child
Jun 19 22:42:14 rhel78 kernel: Killed process 45465 (tail), UID 0, total-vm:7582132kB, anon-rss:7420324kB, file-rss:0kB, shmem-rss:0kB
Le système déclenche une situation de mémoire insuffisante (OOM) après que la RAM (mémoire physique) et le SWAP (espace disque) sont consommés.
Note
Utilisez la pidstat -r commande pour afficher les statistiques de mémoire par processus.
Important
L’utilisation élevée de la mémoire est normale dans Linux. La pression de la mémoire se manifeste par une faible mémoire disponible, une activité de swapping ou des événements OOMkilled, et non par l'utilisation du cache.
Déterminer si une contrainte de ressource existe
Vous pouvez identifier les contraintes de ressources en mettant en corrélation les indicateurs avec la configuration actuelle.
Voici un exemple de contrainte de disque :
Une machine virtuelle D2s_v3 est capable de 48 Mo/s de débit non mis en cache. Sur cette machine virtuelle, un disque P30 est attaché capable de 200 Mo/s. L’application nécessite un minimum de 100 Mo/s.
Dans cet exemple, la ressource de limitation est le débit de la machine virtuelle globale. L’exigence de l’application par rapport à ce que peut fournir la configuration du disque ou de la machine virtuelle indique la ressource limitante.
Si l'application nécessite la mesure1 de la ressource, et que la configuration actuelle de la ressource est capable de fournir uniquement la mesure2, cette exigence peut être un facteur contraignant.
Définir la ressource de limitation
Après avoir identifié un goulot d’étranglement des ressources dans la configuration actuelle, évaluez les modifications possibles et évaluez l’impact sur la charge de travail. Dans certains cas, le goulot d’étranglement existe en tant que choix d’optimisation des coûts et l’application continue à fonctionner dans des limites de performances acceptables.
Par exemple, lorsqu’une application nécessite 128 Go (mesure) de RAM (ressource), mais que la configuration actuelle fournit seulement 64 Go (ressource), la mémoire devient un goulot d’étranglement pour la charge de travail.
Après avoir identifié la ressource de goulot d’étranglement, définissez la contrainte et prenez les mesures appropriées. Cette approche s’applique à toutes les ressources.
Certains goulots d’étranglement résultent de configurations d’économie de coûts et sont acceptables lorsque l’application peut les tolérer. Lorsque l’application ne peut pas tolérer les ressources réduites, la configuration devient problématique.
Apporter des modifications en fonction des données obtenues
La conception pour les performances ne consiste pas à résoudre des problèmes, mais à comprendre où le goulot d’étranglement suivant peut se produire et comment le contourner. Les goulots d’étranglement existent toujours et l’on ne peut que les déplacer à un autre endroit dans la conception.
Par exemple, si les performances du disque limitent l’application, vous pouvez augmenter la taille du disque pour permettre un débit plus élevé. Toutefois, le réseau devient alors le goulot d’étranglement suivant. Étant donné que les ressources sont limitées, il n’existe aucune configuration idéale et vous devez résoudre régulièrement les problèmes.
Après avoir collecté des données à partir des étapes précédentes, ajustez le système en fonction des données réelles et mesurables. Comparez ces modifications à la base de référence établie précédemment pour vérifier une amélioration mesurable.
Prenons l’exemple suivant :
Une base de référence a montré une utilisation de 100 % du processeur sur un système à deux processeurs avec une charge moyenne de 4, indiquant une mise en file d’attente des requêtes. Après le redimensionnement sur huit processeurs, la même charge de travail a réduit l’utilisation du processeur à 25 % et a réduit la moyenne de charge à 2.
Dans cet exemple, vous voyez une différence mesurable lorsque vous comparez les résultats obtenus aux ressources modifiées. Avant la modification, il y avait une contrainte de ressource claire. Mais après la modification, il y a suffisamment de ressources pour augmenter la charge.
Migrer d’un site local vers le cloud
Plusieurs différences de performances peuvent affecter les migrations d’une configuration locale vers le cloud computing.
UC
Selon l’architecture, une configuration locale peut exécuter des processeurs qui ont des vitesses d’horloge plus élevées et des caches plus volumineux. Le résultat est une diminution des temps de traitement et des instructions plus élevées par cycle (IPC). Il est important de comprendre les différences entre les modèles de processeurs et les indicateurs lorsque vous travaillez sur des migrations. Dans ce cas, une relation un à un entre les nombres de cœurs peut ne pas suffire.
Par exemple :
Dans un système local qui a quatre PROCESSEURs qui s’exécutent à 3,7 GHz, il y a un total de 14,8 GHz disponibles pour le traitement. Si vous créez l’équivalent en nombre de cœurs en utilisant une machine virtuelle D4s_v3 alimentée par des processeurs de 2,1 GHz, la machine virtuelle migrée dispose de 8,1 GHz disponibles pour le traitement. Cela représente environ une diminution de 44 % des performances.
Disque
Les performances des disques dans Azure dépendent du type et de la taille du disque, à l’exception du disque Ultra, qui offre une flexibilité en matière de taille, d’E/S par seconde et de débit. La taille du disque définit les limites d’E/S par seconde et de débit.
La latence dépend du type de disque plutôt que de la taille du disque. La plupart des solutions de stockage locales utilisent des tableaux de disques avec des caches DRAM. Ce type de cache offre une latence inférieure à la milliseconde (environ 200 microsecondes) et un débit en lecture/écriture élevé (IOPS).
Les latences Azure moyennes sont indiquées dans le tableau suivant.
| Type de disque | Latence |
|---|---|
| Disque Ultra/SSD Premium v2 | μs à trois chiffres (microsecondes) |
| SSD Premium/SSD Standard | Ms à un chiffre (millisecondes) |
| HDD Standard | ms de deux chiffres (millisecondes) |
Note
Un disque est limité s’il atteint ses limites d’IOPS ou de bande passante. Sinon, la latence peut atteindre 100 millisecondes ou plus.
La différence de latence entre une configuration locale (souvent inférieure à une milliseconde) et un SSD Premium (millisecondes à un chiffre) peut être un facteur de limitation. Notez les différences de latence entre les offres de stockage et sélectionnez l’offre qui répond le mieux aux exigences de votre application.
Network (Réseau)
La plupart des configurations réseau locales utilisent des liens de 10 Gbits/s. Dans Azure, la taille des machines virtuelles détermine directement la bande passante réseau. Certaines bande passantes réseau peuvent dépasser 40 Gbits/s. Veillez à sélectionner une taille qui fournit suffisamment de bande passante pour vos besoins d’application. Dans la plupart des cas, les limites de débit de la machine virtuelle ou du disque, plutôt que du réseau, sont le facteur de limitation.
Mémoire
Sélectionnez une taille de machine virtuelle qui a suffisamment de RAM pour ce qui est actuellement configuré.
Diagnostics de performances (PerfInsights)
Azure recommande l'utilisation de PerfInsights pour les problèmes de performances de machines virtuelles. Il fournit les meilleures pratiques et les onglets d’analyse dédiés pour le processeur, la mémoire et les E/S. Vous pouvez l’exécuter à la demande via le portail Azure ou à partir de la machine virtuelle, puis partager les données avec l’équipe du support technique Azure.
Exécuter PerfInsights
PerfInsights est disponible pour le système d’exploitation Linux . Vérifiez que la distribution Linux figure dans la liste des distributions prises en charge pour les diagnostics de performances pour Linux.
Exécuter et analyser des rapports via le Portail Azure
Lorsque vous installez PerfInsights via le portail Azure, le logiciel installe une extension sur la machine virtuelle. Vous pouvez également installer PerfInsights en tant qu’extension en accédant directement aux extensions, puis en sélectionnant une option de diagnostics de performances.
Option 1 du portail Azure
Accédez au volet de la machine virtuelle et sélectionnez Diagnostic de performance. Installez-la ensuite sur la machine virtuelle cible (utilise des extensions).
Option 2 du portail Azure
Accédez à l’onglet Diagnostiquer et résoudre les problèmes dans le tableau de bord de la machine virtuelle, puis recherchez le lien Résoudre les problèmes sous Problèmes de performance de la machine virtuelle.
Éléments à rechercher dans le rapport PerfInsights
Après avoir exécuté le rapport PerfInsights, l’emplacement du contenu dépend de l’exécution du rapport via le portail Azure ou en tant qu’exécutable. Pour l’une ou l’autre option, vous pouvez accéder au dossier de journal généré ou (si dans le portail Azure) télécharger localement pour l’analyse.
Exécuter via le portail Azure
Ouvrez le rapport PerfInsights. L’onglet Résultats enregistre toute valeur aberrante en termes de consommation de ressources. S’il existe des instances de performances lentes en raison d’une utilisation spécifique des ressources, l’onglet Résultats classe chaque recherche comme impact élevé ou impact moyen .
Par exemple, dans le rapport suivant, vous voyez que l’outil a détecté des résultats d’impact moyen liés au stockage et que vous voyez les recommandations correspondantes. Si vous développez l’événement Findings , vous voyez plusieurs détails clés.
Pour plus d’informations sur PerfInsights dans le système d’exploitation Linux, consultez Comment utiliser PerfInsights Linux dans Microsoft Azure.