Résoudre les problèmes de performances et isoler les goulots d’étranglement dans Linux
Problèmes de performances et goulots d’étranglement
Lorsque des problèmes de performances se produisent dans différents systèmes d’exploitation et applications, chaque cas nécessite une approche unique pour résoudre les problèmes. Le processeur, la mémoire, la mise en réseau et l’entrée/sortie (E/S) sont des domaines clés où des problèmes peuvent se produire. Chacun de ces domaines présente des symptômes différents (parfois simultanément) et nécessite des diagnostics et des solutions différents.
Les problèmes de performances peuvent être causés par une configuration incorrecte de l’application ou de l’installation. Par exemple, une application web qui a une couche de mise en cache qui n’est pas correctement configurée. Cette situation déclenche davantage de requêtes qui reviennent au serveur d’origine au lieu d’être traitées à partir d’un cache.
Dans un autre exemple, le journal de restauration par progression d’une base de données MySQL ou MariaDB se trouve sur le disque du système d’exploitation ou sur un disque qui ne répond pas aux exigences de la base de données. Dans ce scénario, vous pouvez voir moins de transactions par seconde (TPS) en raison de la concurrence pour les ressources et des temps de réponse plus élevés (latence).
Si vous comprenez parfaitement le problème, vous pouvez mieux identifier où regarder dans la pile (processeur, mémoire, mise en réseau, E/S). Pour résoudre les problèmes de performances, vous devez établir une base de référence qui vous permet de comparer les métriques après avoir apporté des modifications et d’évaluer si les performances globales ont été améliorées.
La résolution des problèmes de performances d’une machine virtuelle n’est pas différente de la résolution d’un problème de performances sur un système physique. Il s’agit de déterminer quelle ressource ou quel composant est à l’origine d’un goulot d’étranglement dans le système.
Il est important de comprendre que les goulots d’étranglement existent toujours. La résolution des problèmes de performances consiste à comprendre où se produit un goulot d’étranglement et à le déplacer vers une ressource moins incriminant.
Ce guide vous aide à découvrir et à résoudre les problèmes de performances dans Azure Machines Virtuelles dans l’environnement Linux.
Obtenir des pointeurs de performances
Vous pouvez obtenir des pointeurs de performances qui confirment ou nient si la contrainte de ressource existe.
En fonction de la ressource examinée, de nombreux outils peuvent vous aider à obtenir des données relatives à cette ressource. Le tableau suivant contient des exemples pour les ressources main.
| Resource | Outil |
|---|---|
| UC | top, htop, mpstat, pidstat, vmstat |
| Disque | iostat, iotop, vmstat |
| Réseau | ip, vnstat, iperf3 |
| Mémoire | free, top, vmstat |
Les sections suivantes traitent des pointeurs et des outils que vous pouvez utiliser pour rechercher les ressources main.
Ressource d’UC
Un certain pourcentage de processeur est utilisé ou non. De même, les processus passent du temps dans le processeur (par exemple, 80 % usr d’utilisation) ou non (par exemple, 80 % d’inactivité). L’outil main pour confirmer l’utilisation du processeur est top.
L’outil top s’exécute en mode interactif par défaut. Il s’actualise toutes les secondes et affiche les processus comme triés par utilisation du processeur :
[root@rhel78 ~]$ 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 dd ligne de processus à partir de cette sortie :
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.
Remarque
Vous pouvez afficher l’utilisation par processeur 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 processeurs.
Une autre référence utile est la moyenne de charge. La moyenne de charge indique une charge système moyenne par intervalles de 1 minute, 5 minutes et 15 minutes. La valeur indique le niveau de charge du système. L’interprétation de cette valeur dépend du nombre d’uc disponibles. Par exemple, si la charge moyenne est de 2 sur un système à un processeur, le système est chargé de telle sorte que les processus commencent à mettre en file d’attente. S’il y a une charge moyenne de 2 sur un système à quatre processeurs, l’utilisation globale du processeur est d’environ 50 %.
Remarque
Vous pouvez obtenir rapidement le nombre de processeurs en exécutant la nproc commande .
Dans l’exemple précédent, la charge moyenne est de 1,04. Il s’agit d’un système à deux processeurs, ce qui signifie qu’il y a environ 50 % d’utilisation du processeur. Vous pouvez vérifier ce résultat si vous remarquez la valeur du processeur inactif de 48,5 %. (Dans la sortie de la top commande, la valeur du processeur inactif est affichée avant l’étiquette id .)
Utilisez la moyenne de charge comme vue d’ensemble rapide des performances du système.
Exécutez la uptime commande pour obtenir la moyenne de charge.
Ressource de disque (E/S)
Lorsque vous examinez les problèmes de performances d’E/S, les termes suivants vous aident à comprendre où le problème se produit.
| Term | Description |
|---|---|
| Taille d’E/S | Quantité de données traitées par transaction, généralement définie en octets. |
| Threads d’E/S | Nombre de processus qui interagissent avec le périphérique de stockage. Cette valeur dépend de l’application. |
| Taille du bloc | Taille d’E/S définie par l’appareil de bloc de stockage. |
| Taille du secteur | Taille de chacun des secteurs sur le disque. Cette valeur est généralement de 512 octets. |
| E/S par seconde | Opérations de sortie d’entrée par seconde. |
| Latence | Temps nécessaire à la fin d’une opération d’E/S. 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 période spécifique. Cette valeur est généralement définie en mégaoctets par seconde (Mo/s). |
E/S par seconde
Les opérations de sortie d’entrée par seconde (IOPS) sont une fonction du nombre d’opérations d’entrée et de sortie (E/S) mesurées sur une certaine période (dans ce cas, secondes). Les opérations d’E/S peuvent être des lectures ou des écritures. Les suppressions ou les abandons peuvent également être comptabilisés comme une opération sur le système de stockage. Chaque opération a une unité d’allocation qui correspond également à la taille d’E/S.
La taille des E/S est généralement définie au niveau de l’application en tant que quantité de données écrites ou lues par transaction. Une taille d’E/S couramment utilisée est 4K. Toutefois, une taille d’E/S plus petite qui contient plus de threads génère une valeur d’IOPS plus élevée. Étant donné que chaque transaction peut être effectuée relativement rapidement (en raison de sa petite taille), une E/S plus petite permet d’effectuer plus de transactions dans le même laps de temps.
Au contraire, supposons que vous avez le même nombre de threads, mais que vous utilisez une E/S plus grande. Les IOPS diminuent, car chaque transaction prend plus de temps. Toutefois, le débit augmente.
Prenons l'exemple suivant :
1 000 IOPS signifie que pour 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 à terminer, ou une latence d’environ 1 ms.
En connaissant 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)
Une version plus adaptée aux équations peut être écrite comme suit :
IOPS * IOSize = IOSize/s (Throughput)
Débit
Contrairement aux IOPS, le débit est une fonction de la quantité de données dans le temps. Cela signifie qu’au cours de chaque seconde, une certaine quantité de données est écrite ou lue. Cette vitesse est mesurée en <quantité de temps de données>/<, ou mégaoctets par seconde (Mo/>s).
Si vous connaissez les valeurs débit et IOSize, vous pouvez calculer les IOPS en divisant le débit par IOSize. Vous devez normaliser les unités à la plus petite connotation. Par exemple, si IOSize est défini en kilo-octets (Ko), le débit doit être converti.
Le format de l’équation est écrit comme suit :
Throughput / IOSize = IOPS
Pour mettre cette équation en contexte, envisagez un débit de 10 Mo/s à une taille IOS de 4K. Lorsque vous entrez les valeurs dans l’équation, le résultat est 10 240/4 = 2 560 IOPS.
Remarque
10 Mo est précisément égal à 10 240 Ko.
Latence
La latence est la mesure du temps moyen nécessaire à chaque opération pour se terminer. Les IOPS 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 avec des IOPS inférieures. La latence est également appelée temps de recherche.
Comprendre la sortie iostat
Dans le cadre du package sysstat, l’outil fournit des insights sur les iostat métriques de performances et d’utilisation des disques. iostat peut aider à identifier les goulots d’étranglement liés au sous-système de disque.
Vous pouvez exécuter iostat dans une commande simple. La syntaxe de base est la suivante :
iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>
Les paramètres déterminent les informations iostat fournies. Sans aucun paramètre de commande, iostat affiche les détails de base :
[host@rhel76 ~]$ 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 appareils de bloc existants, bien que des données minimales soient fournies pour chaque appareil. Les paramètres disponibles permettent d’identifier les problèmes en fournissant des données étendues (comme le débit, les IOPS, la taille de la file d’attente et la latence).
Exécutez iostat en spécifiant les déclencheurs :
sudo 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 des statistiques étendues. Ce paramètre est important, car il fournit des IOPS, une latence et des tailles 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 exécutions longues. |
-m |
Affiche les 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 :
[host@rhel76 ~]$ 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 main 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 |
Mégaoctets de lecture par seconde (débit) |
wMB/s |
Écrire des mégaoctets par seconde (débit) |
avgrq-sz |
Taille moyenne des E/S dans les secteurs ; multiplier 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 file d’attente en attente d’être servies) |
await |
Temps moyen en millisecondes pour les E/S prises en charge par l’appareil (latence) |
r_await |
Temps de lecture moyen en millisecondes pour les E/S prises en charge par l’appareil (latence) |
w_await |
Temps de lecture moyen en millisecondes pour les E/S prises en charge par l’appareil (latence) |
Les données présentées par iostat sont informatives, mais la présence de certaines données dans certaines colonnes ne signifie pas qu’il y a un problème. Les données provenant de iostat doivent toujours être capturées et analysées pour détecter les goulots d’étranglement possibles. Une latence élevée peut indiquer que le disque atteint un point de saturation.
Remarque
Vous pouvez utiliser la commande pour afficher les pidstat -d statistiques d’E/S par processus.
Ressource réseau
Les réseaux peuvent rencontrer deux goulots d’étranglement main : une faible bande passante et une latence élevée.
Vous pouvez utiliser vnstat pour capturer en direct les détails de la bande passante. Toutefois, vnstat n’est pas disponible dans toutes les distributions. L’outil largement disponible iptraf-ng est une autre option pour afficher le trafic d’interface en temps réel.
Latence réseau
La latence réseau dans deux systèmes différents peut être déterminée à l’aide d’une commande simple ping dans Internet Control Message Protocol (ICMP) :
[root@rhel78 ~]# 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
Vous pouvez vérifier la bande passante réseau à l’aide d’outils tels que iperf3. L’outil iperf3 fonctionne sur le modèle serveur/client dans lequel l’application est démarrée 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.
Server
root@ubnt:~# iperf3 -s ----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------Client
root@ubnt2:~# 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.
Certains paramètres courants iperf3 pour le client sont indiqués dans le tableau suivant.
| Paramètre | Description |
|---|---|
-P |
Spécifie le nombre de flux clients parallèles à exécuter. |
-R |
Inverse le trafic. Par défaut, le client envoie des données au serveur. |
--bidir |
Teste à la fois le chargement et le téléchargement. |
Ressource mémoire
La mémoire est une autre ressource de résolution des problèmes à case activée, car les applications peuvent ou non utiliser une partie de la mémoire. Vous pouvez utiliser des outils tels que free et top pour passer en revue l’utilisation globale de la mémoire et déterminer la quantité de mémoire consommée par différents processus :
[root@rhel78 ~]# 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 y a une colonne nommée buff/cache. Le noyau Linux utilise de la mémoire libre (inutilisée) pour mettre en cache les demandes d’E/S afin de bénéficier de meilleurs temps de réponse. Ce processus est appelé cache de page. Pendant la sollicitation de la mémoire (scénarios dans lesquels la mémoire est faible), le noyau retourne la mémoire utilisée pour le cache de page afin que les applications puissent utiliser cette mémoire.
Dans la free sortie, la colonne 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 commande pour trier les top processus par utilisation de la mémoire. Par défaut, top trie par pourcentage d’UC (%). 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 :
[root@rhel78 ~]# 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. Cela 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 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 un exemple de sortie de la commande :
[root@rhel78 ~]# 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 sollicitation de la mémoire à partir d’événements d’arrêt de mémoire insuffisante (OOM), comme illustré dans 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
OOM est appelé une fois que la RAM (mémoire physique) et l’ÉCHANGE (disque) sont consommées.
Remarque
Vous pouvez utiliser la commande pour afficher les pidstat -r statistiques de mémoire par processus.
Déterminer si une contrainte de ressource existe
Vous pouvez déterminer si une contrainte existe en utilisant les indicateurs précédents et en connaissant la configuration actuelle. La contrainte peut être comparée à la configuration existante.
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. À cette machine virtuelle, un disque P30 capable de 200 Mo/s est attaché. 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 la configuration du disque ou de la machine virtuelle peut fournir indique la ressource contraignante.
Si l’application nécessite <une ressource> measurement1>< et que la configuration actuelle de <la ressource> est capable de fournir uniquement <la mesure2>, cette exigence peut être un facteur de limitation.
Définir la ressource de limitation
Après avoir déterminé qu’une ressource est le facteur de limitation dans la configuration actuelle, identifiez comment elle peut être modifiée et comment elle affecte la charge de travail. Il existe des situations dans lesquelles la limitation des ressources peut exister en raison d’une mesure de réduction des coûts, mais l’application est toujours en mesure de gérer le goulot d’étranglement sans problème.
Par exemple :
Si l’application nécessite 128 Go (mesure) de RAM (ressource) et que la configuration actuelle de la RAM (ressource) est capable de fournir seulement 64 Go (mesure), cette exigence peut être un facteur de limitation.
À présent, vous pouvez définir la ressource de limitation et prendre des mesures en fonction de cette ressource. Le même concept s’applique à d’autres ressources.
Si ces ressources limitantes sont attendues comme mesure de réduction des coûts, l’application doit contourner les goulots d’étranglement. Toutefois, si les mêmes mesures d’économie de coûts existent et que l’application ne peut pas facilement gérer le manque de ressources, cette configuration peut entraîner des problèmes.
Apporter des modifications en fonction des données obtenues
La conception de performances ne consiste pas à résoudre les problèmes, mais à comprendre où le goulot d’étranglement suivant peut se produire et comment le contourner. Les goulots d’étranglement existent toujours et peuvent uniquement être déplacés vers un autre emplacement de la conception.
Par exemple, si l’application est limitée par les performances du disque, 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 pas de configuration idéale et vous devez résoudre les problèmes régulièrement.
En obtenant des données dans les étapes précédentes, vous pouvez désormais apporter des modifications en fonction de données réelles et mesurables. Vous pouvez également comparer ces modifications à la base de référence que vous avez mesurée précédemment pour vérifier qu’il existe une différence tangible.
Prenons l'exemple suivant :
Lorsque vous avez obtenu une base de référence pendant l’exécution de l’application, vous avez déterminé que le système avait une utilisation constante du processeur à 100 % dans une configuration de deux processeurs. Vous avez observé une charge moyenne de 4. Cela signifiait que le système faisait la file d’attente des requêtes. Une modification apportée à un système à 8 processeurs a réduit l’utilisation du processeur à 25 % et la moyenne de charge a été réduite à 2 lorsque la même charge a été appliquée.
Dans cet exemple, il existe 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 environnement local vers le cloud
Les migrations d’une installation locale vers le cloud computing peuvent être affectées par plusieurs différences de performances.
UC
En fonction de l’architecture, une installation locale peut exécuter des processeurs qui ont des vitesses d’horloge plus élevées et des caches plus volumineux. Le résultat serait une réduction des temps de traitement et une augmentation des instructions par cycle (IPC). Il est important de comprendre les différences entre les modèles d’UC et les métriques lorsque vous travaillez sur des migrations. Dans ce cas, une relation un-à-un entre les nombres de processeurs peut ne pas suffire.
Par exemple :
Dans un système local qui dispose de quatre processeurs qui s’exécutent à 3,7 GHz, un total de 14,8 GHz est disponible pour le traitement. Si l’équivalent en nombre d’UC est créé à l’aide d’une machine virtuelle D4s_v3 soutenue par des processeurs de 2,1 GHz, la machine virtuelle migrée dispose de 8,1 GHz disponibles pour le traitement. Cela représente une diminution d’environ 44 % des performances.
Disque
Les performances du disque dans Azure sont définies par le type et la taille du disque (à l’exception du disque Ultra, qui offre une flexibilité en termes de taille, d’IOPS et de débit). La taille du disque définit les limites d’IOPS et de débit.
La latence est une métrique qui dépend du type de disque plutôt que de la taille du disque. La plupart des solutions de stockage local sont des baies de disques qui ont des caches DRAM. Ce type de cache fournit une latence inférieure à la milliseconde (environ 200 microsecondes) et un débit de lecture/écriture (IOPS) élevé.
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) |
| Standard HDD | Ms à deux chiffres (millisecondes) |
Remarque
Un disque est limité s’il atteint ses limites d’IOPS ou de bande passante, car sinon, la latence peut atteindre 100 millisecondes ou plus.
La différence de latence entre un disque local (souvent inférieur à une milliseconde) et un SSD Premium (millisecondes à un chiffre) devient un facteur limitant. Notez les différences de latence entre les offres de stockage et sélectionnez l’offre qui répond le mieux aux exigences de l’application.
Réseau
La plupart des configurations réseau locales utilisent des liens 10 Gbits/s. Dans Azure, la bande passante réseau est directement définie par la taille des machines virtuelles. Certaines bandes passantes réseau peuvent dépasser 40 Gbits/s. Veillez à sélectionner une taille qui dispose de suffisamment de bande passante pour vos besoins d’application. Dans la plupart des cas, le facteur de limitation est les limites de débit de la machine virtuelle ou du disque au lieu du réseau.
Mémoire
Sélectionnez une taille de machine virtuelle qui dispose de suffisamment de RAM pour ce qui est actuellement configuré.
Diagnostics de performances (PerfInsights)
PerfInsights est l’outil recommandé par le support Azure pour les problèmes de performances des machines virtuelles. Il est conçu pour couvrir 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 support Azure.
Exécuter PerfInsights
PerfInsights est disponible sous les systèmes d’exploitation Windows et Linux. Vérifiez que votre distribution Linux figure dans la liste des distributions prises en charge pour Diagnostics de performances pour Linux.
Exécuter et analyser des rapports via le Portail Azure
Lorsque PerfInsights est installé via le Portail Azure, le logiciel installe une extension sur la machine virtuelle. Les utilisateurs peuvent également installer PerfInsights en tant qu’extension en accédant directement au panneau Extensions dans la machine virtuelle, puis en sélectionnant une option de diagnostics des performances.
option Portail Azure 1
Parcourez le panneau de la machine virtuelle et sélectionnez l’option Performances diagnostics. Vous êtes invité à installer l’option (utilise des extensions) sur la machine virtuelle pour laquelle vous l’avez sélectionnée.
option Portail Azure 2
Accédez à l’onglet Diagnostiquer et résoudre les problèmes dans le panneau de la machine virtuelle, puis recherchez le lien Résoudre les problèmes sous Problèmes de performances de machine virtuelle.
Éléments à rechercher dans le rapport PerfInsights
Après avoir exécuté le rapport PerfInsights, l’emplacement du contenu varie selon que le rapport a été exécuté via le Portail Azure ou en tant qu’exécutable. Pour l’une ou l’autre option, accédez au dossier de journal généré ou (si dans le Portail Azure) téléchargez localement pour 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 résultat comme impact élevé ou impact moyen .
Par exemple, dans le rapport suivant, nous constatons que des résultats d’impact moyen liés au stockage ont été détectés et que nous voyons 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.
Plus d’informations
Dépanner les performances de la machine virtuelle Azure sous Linux ou Windows
Diagnostics de performances pour les machines virtuelles Azure
Contactez-nous pour obtenir de l’aide
Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour