Résoudre les problèmes de performances et isoler les goulots d’étranglement dans Linux
S’applique à : ✔️ Machines virtuelles Linux
Problèmes de performances et goulots d’étranglement
Quand des problèmes de performances se produisent dans différents systèmes d’exploitation ou applications, et chaque cas requiert une approche unique pour le dépannage. La plupart des problèmes sont liés au processeur, à la mémoire, à la mise en réseau et à l’entrée/sortie (E/S). Chacune de ces zones génère des symptômes différents (parfois simultanément) et nécessite un diagnostic et une solution différents.
Les problèmes de performances peuvent être causés par une configuration incorrecte de l’application ou de la configuration. 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 rétablissement 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 des ressources et des temps de réponse plus élevés (latence).
Si vous comprenez parfaitement le problème, vous pouvez mieux identifier l’emplacement où rechercher sur 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 composant provoque 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ù un goulot d’étranglement se produit et comment 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 refusent si la contrainte de ressource existe.
Selon la ressource examinée, de nombreux outils peuvent vous aider à obtenir des données relatives à cette ressource. Le tableau suivant inclut des exemples pour les ressources principales.
| Ressource | Outil |
|---|---|
| UC | top, , htopmpstat, , pidstatvmstat |
| Disque | iostat, , iotopvmstat |
| Network (Réseau) | ip, , vnstatiperf3 |
| Mémoire | free, , topvmstat |
Les sections suivantes décrivent les pointeurs et les outils que vous pouvez utiliser pour rechercher les ressources principales.
Ressource processeur
Un certain pourcentage d’UC est utilisé ou non. De même, les processus passent du temps dans le processeur (par exemple, 80 % usr d’utilisation) ou ne le font pas (par exemple, 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 :
[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 ligne de dd 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.
Note
Vous pouvez afficher l’utilisation par uc 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 uc.
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 top commande, 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.
Ressource disque (E/S)
Lorsque vous examinez les problèmes de performances des E/S, les termes suivants vous aident à comprendre où se produit le problème.
| 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 l’appareil de bloc de stockage. |
| Taille du secteur | Taille de chacun des secteurs au niveau du disque. Cette valeur est généralement de 512 octets. |
| D’OPÉRATIONS D’E/S PAR SECONDE | Opérations de sortie d’entrée par seconde. |
| Latence | Heure à laquelle une opération d’E/S prend 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). |
D’OPÉRATIONS D’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 dans un certain temps (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 comme quantité de données écrites ou lues par transaction. Une taille d’E/S couramment utilisée est de 4 Ko. Toutefois, une taille d’E/S plus petite qui contient plus de threads génère une valeur d’E/S par seconde 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 temps.
Au contraire, supposons que vous avez le même nombre de threads, mais utilisez une E/S plus grande. Les E/S par seconde 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 environ une latence de 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 conviviale de l’équation 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 au fil du 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 données/>><, ou en mégaoctets par seconde (Mo/s).<
Si vous connaissez le débit et les valeurs IOSize, vous pouvez calculer les E/S par seconde 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 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 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 avoir de 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 les données minimales soient fournies pour chaque appareil. Les paramètres sont disponibles pour identifier les problèmes en fournissant des données étendues (par exemple, débit, IOPS, taille de file d’attente et latence).
Exécutez en iostat spécifiant des 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 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 :
[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 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. Les données provenant de iostat doivent toujours être capturées et analysées pour les goulots d’étranglement possibles. 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.
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 vnstat 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
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.
Serveur
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 à vérifier, car les applications peuvent ou ne pas utiliser une partie de la mémoire. Vous pouvez utiliser des outils tels que 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 :
[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 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 dans lesquels la mémoire est en cours d’exécution faible), le noyau retourne la mémoire utilisée pour le cache de pages afin que les applications puissent utiliser cette mémoire.
Dans la sortie, la free 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 top commande pour trier les processus en fonction de l’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 colonne indique la RES mémoire résidente. Cela représente l’utilisation réelle du processus. L’outil top fournit une sortie similaire en free 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 :
[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 pression de la mémoire à partir des événements OOM (Out of Memory), 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é après la consommation de RAM (mémoire physique) et d’ÉCHANGE (disque).
Note
Vous pouvez utiliser la pidstat -r commande pour afficher les statistiques de mémoire par processus.
Déterminer si une contrainte de ressource existe
Vous pouvez déterminer si une contrainte existe à l’aide des indicateurs précédents et connaître 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. 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 à la configuration du disque ou de la machine virtuelle peut fournir indique la ressource contraignante.
Si l’application nécessite <une ressource> mesure1<>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 doit être le facteur de limitation de 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 d’économie de 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 effectuer des actions en fonction de cette ressource. Le même concept s’applique à d’autres ressources.
Si ces ressources limitantes sont attendues comme mesure d’économie de 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 l’absence de ressources, cette configuration peut entraîner des problèmes.
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 ne peuvent être déplacés qu’à 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 autoriser davantage de débit. 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.
En obtenant des données dans les étapes précédentes, vous pouvez désormais apporter des modifications en fonction des 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 disposait d’une utilisation constante de 100 % du processeur dans une configuration de deux PROCESSEURs. Vous avez observé une moyenne de charge de 4. Cela signifiait que le système faisait l’objet d’une mise en file d’attente. Une modification apportée à un système de 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 site local vers le cloud
Les migrations d’une configuration locale vers le cloud computing peuvent être affectées par plusieurs différences de performances.
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 serait 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 d’UC et les métriques lorsque vous travaillez sur des migrations. Dans ce cas, une relation un-à-un entre les nombres d’UC 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 l’équivalent dans le nombre d’UC est créé à l’aide d’une machine virtuelle D4s_v3 sauvegardé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 sont définies par le type et la taille du disque (à l’exception du disque Ultra, ce 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 est une métrique qui dépend du type de disque au lieu de la taille du disque. La plupart des solutions de stockage locales sont des tableaux de disques qui ont des caches DRAM. Ce type de cache fournit une latence de sous-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 à deux chiffres (millisecondes) |
Note
Un disque est limité s’il atteint ses limites d’E/S par seconde ou de bande passante, car sinon la latence peut atteindre 100 millisecondes ou plus.
La différence de latence entre un disque ssd local (souvent inférieur à une milliseconde) et un SSD Premium (millisecondes à un chiffre) devient un facteur de limitation. Notez les différences de latence entre les offres de stockage et sélectionnez l’offre qui répond mieux aux exigences de l’application.
Network (Réseau)
La plupart des configurations réseau locales utilisent des liens de 10 Gbits/s. Dans Azure, la bande passante réseau est directement définie par la taille des machines virtuelles. Certaines bande passantes réseau peuvent dépasser 40 Gbits/s. Veillez à sélectionner une taille qui a 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 a 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 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
Quand 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 diagnostic de performances.
Portail Azure option 1
Parcourez le panneau de la machine virtuelle et sélectionnez l’option Diagnostics de performances. Vous êtes invité à installer l’option (utilise des extensions) sur la machine virtuelle pour laquelle vous l’avez sélectionnée.
Portail Azure option 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 de performances de machine virtuelle.
Éléments à rechercher dans le rapport PerfInsights
Après avoir exécuté le rapport PerfInsights, l’emplacement du contenu dépend du fait 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 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, nous constatons que les 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
Résoudre les problèmes de performances des machines virtuelles Azure sur 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.