Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op: ✔️ Virtuele Linux-machines
Overzicht
Los problemen met CPU-, geheugen- en schijfinvoer- en uitvoerprestaties op en isoleren knelpunten op virtuele Linux-machines (VM's) in Azure.
Prestatieproblemen en knelpunten
Prestatieproblemen kunnen optreden in verschillende besturingssystemen en toepassingen. Voor elk scenario is een gerichte aanpak voor probleemoplossing vereist. In Linux-VM's komen prestatieproblemen meestal voor in een of meer kernresourcegebieden: CPU, geheugen, netwerken en invoer/uitvoer (I/O). Elke resource presenteert verschillende symptomen, vaak overlappend en vereist verschillende diagnostische methoden en herstelstrategieën.
In veel gevallen veroorzaken toepassings- of configuratieproblemen prestatievermindering, niet het platform zelf. Een webtoepassing met een onjuist geconfigureerde cachelaag kan bijvoorbeeld overmatige aanvragen naar de oorspronkelijke server routeren in plaats van ze uit de cache te leveren. Deze onjuiste configuratie verhoogt de CPU-belasting en reactietijden. Op dezelfde manier kan opslagplaatsing van invloed zijn op databaseworkloads. Als de redo log voor een MySQL- of MariaDB-database zich op de schijf van het besturingssysteem bevindt of op opslag die niet voldoet aan de prestatievereisten van de database, kan I/O-contentie leiden tot toegenomen latentie en minder transacties per seconde (TPS).
Effectieve probleemoplossing begint met het begrijpen van het probleem en het identificeren waar het knelpunt in de stack bestaat, ongeacht of het CPU, geheugen, netwerken of I/O is. Het instellen van een prestatiebasislijn is essentieel, omdat u hiermee metrische gegevens kunt vergelijken voor en na wijzigingen en kunt bepalen of deze wijzigingen leiden tot meetbare verbetering.
Het oplossen van prestatieproblemen op een virtuele machine is fundamenteel hetzelfde als in een fysiek systeem: het doel is om te bepalen welke resource de algehele prestaties beperkt. Knelpunten bestaan altijd in elk systeem. Prestatieproblemen oplossen is het proces van het identificeren van het huidige knelpunt en, indien mogelijk, het verplaatsen naar een minder beperkende resource.
Deze handleiding helpt u bij het identificeren en oplossen van prestatieproblemen in op Linux gebaseerde Azure-VM's door u te richten op het isoleren van knelpunten en het toepassen van gerichte diagnostische gegevens.
Het waarschijnlijke knelpunt identificeren
Begin met het oplossen van problemen door systeemgedrag en metrische relaties te observeren, niet afzonderlijke resourcegebruik in isolatie. Prestatieknelpunten komen vaak indirect aan de orde en de beperkte resource is niet altijd de meest voor de hand liggende resource.
De volgende tabel wijst algemene waarnemingen en metrische patronen toe aan de meest waarschijnlijke resource om eerst te onderzoeken.
| Observatie of signaal | Mogelijk knelpunt dat onderzocht moet worden | Onderbouwing |
|---|---|---|
| Hoog belastingsmiddel met laag CPU-gebruik | Schijf (I/O) | Processen worden geblokkeerd die wachten op I/O in plaats van te worden uitgevoerd op CPU |
| Hoog CPU-gebruik met gemiddelde lage belasting | Toepassingsontwerp of workload met één thread | De CPU is druk bezig, maar niet verzadigd over de beschikbare kernen. |
| Toenemende latentie van aanvragen onder belasting, CPU niet verzadigd | Schijf of netwerk | Latentie neemt vaak toe voordat de gebruikslimieten worden bereikt |
| Scherpe CPU-gebruiksschommelingen met een stabiele werkbelasting | CPU-beperking of burst-limieten | CPU-beschikbaarheid kan variëren vanwege platformbeperkingen |
| Hoge I/O-latentie met lage doorvoer | Schijfverzadiging of beperking | Latentie neemt toe voordat bandbreedtelimieten worden bereikt |
| Geleidelijk meer geheugengebruik in de loop van de tijd | Geheugenlek of groei van cache | Geheugendruk ontwikkelt zich geleidelijk in plaats van onmiddellijk |
| Gebeurtenissen van onvoldoende geheugen (OOMKilled) ondanks beschikbare schijfruimte | Geheugen | De beschikbaarheid van schijven beperkt de RAM-uitputting niet |
| Acceptabele metrische schijfgegevens, maar trage toepassings-I/O | I/O-patroon van applicatie | Kleine of synchrone I/O-bewerkingen beperken de prestaties. |
| Netwerkdoorvoer onder de verwachtingen | VM-grootte of netwerkinterfacekaart (NIC)-limieten | Netwerkbandbreedte wordt beperkt door de VM-SKU |
| Prestatievermindering alleen tijdens piekgebruik | Capaciteitsbeperking | Resourcelimieten worden alleen bereikt bij gelijktijdig gebruik |
Nadat u het meest relevante patroon hebt geïdentificeerd, gaat u verder met de bijbehorende resourcesectie voor gedetailleerde diagnostische gegevens en validatie.
Belangrijk
Knelpunten worden geïdentificeerd door relaties tussen metrische gegevens, niet door afzonderlijke gebruikswaarden. Cpu-, geheugen-, schijf- en netwerkgegevens altijd samen interpreteren.
Prestatie-inzichten verzamelen
Gebruik deze prestatieinzichten om te controleren of er een knelpunt voor resources bestaat.
Verschillende hulpprogramma's verzamelen prestatiegegevens, afhankelijk van de resource die wordt onderzocht. In de volgende tabel ziet u voorbeeldhulpprogramma's voor de primaire resources.
| Bron | Gereedschap |
|---|---|
| centrale verwerkingseenheid (CPU) |
top
htop, mpstat, pidstatvmstat |
| Schijf |
iostat, iotop, vmstat |
| Netwerk |
ip, vnstat, iperf3 |
| Geheugen |
free, top, vmstat |
In de volgende secties worden prestatiegegevens en hulpprogramma's besproken die u voor onderzoek kunt gebruiken.
CPU-bron
CPU-gebruik vertegenwoordigt het percentage tijd dat de processor actief werk uitvoert ten opzichte van de resterende inactiviteit. Op dezelfde manier besteden processen tijd aan CPU (zoals 80 procent usr gebruik) of niet (zoals 80 procent inactief). Het belangrijkste hulpprogramma om het CPU-gebruik te controleren is top.
Het top hulpprogramma wordt standaard uitgevoerd in de interactieve modus. Het wordt elke seconde vernieuwd en worden processen weergegeven die zijn gesorteerd op CPU-gebruik.
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
Bekijk nu de dd proceslijn van die uitvoer:
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
U kunt zien dat het dd proces 99,7 procent van de CPU verbruikt.
Notitie
U kunt het gebruik per CPU in het
tophulpprogramma weergeven door 1 te selecteren.Het
tophulpprogramma geeft een totaal gebruik van meer dan 100 procent weer als het proces multithreaded is en meer dan één CPU omvat.
Een andere nuttige verwijzing is het gemiddelde van de belasting. Het laadgemiddelde toont een gemiddelde systeembelasting in intervallen van 1 minuut, 5 minuten en 15 minuten. De waarde toont het belastingsniveau van het systeem. Het interpreteren van deze waarde is afhankelijk van het aantal BESCHIKBARE CPU's. Als het belastingsgemiddelde bijvoorbeeld 2 is op een systeem met één CPU, wordt het systeem zo geladen dat de processen in de wachtrij worden geplaatst. Als er een belastinggemiddelde van 2 is op een systeem met vier CPU's, is het totale CPU-gebruik ongeveer 50 procent.
Notitie
U kunt snel het CPU-aantal verkrijgen door de opdracht uit te nproc voeren.
In het vorige voorbeeld is het gemiddelde van de belasting 1,04. Dit is een systeem met twee CPU's, wat betekent dat er ongeveer 50 procent CPU-gebruik is. U kunt dit resultaat controleren als u de 48,5 procent niet-actieve CPU-waarde ziet. (In de uitvoer van de top opdracht wordt de niet-actieve CPU-waarde weergegeven vóór het id label.)
Gebruik het belastingsmiddelde als snel overzicht van de prestaties van het systeem.
Voer de uptime opdracht uit om het laadmiddelde te verkrijgen.
Belangrijk
Load average biedt context voor CPU-gebruik. Hoge belasting met een lage inactieve CPU duidt op verzadiging, terwijl een hoge belasting met niet-actieve CPU vaak verwijst naar niet-CPU-knelpunten.
I/O-resource (schijf)
In de volgende termen wordt uitgelegd hoe u I/O-prestatiemeteritems kunt identificeren en begrijpen.
| Term | Omschrijving |
|---|---|
| IO-grootte | De hoeveelheid gegevens die per transactie worden verwerkt, meestal gedefinieerd in bytes. |
| IO-threads | Het aantal processen dat interactie heeft met het opslagapparaat. Deze waarde is afhankelijk van de toepassing. |
| Blokgrootte | De I/O-grootte zoals gedefinieerd door het achterliggende blokapparaat. |
| Sectorgrootte | De grootte van elk van de sectoren op de schijf. Deze waarde is doorgaans 512 bytes. |
| IOPS | Invoeruitvoerbewerkingen per seconde. |
| Latentie | De tijd dat een I/O-bewerking moet worden voltooid. Deze waarde wordt doorgaans gemeten in milliseconden (ms). |
| Doorvoer | Een functie van de hoeveelheid gegevens die gedurende een bepaalde tijd is overgedragen. Deze waarde wordt doorgaans gedefinieerd als megabytes per seconde (MB/s). |
IOPS
IOPS (Input Output Operations Per Second ) meet het aantal invoer- en uitvoerbewerkingen (I/O) gedurende een specifieke tijd, meestal seconden. I/O-bewerkingen omvatten zowel lees- als schrijfbewerkingen. Het systeem kan ook verwijderingen of afkeuringen als bewerkingen van het opslagsysteem tellen. Elke bewerking heeft een toewijzingseenheid die overeenkomt met de I/O-grootte.
Toepassingen definiëren doorgaans de I/O-grootte als de hoeveelheid geschreven of gelezen gegevens per transactie. Een algemene I/O-grootte is 4K. Een kleinere I/O-grootte met meer threads resulteert echter in een hogere IOPS-waarde. Omdat elke transactie snel wordt voltooid vanwege de kleine grootte, zorgt een kleinere I/O-grootte ervoor dat meer transacties in dezelfde tijd kunnen worden voltooid.
Als u echter hetzelfde aantal threads gebruikt, maar een grotere I/O-grootte kiest, neemt IOPS af omdat het langer duurt om elke transactie te voltooien. Doorvoer neemt echter toe.
Kijk een naar het volgende voorbeeld:
1000 IOPS betekent dat elke seconde, duizend bewerkingen worden voltooid. Elke bewerking duurt ongeveer één milliseconden. (Er zijn 1000 milliseconden in één seconde.) In theorie heeft elke transactie ongeveer één milliseconde om te voltooien, of ongeveer 1 ms latentie.
Als u de IOSize-waarde en de IOPS kent, kunt u de doorvoer berekenen door IOSize te vermenigvuldigen met IOPS.
Bijvoorbeeld:
1000 IOPS bij 4K IOSize = 4.000 KB/s of 4 MB/s (3,9 MB/s om precies te zijn)
1000 IOPS bij 1M IOSize = 1000 MB/s of 1 GB/s (976 MB/s om precies te zijn)
U kunt als volgt een meer vergelijkingsvriendelijke versie schrijven:
IOPS * IOSize = IOSize/s (Throughput)
Doorvoer
In tegenstelling tot IOPS is doorvoer een functie van de hoeveelheid gegevens in de loop van de tijd. Deze meting betekent dat tijdens elke seconde een bepaalde hoeveelheid gegevens wordt geschreven of gelezen. U meet deze snelheid in <hoeveelheid gegevens>/<per> megabytes per seconde (MB/s).
Wanneer u de waarden voor doorvoer en I/O-grootte kent, kunt u IOPS berekenen door de doorvoer te delen door de I/O-grootte. U moet beide waarden normaliseren naar dezelfde maateenheid. Als de I/O-grootte bijvoorbeeld is gedefinieerd in kilobytes (KB), moet u doorvoer converteren naar KB voordat u de berekening uitvoert.
De vergelijkingsindeling wordt als volgt geschreven:
Throughput / IOSize = IOPS
Als u deze vergelijking in context wilt plaatsen, kunt u een doorvoer van 10 MB/s overwegen op een IOSize van 4K. Wanneer u de waarden in de vergelijking invoert, is het resultaat 10.240/4=2560 IOPS.
Notitie
10 MB is precies gelijk aan 10.240 kB.
Latentie
Latentie is de meting van de gemiddelde hoeveelheid tijd die elke bewerking nodig heeft om te voltooien. IOPS en latentie zijn gerelateerd omdat beide concepten een functie van tijd zijn. Bij 100 IOPS duurt elke bewerking bijvoorbeeld ongeveer 10 ms. Maar dezelfde hoeveelheid gegevens kan nog sneller worden opgehaald bij lagere IOPS. Latentie wordt ook wel zoektijd genoemd.
Iostat-uitvoer begrijpen
Als onderdeel van het sysstat-pakket biedt het iostat hulpprogramma inzicht in schijfprestaties en metrische gegevens over gebruik.
iostat kan helpen bij het identificeren van knelpunten die zijn gerelateerd aan het schijfsubsysteem.
U kunt het iostat hulpprogramma uitvoeren met behulp van een eenvoudige opdracht. De basissyntaxis wordt als volgt weergegeven:
iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>
De parameters bepalen welke informatie iostat biedt. Zonder een opdrachtparameter iostat worden basisdetails weergegeven:
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
iostat Standaard worden gegevens weergegeven voor alle bestaande blokapparaten, hoewel het minimale gegevens voor elk apparaat biedt. Gebruik parameters die uitgebreide gegevens bieden, zoals doorvoer, IOPS, wachtrijgrootte en latentie om problemen te identificeren.
Uitvoeren iostat door triggers op te geven:
iostat -dxctm 1
Gebruik de volgende parameters om de iostat resultaten verder uit te breiden.
| Parameter | Actie |
|---|---|
-d |
Het rapport apparaatgebruik weergeven. |
-x |
Uitgebreide statistieken weergeven. Deze parameter is belangrijk omdat deze IOPS, latentie en wachtrijgrootten biedt. |
-c |
Het rapport CPU-gebruik weergeven. |
-t |
Druk de tijd af voor elk rapport dat wordt weergegeven. Deze parameter is handig voor lange uitvoeringen. |
-m |
Statistieken weergeven in megabytes per seconde, een meer leesbare vorm. |
Het numerieke 1 getal in de opdracht geeft iostat aan om elke seconde te vernieuwen. Als u het vernieuwen wilt stoppen, selecteert u Ctrl+C.
Als u de extra parameters opneemt, lijkt de uitvoer op de volgende tekst:
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
Waarden begrijpen
De hoofdkolommen uit de iostat uitvoer worden weergegeven in de volgende tabel.
| Kolom | Omschrijving |
|---|---|
r/s |
Leesbewerkingen per seconde (IOPS) |
w/s |
Schrijfbewerkingen per seconde (IOPS) |
rMB/s |
Megabytes per seconde lezen (doorvoer) |
wMB/s |
Megabytes per seconde schrijven (doorvoer) |
avgrq-sz |
Gemiddelde I/O-grootte in sectoren; vermenigvuldig dit getal met de sectorgrootte, meestal 512 bytes, om de I/O-grootte in bytes op te halen (I/O-grootte) |
avgqu-sz |
Gemiddelde wachtrijgrootte (het aantal I/O-bewerkingen in de wachtrij die wachten op afhandeling) |
await |
Gemiddelde tijd in milliseconden voor I/O die wordt geleverd door het apparaat (latentie) |
r_await |
Gemiddelde leestijd in milliseconden voor I/O die wordt geleverd door het apparaat (latentie) |
w_await |
Gemiddelde leestijd in milliseconden voor I/O die wordt geleverd door het apparaat (latentie) |
De gegevens die worden iostat gepresenteerd, zijn informatief, maar de aanwezigheid van bepaalde gegevens in bepaalde kolommen betekent niet dat er een probleem is. Leg altijd gegevens vast en analyseer deze van iostat op mogelijke knelpunten. Hoge latentie kan erop wijzen dat de schijf een verzadigingspunt bereikt.
Notitie
U kunt de pidstat -d opdracht gebruiken om I/O-statistieken per proces weer te geven.
Belangrijk
Afzonderlijke iostat waarden geven zelf geen probleem aan. Aanhoudende hoge latentie of wachtrijdiepte onder belasting is een sterkere indicator van schijfverzadiging.
Netwerkresource
Netwerken kunnen twee belangrijke knelpunten ervaren: lage bandbreedte en hoge latentie.
U kunt vmstat gebruiken om bandbreedtegegevens live vast te leggen.
vnstat Is echter niet beschikbaar in alle distributies. Het algemeen beschikbare iptraf-ng hulpprogramma is een andere optie om realtime interfaceverkeer weer te geven.
Netwerklatentie
U kunt netwerklatentie tussen twee verschillende systemen bepalen met behulp van de eenvoudige ping opdracht in 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
Als u de pingactiviteit wilt stoppen, selecteert u Ctrl+C.
Netwerkbandbreedte
Controleer de netwerkbandbreedte met behulp van hulpprogramma's zoals iperf3. Het iperf3 hulpprogramma werkt op het server-/clientmodel. Start de toepassing door de -s vlag op de server op te geven. Clients maken vervolgens verbinding met de server door het IP-adres of de FQDN (Fully Qualified Domain Name) van de server op te geven in combinatie met de -c vlag. De volgende codefragmenten laten zien hoe u het iperf3 hulpprogramma op de server en client gebruikt.
Server
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.
In de volgende tabel ziet u enkele algemene iperf3 parameters voor de client.
| Parameter | Omschrijving |
|---|---|
-P |
Hiermee geeft u het aantal parallelle clientstreams op dat moet worden uitgevoerd. |
-R |
Verkeer omkeren. De client verzendt standaard gegevens naar de server. |
--bidir |
Test de zowel het uploaden als het downloaden. |
Belangrijk
Netwerkprestaties in Azure zijn gebonden aan de VM-grootte. Doorvoerbeperkingen zijn vaak afkomstig van VM- of schijflimieten in plaats van het netwerk zelf.
Geheugenresource
Geheugen is een ander hulpmiddel voor probleemoplossing dat gecontroleerd moet worden, omdat toepassingen mogelijk een deel van het geheugen al dan niet gebruiken. U kunt hulpprogramma's zoals free het algehele geheugengebruik gebruiken en top bepalen hoeveel geheugen verschillende processen verbruiken:
free -m
total used free shared buff/cache available
Mem: 7802 435 5250 9 2117 7051
Swap: 0 0 0
In Linux-systemen is het gebruikelijk om het geheugengebruik van 99 procent te zien. In de uitvoer is er een kolom genaamd buff/cache. De Linux-kernel gebruikt gratis (ongebruikt) geheugen om I/O-aanvragen in de cache op te cachen voor betere reactietijden. Dit proces wordt een paginacache genoemd. Tijdens geheugenbelasting (scenario's waarin het geheugen laag is), retourneert de kernel het geheugen dat wordt gebruikt voor de paginacache , zodat toepassingen dat geheugen kunnen gebruiken.
In de free uitvoer geeft de beschikbare kolom aan hoeveel geheugen er beschikbaar is voor processen die moeten worden gebruikt. Deze waarde wordt berekend door de hoeveelheden buff-/cachegeheugen en het vrije geheugen toe te voegen.
U kunt de top opdracht configureren om processen te sorteren op geheugengebruik. Sorteert standaard top op CPU-percentage (%). Als u wilt sorteren op geheugengebruik (%), selecteert u Shift+M wanneer u deze uitvoert.top In de volgende tekst ziet u uitvoer van de top opdracht:
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
[...]
De RES kolom geeft resident geheugen aan. Deze waarde vertegenwoordigt het werkelijke procesgebruik. Het top hulpprogramma biedt een vergelijkbare uitvoer als free in termen van kilobytes (KB).
Geheugengebruik kan meer dan verwacht toenemen als de toepassing geheugenlekken ondervindt. In een scenario met geheugenlekken kunnen toepassingen geen geheugenpagina's vrijmaken die niet meer worden gebruikt.
Hier volgt een andere opdracht die wordt gebruikt om de meest gebruikte processen voor geheugengebruik weer te geven:
ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
In de volgende tekst ziet u voorbeelduitvoer van de opdracht:
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
[...]
U kunt geheugendruk identificeren aan de hand van gebeurtenissen van een Out of Memory (OOM) Kill, zoals wordt weergegeven in de volgende voorbeelduitvoer:
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
Het systeem roept OOM aan nadat zowel RAM (fysiek geheugen) als SWAP (schijf) zijn verbruikt.
Notitie
Gebruik de pidstat -r opdracht om statistieken per procesgeheugen weer te geven.
Belangrijk
Hoog geheugengebruik is normaal in Linux. Geheugendruk wordt aangegeven door weinig beschikbaar geheugen, actieve wisselingen of OOM-killed gebeurtenissen, niet door cachegebruik.
Bepalen of er een resourcebeperking bestaat
U kunt resourcebeperkingen identificeren door indicatoren te correleren met de huidige configuratie.
Hier volgt een voorbeeld van een schijfbeperking:
Een D2s_v3 VM is geschikt voor 48 MB/s van niet-cachedoorvoer. Op deze VM is een P30-schijf gekoppeld die geschikt is voor 200 MB/s. Voor de toepassing is minimaal 100 MB/s vereist.
In dit voorbeeld is de beperkende resource de doorvoer van de volledige VM. De vereiste van de toepassing versus wat de schijf- of VM-configuratie kan bieden, geeft de beperkingsresource aan.
Als de toepassing <meting1><-bron> vereist, en de huidige configuratie voor <de bron> alleen <meting2> kan leveren, kan deze eis een beperkende factor zijn.
De beperkende resource definiëren
Nadat u een knelpunt voor resources in de huidige configuratie hebt geïdentificeerd, evalueert u mogelijke wijzigingen en beoordeelt u de impact op de workload. In sommige gevallen bestaat het knelpunt als een keuze voor kostenoptimalisatie en blijft de toepassing binnen acceptabele prestatielimieten werken.
Wanneer voor een toepassing bijvoorbeeld 128 GB (meting) ram (resource) is vereist, maar de huidige configuratie slechts 64 GB (resource) biedt, wordt het geheugen een knelpunt voor de workload.
Nadat u de knelpuntresource hebt geïdentificeerd, definieert u de beperking en voert u de juiste actie uit. Deze benadering is van toepassing op alle resources.
Sommige knelpunten zijn het gevolg van kostenbesparende configuraties en zijn acceptabel wanneer de toepassing deze kan tolereren. Wanneer de toepassing de verminderde resources niet tolereert, wordt de configuratie problematisch.
Wijzigingen aanbrengen op basis van verkregen gegevens
Ontwerpen voor prestaties gaat niet over het oplossen van problemen, maar over het begrijpen waar het volgende knelpunt kan optreden en hoe u dit kunt omzeilen. Knelpunten bestaan altijd en u kunt ze alleen verplaatsen naar een andere locatie in het ontwerp.
Als de schijfprestaties bijvoorbeeld de toepassing beperkt, kunt u de schijfgrootte vergroten om meer doorvoer toe te staan. Het netwerk wordt echter het volgende knelpunt. Omdat resources beperkt zijn, is er geen ideale configuratie en moet u regelmatig problemen oplossen.
Nadat u gegevens uit de vorige stappen hebt verzameld, kunt u het systeem afstemmen op basis van werkelijke, meetbare gegevens. Vergelijk deze wijzigingen met de eerder vastgestelde basislijn om een meetbare verbetering te controleren.
Kijk een naar het volgende voorbeeld:
Een basislijn toont 100 procent CPU-gebruik op een systeem met twee CPU's en een belastinggemiddelde van 4, wat aangeeft dat verzoeken in de wachtrij staan. Nadat het aantal is vergroot naar acht CPU's, is het CPU-gebruik door dezelfde workload verminderd tot 25 procent en is de gemiddelde belasting verlaagd tot 2.
In dit voorbeeld ziet u een meetbaar verschil wanneer u de verkregen resultaten vergelijkt met de gewijzigde resources. Vóór de wijziging was er een duidelijke resourcebeperking. Maar na de wijziging zijn er voldoende resources om de belasting te verhogen.
Migreren van on-premises naar de cloud
Verschillende prestatieverschillen kunnen van invloed zijn op migraties van een on-premises installatie naar cloud-computing.
centrale verwerkingseenheid (CPU)
Afhankelijk van de architectuur kan een on-premises installatie CPU's uitvoeren met hogere kloksnelheden en grotere caches. Het resultaat is verminderde verwerkingstijden en hogere instructies per cyclus (IPC). Het is belangrijk om inzicht te hebben in de verschillen in CPU-modellen en metrische gegevens wanneer u aan migraties werkt. In dit geval is een een-op-een-relatie tussen CPU-tellingen mogelijk niet voldoende.
Bijvoorbeeld:
In een on-premises systeem met vier CPU's die op 3,7 GHz worden uitgevoerd, is er in totaal 14,8 GHz beschikbaar voor verwerking. Als u het equivalent in cpu-telling maakt met behulp van een D4s_v3 VM die wordt ondersteund door CPU's van 2,1 GHz, is de gemigreerde VM 8,1 GHz beschikbaar voor verwerking. Dit vertegenwoordigt ongeveer 44 procent lagere prestaties.
Schijf
Schijfprestaties in Azure zijn afhankelijk van het type en de grootte van de schijf, met uitzondering van Ultra-schijf, die flexibiliteit biedt in grootte, IOPS en doorvoer. De schijfgrootte stelt de IOPS- en doorvoerlimieten in.
Latentie is afhankelijk van het schijftype in plaats van de schijfgrootte. De meeste on-premises opslagoplossingen maken gebruik van schijfmatrices met DRAM-caches. Dit type cache levert een latentie van minder dan milliseconden (ongeveer 200 microseconden) en een hoge doorvoer voor lezen/schrijven (IOPS).
De gemiddelde Azure-latenties worden weergegeven in de volgende tabel.
| Schijftype | Latentie |
|---|---|
| Ultra disk/Premium SSD v2 | Drie-cijferige waarden in μs (microseconden) |
| Premium SSD/Standard SSD | Ms met één cijfer (milliseconden) |
| Standard HDD | Tweedelige ms (milliseconden) |
Notitie
Een schijf wordt beperkt als deze de IOPS- of bandbreedtelimieten bereikt. Anders kan latentie pieken tot 100 milliseconden of meer.
Het latentieverschil tussen een on-premises installatie (vaak minder dan een milliseconden) en Premium SSD (milliseconden met één cijfer) kan een beperkende factor zijn. Let op de verschillen in latentie tussen de opslagaanbiedingen en selecteer het aanbod dat het beste past bij de vereisten van uw toepassing.
Netwerk
De meeste on-premises netwerkinstellingen gebruiken 10 Gbps-koppelingen. In Azure bepaalt de grootte van de VM's rechtstreeks de netwerkbandbreedte. Sommige netwerkbandbreedten kunnen groter zijn dan 40 Gbps. Zorg ervoor dat u een grootte selecteert die voldoende bandbreedte biedt voor uw toepassingsbehoeften. In de meeste gevallen zijn de doorvoerlimieten van de VM of schijf, in plaats van het netwerk, de beperkende factor.
Geheugen
Selecteer een VM-grootte met voldoende RAM-geheugen voor wat momenteel is geconfigureerd.
Prestatiediagnose (PerfInsights)
Azure-ondersteuning raadt PerfInsights aan voor prestatieproblemen met vm's. Het biedt aanbevolen procedures en toegewezen analysetabbladen voor CPU, geheugen en I/O. U kunt deze op aanvraag uitvoeren via Azure Portal of vanuit de VIRTUELE machine en de gegevens vervolgens delen met het ondersteuningsteam van Azure.
PerfInsights uitvoeren
PerfInsights is beschikbaar voor het Linux-besturingssysteem . Controleer of de Linux-distributie in de lijst met ondersteunde distributies voor Prestatiediagnose voor Linux staat.
Rapporten uitvoeren en analyseren via Azure Portal
Wanneer u PerfInsights installeert via Azure Portal, installeert de software een extensie op de VIRTUELE machine. U kunt PerfInsights ook als een extensie installeren door rechtstreeks naar Extensies te gaan en vervolgens een optie voor prestatiediagnose te selecteren.
Optie 1 van Azure Portal
Blader naar de blade VM en selecteer Prestatiediagnose. Installeer deze vervolgens op de doel-VM (gebruikt extensies).
Optie 2 van Azure Portal
Blader naar het tabblad Diagnose en Oplossen van Problemen op het VM-blad en zoek naar de koppeling Problemen oplossen onder VM-prestatieproblemen.
Wat u zoekt in het PerfInsights-rapport
Nadat u het PerfInsights-rapport hebt uitgevoerd, is de locatie van de inhoud afhankelijk van of u het rapport uitvoert via Azure Portal of als uitvoerbaar bestand. Voor beide opties hebt u toegang tot de gegenereerde logboekmap of (indien in de Azure Portal) kunt u deze lokaal downloaden voor analyse.
Uitvoeren via De Azure-portal
Open het PerfInsights-rapport. Op het tabblad Bevindingen worden eventuele uitbijters in termen van resourceverbruik in logboeken opgeslagen. Als er gevallen van trage prestaties zijn vanwege specifiek resourcegebruik, categoriseert het tabblad Bevindingen elke bevindingen als hoge impact of gemiddeld effect.
In het volgende rapport ziet u bijvoorbeeld dat het hulpprogramma resultaten van gemiddelde impact heeft gedetecteerd die betrekking hebben op opslag en dat u de bijbehorende aanbevelingen ziet. Als u de gebeurtenis Resultaten uitvouwt , ziet u verschillende belangrijke details.
Zie PerfInsights Linux gebruiken in Microsoft Azure voor meer informatie over PerfInsights Insights in het Linux-besturingssysteem.