Prestatieproblemen oplossen en knelpunten in Linux isoleren
Van toepassing op: ✔️ Virtuele Linux-machines
Prestatieproblemen en knelpunten
Wanneer prestatieproblemen optreden in verschillende besturingssystemen en toepassingen, is voor elk geval een unieke benadering vereist om problemen op te lossen. CPU, geheugen, netwerken en input/output (I/O) zijn belangrijke gebieden waar problemen kunnen optreden. Elk van deze gebieden vertoont verschillende symptomen (soms tegelijkertijd) en vereist verschillende diagnoses en oplossingen.
Prestatieproblemen kunnen worden veroorzaakt door een onjuiste configuratie van de toepassing of installatie. Een voorbeeld hiervan is een webtoepassing met een cachelaag die niet juist is geconfigureerd. In deze situatie worden meer aanvragen geactiveerd die teruggaan naar de oorspronkelijke server in plaats van te worden geleverd vanuit een cache.
In een ander voorbeeld bevindt het opnieuw logboek van een MySQL- of MariaDB-database zich op de besturingssysteemschijf of op een schijf die niet voldoet aan de databasevereisten. In dit scenario ziet u mogelijk minder transacties per seconde (TPS) vanwege concurrentie voor resources en hogere reactietijden (latentie).
Als u het probleem volledig begrijpt, kunt u beter bepalen waar u moet kijken op de stack (CPU, geheugen, netwerken, I/O). Als u prestatieproblemen wilt oplossen, moet u een basislijn instellen waarmee u metrische gegevens kunt vergelijken nadat u wijzigingen hebt aangebracht en om te evalueren of de algehele prestaties zijn verbeterd.
Het oplossen van een prestatieprobleem met een virtuele machine (VM) verschilt niet van het oplossen van een prestatieprobleem op een fysiek systeem. Het gaat erom te bepalen welke resource of welk onderdeel een knelpunt in het systeem veroorzaakt.
Het is belangrijk om te begrijpen dat er altijd knelpunten bestaan. Het oplossen van prestatieproblemen gaat over het begrijpen waar een knelpunt optreedt en hoe u deze verplaatst naar een minder beledige resource.
Deze handleiding helpt u bij het detecteren en oplossen van prestatieproblemen in virtuele Azure-machines in de Linux-omgeving.
Prestatiepunten verkrijgen
U kunt prestatiepunten verkrijgen die bevestigen of weigeren of de resourcebeperking bestaat.
Afhankelijk van de resource die wordt onderzocht, kunnen veel hulpprogramma's u helpen bij het verkrijgen van gegevens die betrekking hebben op die resource. De volgende tabel bevat voorbeelden voor de belangrijkste resources.
| Bron | Hulpprogramma |
|---|---|
| CPU | topmpstat, htop, pidstatvmstat |
| Schijf | iostat, , iotopvmstat |
| Netwerk | ip, , vnstatiperf3 |
| Geheugen | free, , topvmstat |
In de volgende secties worden de aanwijzers en hulpprogramma's besproken die u kunt gebruiken om naar de belangrijkste resources te zoeken.
CPU-resource
Een bepaald percentage cpu wordt gebruikt of niet. Op dezelfde manier besteden processen tijd aan CPU (zoals 80 procent usr gebruik) of niet (zoals 80 procent inactief). Het belangrijkste hulpprogramma om te bevestigen dat het CPU-gebruik is top.
Het top hulpprogramma wordt standaard uitgevoerd in de interactieve modus. Elke seconde wordt vernieuwd en worden processen weergegeven zoals gesorteerd op CPU-gebruik:
[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
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 geeft het belastingsniveau van het systeem aan. 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.
I/O-resource (schijf)
Wanneer u I/O-prestatieproblemen onderzoekt, helpen de volgende termen u te begrijpen waar het probleem zich voordoet.
| Termijn | Omschrijving |
|---|---|
| IO-grootte | De hoeveelheid gegevens die per transactie wordt 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 backingblokapparaat. |
| 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 wordt overgedragen. Deze waarde wordt doorgaans gedefinieerd als megabytes per seconde (MB/s). |
IOPS
IOPS (Input Output Operations Per Second ) is een functie van het aantal invoer- en uitvoerbewerkingen (I/O) dat gedurende een bepaalde tijd (in dit geval seconden) wordt gemeten. I/O-bewerkingen kunnen lees- of schrijfbewerkingen zijn. Verwijderingen of verwijderingen kunnen ook worden meegeteld als een bewerking voor het opslagsysteem. Elke bewerking heeft een toewijzingseenheid die gelijk is aan de I/O-grootte.
De I/O-grootte wordt doorgaans gedefinieerd op toepassingsniveau als de hoeveelheid gegevens die per transactie wordt geschreven of gelezen. Een veelgebruikte I/O-grootte is 4K. Een kleinere I/O-grootte die meer threads bevat, levert echter een hogere IOPS-waarde op. Omdat elke transactie relatief snel kan worden voltooid (vanwege de kleine grootte), zorgt een kleinere I/O ervoor dat meer transacties in dezelfde tijd kunnen worden voltooid.
Stel dat u hetzelfde aantal threads hebt, maar een grotere I/O gebruikt. IOPS neemt af omdat het langer duurt voordat elke transactie is voltooid. Doorvoer neemt echter toe.
Kijk een naar het volgende voorbeeld:
1000 IOPS betekent dat voor elke seconde duizend bewerkingen zijn voltooid. Elke bewerking duurt ongeveer één milliseconde. (Er zijn 1000 milliseconden in één seconde.) In theorie heeft elke transactie ongeveer één milliseconde om te voltooien, of ongeveer 1 ms latentie.
Door de IOSize-waarde en de IOPS te kennen, 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)
Een meer vergelijkingsvriendelijke versie kan als volgt worden geschreven:
IOPS * IOSize = IOSize/s (Throughput)
Doorvoer
In tegenstelling tot IOPS is doorvoer een functie van de hoeveelheid gegevens in de loop van de tijd. Dit betekent dat tijdens elke seconde een bepaalde hoeveelheid gegevens wordt geschreven of gelezen. Deze snelheid wordt gemeten in hoeveelheid gegevens/><of> megabytes per seconde (MB/s).<
Als u de doorvoer- en IOSize-waarden kent, kunt u IOPS berekenen door de doorvoer te delen door IOSize. U moet de eenheden normaliseren tot de kleinste connotatie. Als IOSize bijvoorbeeld is gedefinieerd in kilobytes (kb), moet de doorvoer worden geconverteerd.
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 uitvoeren iostat in een eenvoudige opdracht. De basissyntaxis is als volgt:
iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>
De parameters bepalen welke informatie iostat biedt. Als u geen opdrachtparameter hebt, iostat worden basisdetails weergegeven:
[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
iostat Standaard worden gegevens weergegeven voor alle bestaande blokapparaten, hoewel er voor elk apparaat minimale gegevens worden opgegeven. Parameters zijn beschikbaar om problemen te identificeren door uitgebreide gegevens op te geven (zoals doorvoer, IOPS, wachtrijgrootte en latentie).
Uitvoeren iostat door triggers op te geven:
sudo 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 |
De tijd afdrukken voor elk weergegeven rapport. 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:
[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
Waarden begrijpen
De hoofdkolommen uit de iostat uitvoer worden weergegeven in de volgende tabel.
| Kolom | Beschrijving |
|---|---|
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 dat moet worden verwerkt) |
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. Gegevens uit iostat moeten altijd worden vastgelegd en geanalyseerd 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.
Netwerkresource
Netwerken kunnen twee belangrijke knelpunten ervaren: lage bandbreedte en hoge latentie.
U kunt bandbreedtegegevens vnstat live vastleggen. 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
Netwerklatentie in twee verschillende systemen kan worden bepaald met behulp van een eenvoudige ping opdracht in 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
Als u de pingactiviteit wilt stoppen, selecteert u Ctrl+C.
Netwerkbandbreedte
U kunt de netwerkbandbreedte controleren met behulp van hulpprogramma's zoals iperf3. Het iperf3 hulpprogramma werkt op het server-/clientmodel waarin de toepassing wordt gestart 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
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.
Enkele algemene iperf3 parameters voor de client worden weergegeven in de volgende tabel.
| Parameter | Description |
|---|---|
-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 zowel uploaden als downloaden. |
Geheugenresource
Geheugen is een andere resource voor het oplossen van problemen om te controleren omdat toepassingen al dan niet een deel van het geheugen gebruiken. U kunt hulpprogramma's zoals free het top algehele geheugengebruik controleren en bepalen hoeveel geheugen verschillende processen verbruiken:
[root@rhel78 ~]# 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 free uitvoer ziet u een kolom met de naam 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:
[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
[...]
De RES kolom geeft resident geheugen aan. Dit 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:
[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
[...]
U kunt geheugendruk identificeren van killgebeurtenissen voor onvoldoende geheugen (OOM), 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
OOM wordt aangeroepen nadat zowel RAM (fysiek geheugen) als SWAP (schijf) zijn gebruikt.
Notitie
U kunt de pidstat -r opdracht gebruiken om geheugenstatistieken per proces weer te geven.
Bepalen of er een resourcebeperking bestaat
U kunt bepalen of er een beperking bestaat met behulp van de vorige indicatoren en de huidige configuratie kennen. De beperking kan worden vergeleken met de bestaande 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 algehele VM. De vereiste van de toepassing versus wat de schijf- of VM-configuratie kan bieden, geeft de beperkingsresource aan.
Als voor de toepassing een meting1-resource><> is vereist <en de huidige configuratie voor <de resource> alleen< meting2> kan leveren, kan deze vereiste een beperkende factor zijn.
De beperkende resource definiëren
Nadat u hebt vastgesteld dat een resource de beperkende factor in de huidige configuratie moet zijn, bepaalt u hoe deze kan worden gewijzigd en hoe deze van invloed is op de workload. Er zijn situaties waarin het beperken van resources kan bestaan vanwege een kostenbesparende meting, maar de toepassing kan het knelpunt nog steeds zonder problemen verwerken.
Bijvoorbeeld:
Als voor de toepassing 128 GB (meting) ram (resource) is vereist en de huidige configuratie voor RAM (resource) slechts 64 GB (meting) kan leveren, kan deze vereiste een beperkende factor zijn.
U kunt nu de beperkende resource definiëren en acties uitvoeren op basis van die resource. Hetzelfde concept is van toepassing op andere resources.
Als deze limieten voor resources worden verwacht als een kostenbesparende meting, moet de toepassing de knelpunten omzeilen. Als er echter dezelfde kostenbesparende maatregelen bestaan en de toepassing het gebrek aan resources niet gemakkelijk kan verwerken, kan deze configuratie problemen veroorzaken.
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 kunnen alleen worden verplaatst naar een andere locatie van het ontwerp.
Als de toepassing bijvoorbeeld wordt beperkt door schijfprestaties, kunt u de schijfgrootte verhogen 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.
Door in de vorige stappen gegevens te verkrijgen, kunt u nu wijzigingen aanbrengen op basis van werkelijke, meetbare gegevens. U kunt deze wijzigingen ook vergelijken met de basislijn die u eerder hebt gemeten om te controleren of er een tastbaar verschil is.
Kijk een naar het volgende voorbeeld:
Wanneer u een basislijn hebt verkregen terwijl de toepassing werd uitgevoerd, hebt u vastgesteld dat het systeem een constant CPU-gebruik van 100 procent had in een configuratie van twee CPU's. U hebt een belastingsmiddelde van 4 waargenomen. Dit betekende dat het systeem aanvragen in de wachtrij plaatste. Een wijziging in een 8-CPU-systeem verminderde CPU-gebruik tot 25 procent, en het belastingsgemiddelde werd verlaagd tot 2 toen dezelfde belasting werd toegepast.
In dit voorbeeld is er 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
Migraties van een on-premises installatie naar cloud-computing kunnen worden beïnvloed door verschillende prestatieverschillen.
CPU
Afhankelijk van de architectuur kan een on-premises installatie CPU's uitvoeren met hogere kloksnelheden en grotere caches. Het resultaat zou lagere verwerkingstijden en hogere instructies per cyclus (IPC) zijn. 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 het equivalent in het CPU-aantal wordt gemaakt 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 worden gedefinieerd door het type en de grootte van de schijf (met uitzondering van Ultra-schijf, die flexibiliteit biedt met betrekking tot grootte, IOPS en doorvoer). De schijfgrootte definieert IOPS- en doorvoerlimieten.
Latentie is een metrische waarde die afhankelijk is van het schijftype in plaats van de schijfgrootte. De meeste on-premises opslagoplossingen zijn schijfmatrices met DRAM-caches. Dit type cache biedt een latentie van sub milliseconden (ongeveer 200 microseconden) en een hoge lees-/schrijfdoorvoer (IOPS).
De gemiddelde Azure-latenties worden weergegeven in de volgende tabel.
| Schijftype | Latentie |
|---|---|
| Ultra disk/Premium SSD v2 | Driecijferige μs (microseconden) |
| Premium SSD/Standard SSD | Ms met één cijfer (milliseconden) |
| Standard HDD | Ms met twee cijfers (milliseconden) |
Notitie
Een schijf wordt beperkt als deze de IOPS- of bandbreedtelimieten bereikt, omdat anders de latentie kan pieken tot 100 milliseconden of meer.
Het latentieverschil tussen een on-premises (vaak minder dan een milliseconde) en Premium SSD (milliseconden met één cijfer) wordt een beperkende factor. Let op de verschillen in latentie tussen de opslagaanbiedingen en selecteer het aanbod dat beter past bij de vereisten van de toepassing.
Netwerk
De meeste on-premises netwerkinstellingen gebruiken 10 Gbps-koppelingen. In Azure wordt de netwerkbandbreedte rechtstreeks gedefinieerd door de grootte van de virtuele machines (VM's). Sommige netwerkbandbreedten kunnen groter zijn dan 40 Gbps. Zorg ervoor dat u een grootte selecteert die voldoende bandbreedte heeft voor uw toepassingsbehoeften. In de meeste gevallen is de beperkende factor de doorvoerlimieten van de VM of schijf in plaats van het netwerk.
Geheugen
Selecteer een VM-grootte met voldoende RAM-geheugen voor wat momenteel is geconfigureerd.
Prestatiediagnose (PerfInsights)
PerfInsights is het aanbevolen hulpprogramma van ondersteuning voor Azure voor prestatieproblemen met vm's. Het is ontworpen om best practices en speciale analysetabbladen voor CPU, geheugen en I/O te behandelen. U kunt onDemand uitvoeren via Azure Portal of vanuit de VIRTUELE machine en de gegevens vervolgens delen met het ondersteuning voor Azure team.
PerfInsights uitvoeren
PerfInsights is beschikbaar voor zowel het Windows- als linux-besturingssysteem. Controleer of uw Linux-distributie in de lijst met ondersteunde distributies voor Prestatiediagnose voor Linux staat.
Rapporten uitvoeren en analyseren via Azure Portal
Wanneer PerfInsights wordt geïnstalleerd via Azure Portal, installeert de software een extensie op de VIRTUELE machine. Gebruikers kunnen PerfInsights ook als extensie installeren door rechtstreeks naar extensies op de vm-blade te gaan en vervolgens een optie voor prestatiediagnose te selecteren.
Optie 1 van Azure Portal
Blader door de vm-blade en selecteer de optie Prestatiediagnose . U wordt gevraagd om de optie (gebruikt extensies) te installeren op de virtuele machine waarvoor u deze hebt geselecteerd.
Optie 2 van Azure Portal
Blader naar het tabblad Problemen vaststellen en oplossen op de blade VM en zoek naar de koppeling Problemen oplossen onder PRESTATIEproblemen met vm's.
Wat u zoekt in het PerfInsights-rapport
Nadat u het PerfInsights-rapport hebt uitgevoerd, is de locatie van de inhoud afhankelijk van of het rapport is uitgevoerd via Azure Portal of als uitvoerbaar bestand. Voor beide opties opent u de gegenereerde logboekmap of downloadt u lokaal (indien in Azure Portal) 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 zien we bijvoorbeeld dat resultaten van gemiddelde impact zijn gedetecteerd die zijn gerelateerd aan Opslag en dat de bijbehorende aanbevelingen worden weergegeven. Als u de gebeurtenis Resultaten uitvouwt , ziet u verschillende belangrijke details.
Voor meer informatie over PerfInsights in het Linux-besturingssysteem raadpleegt u PerfInsights Linux gebruiken in Microsoft Azure.
Meer informatie
Problemen met prestaties van virtuele Azure-machines in Linux of Windows oplossen
Diagnostische gegevens over prestaties voor virtuele Azure-machines
Contact met ons opnemen voor ondersteuning
Als u vragen hebt of hulp nodig hebt, maakt u een ondersteuningsaanvraag of stelt u ondersteuning voor de Azure-community. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.