Felsök prestanda och isolera flaskhalsar i Linux
Gäller för: ✔️ Virtuella Linux-datorer
Prestandaproblem och flaskhalsar
När prestandaproblem uppstår i olika operativsystem och program kräver varje problem en unik metod för felsökning. CPU, minne, nätverk och indata/utdata (I/O) är viktiga områden där problem kan uppstå. Vart och ett av dessa områden visar olika symtom, ibland samtidigt, och kräver en egen diagnos och lösning.
Prestandaproblem kan orsakas av en felkonfiguration av programmet eller konfigurationen. Ett exempel är ett webbprogram som har ett cachelagringslager som inte är korrekt konfigurerat. Den här situationen utlöser fler begäranden som flödar tillbaka till ursprungsservern i stället för att hanteras från en cache.
I ett annat exempel finns omloggen för en MySQL- eller MariaDB-databas på operativsystemdisken (OS) eller på en disk som inte uppfyller databaskraven. I det här scenariot kan du se färre transaktioner per sekund (TPS) på grund av konkurrens om resurser och högre svarstider (svarstid).
Om du förstår problemet fullt ut kan du bättre identifiera var du ska titta på stacken (CPU, minne, nätverk, I/O). För att felsöka prestandaproblem måste du upprätta en baslinje som gör att du kan jämföra mått när du har gjort ändringar och utvärdera om den övergripande prestandan har förbättrats.
Att felsöka prestandaproblem för en virtuell dator (VM) skiljer sig inte från att lösa ett prestandaproblem i ett fysiskt system. Det handlar om att avgöra vilken resurs eller komponent som orsakar en flaskhals i systemet.
Det är viktigt att förstå att flaskhalsar alltid finns. Prestandafelsökning handlar om att förstå var en flaskhals inträffar och hur du flyttar den till en mindre felande resurs.
Den här guiden hjälper dig att identifiera och lösa prestandaproblem i Azure Virtual Machines i Linux-miljön.
Hämta prestandapekare
Du kan hämta prestandapekare som antingen bekräftar eller nekar om resursbegränsningen finns.
Beroende på vilken resurs som undersöks kan många verktyg hjälpa dig att hämta data som gäller för den resursen. Följande tabell innehåller exempel på huvudresurserna.
| Resurs | Verktyg |
|---|---|
| Processor | top, htop, mpstat, , , pidstatvmstat |
| Disk | iostat, , iotopvmstat |
| Nätverk | ip, , vnstatiperf3 |
| Minne | free, , topvmstat |
I de följande avsnitten beskrivs pekare och verktyg som du kan använda för att leta efter huvudresurserna.
CPU-resurs
En viss procentandel av processorn används eller inte. På samma sätt kan processer antingen spendera tid i CPU (till exempel 80 procent usr användning) eller inte (till exempel 80 procent inaktiv). Huvudverktyget för att bekräfta cpu-användningen är top.
Verktyget top körs som standard i interaktivt läge. Den uppdateras varje sekund och visar processer sorterade efter CPU-användning:
[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
Titta nu på processraden dd från utdata:
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
Du kan se att dd processen förbrukar 99,7 procent av processorn.
Kommentar
Du kan visa användning per PROCESSOR i
topverktyget genom att välja 1.Verktyget
topvisar en total användning på mer än 100 procent om processen är flertrådad och omfattar mer än en PROCESSOR.
En annan användbar referens är belastningsgenomsnitt. Belastningsgenomsnittet visar en genomsnittlig systembelastning i intervallet 1 minut, 5 minuter och 15 minuter. Värdet anger systemets belastningsnivå. Tolkningen av det här värdet beror på hur många processorer som är tillgängliga. Om belastningsgenomsnittet till exempel är 2 i ett en-CPU-system så läses systemet in så att processerna börjar köa. Om det finns ett belastningsgenomsnitt på 2 på ett system med fyra processorer finns det cirka 50 procent total CPU-användning.
Kommentar
Du kan snabbt hämta cpu-antalet genom att nproc köra kommandot .
I föregående exempel är belastningsgenomsnittet 1,04. Det här är ett två-CPU-system, vilket innebär att det finns cirka 50 procent cpu-användning. Du kan kontrollera det här resultatet om du ser värdet på 48,5 procent inaktiv CPU. (I kommandots top utdata visas värdet för inaktiv CPU före id etiketten.)
Använd belastningsgenomsnittet som en snabb översikt över hur systemet presterar.
uptime Kör kommandot för att hämta inläsningsgenomsnittet.
Diskresurs (I/O)
När du undersöker I/O-prestandaproblem hjälper följande termer dig att förstå var problemet uppstår.
| Period | Beskrivning |
|---|---|
| I/O-storlek | Mängden data som bearbetas per transaktion, vanligtvis definierad i byte. |
| I/O-trådar | Antalet processer som interagerar med lagringsenheten. Det här värdet beror på programmet. |
| Blockstorlek | I/O-storleken som definieras av enheten för säkerhetskopieringsblocket. |
| Sektorstorlek | Storleken på var och en av sektorerna på disken. Det här värdet är vanligtvis 512 byte. |
| IOPS | Indataåtgärder per sekund. |
| Svarstider | Den tid som en I/O-åtgärd tar att slutföra. Det här värdet mäts vanligtvis i millisekunder (ms). |
| Dataflöde | En funktion av mängden data som överförs under en viss tidsperiod. Det här värdet definieras vanligtvis som megabyte per sekund (MB/s). |
IOPS
Indatautdataåtgärder per sekund (IOPS) är en funktion av antalet indata- och utdataåtgärder (I/O) som mäts under en viss tid (i det här fallet sekunder). I/O-åtgärder kan antingen vara läsningar eller skrivningar. Borttagningar eller borttagningar kan också räknas som en åtgärd mot lagringssystemet. Varje åtgärd har en allokeringsenhet som motsvarar I/O-storleken.
I/O-storlek definieras vanligtvis på programnivå som mängden data som skrivs eller läss per transaktion. En vanlig I/O-storlek är 4K. En mindre I/O-storlek som innehåller fler trådar ger dock ett högre IOPS-värde. Eftersom varje transaktion kan slutföras relativt snabbt (på grund av dess lilla storlek) gör en mindre I/O att fler transaktioner kan slutföras på samma tid.
Anta tvärtom att du har samma antal trådar men använder ett större I/O. IOPS minskar eftersom varje transaktion tar längre tid att slutföra. Dataflödet ökar dock.
Ta följande som exempel:
1 000 IOPS innebär att för varje sekund slutförs tusen åtgärder. Varje åtgärd tar ungefär en millisekunder. (Det finns 1 000 millisekunder på en sekund.) I teorin har varje transaktion ungefär en millisekunder att slutföra, eller cirka 1 ms svarstid.
Genom att känna till IOSize-värdet och IOPS kan du beräkna dataflödet genom att multiplicera IOSize med IOPS.
Till exempel:
1 000 IOPS vid 4K IOSize = 4 000 KB/s eller 4 MB/s (3,9 MB/s för att vara exakt)
1 000 IOPS vid 1M IOSize = 1 000 MB/s eller 1 GB/s (976 MB/s för att vara exakt)
En mer ekvationsvänlig version kan skrivas på följande sätt:
IOPS * IOSize = IOSize/s (Throughput)
Genomflöde
Till skillnad från IOPS är dataflödet en funktion av mängden data över tid. Det innebär att under varje sekund skrivs eller läss en viss mängd data. Den här hastigheten mäts i mängden datatid/>>< eller megabyte per sekund (MB/s).<
Om du känner till dataflödet och IOSize-värdena kan du beräkna IOPS genom att dividera dataflödet med IOSize. Du bör normalisera enheterna till den minsta konnotationen. Om till exempel IOSize definieras i kilobyte (kb) ska dataflödet konverteras.
Ekvationsformatet skrivs på följande sätt:
Throughput / IOSize = IOPS
Om du vill placera den här ekvationen i ett sammanhang bör du överväga ett dataflöde på 10 MB/s med en IOSize på 4 K. När du anger värdena i ekvationen blir resultatet 10 240/4=2 560 IOPS.
Kommentar
10 MB är exakt lika med 10 240 KB.
Svarstid
Svarstid är mätningen av den genomsnittliga tid varje åtgärd tar att slutföra. IOPS och svarstid är relaterade eftersom båda begreppen är en tidsfunktion. Vid till exempel 100 IOPS tar varje åtgärd ungefär 10 ms att slutföra. Men samma mängd data kan hämtas ännu snabbare vid lägre IOPS. Svarstid kallas även söktid.
Förstå iostatutdata
Som en del av sysstat-paketet iostat ger verktyget insikter om diskprestanda och användningsstatistik. iostat kan hjälpa dig att identifiera flaskhalsar som är relaterade till diskundersystemet.
Du kan köra iostat med ett enkelt kommando. Här är den grundläggande syntaxen:
iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>
Parametrarna avgör vilken information iostat som finns. Utan att ha någon kommandoparameter iostat , visas grundläggande information:
[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
Som standard iostat visar data för alla befintliga blockenheter, även om minimala data tillhandahålls för varje enhet. Parametrar är tillgängliga som hjälper dig att identifiera problem genom att tillhandahålla utökade data (till exempel dataflöde, IOPS, köstorlek och svarstid).
Kör iostat genom att ange utlösare:
sudo iostat -dxctm 1
Om du vill expandera iostat resultaten ytterligare använder du följande parametrar.
| Parameter | Åtgärd |
|---|---|
-d |
Visa rapporten för enhetsanvändning. |
-x |
Visa utökad statistik. Den här parametern är viktig eftersom den innehåller storlekar för IOPS, svarstider och köer. |
-c |
Visa cpu-användningsrapporten. |
-t |
Skriv ut tiden för varje rapport som visas. Den här parametern är användbar för långa körningar. |
-m |
Visa statistik i megabyte per sekund, en mer läsbar form för människor. |
Siffran 1 i kommandot uppmanar iostat till uppdatering varje sekund. Om du vill stoppa uppdateringen väljer du Ctrl+C.
Om du inkluderar de extra parametrarna liknar utdata följande text:
[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
Förstå värden
Huvudkolumnerna iostat från utdata visas i följande tabell.
| Kolumn | Beskrivning |
|---|---|
r/s |
Läsningar per sekund (IOPS) |
w/s |
Skrivningar per sekund (IOPS) |
rMB/s |
Läsa megabyte per sekund (dataflöde) |
wMB/s |
Skriva megabyte per sekund (dataflöde) |
avgrq-sz |
Genomsnittlig I/O-storlek i sektorer; multiplicera det här talet med sektorstorleken, som vanligtvis är 512 byte, för att få I/O-storleken i byte (I/O-storlek) |
avgqu-sz |
Genomsnittlig köstorlek (antalet I/O-åtgärder i kö som väntar på att hanteras) |
await |
Genomsnittlig tid i millisekunder för I/O som hanteras av enheten (svarstid) |
r_await |
Genomsnittlig lästid i millisekunder för I/O som hanteras av enheten (svarstid) |
w_await |
Genomsnittlig lästid i millisekunder för I/O som hanteras av enheten (svarstid) |
De data som presenteras av iostat är informationsbaserade, men förekomsten av vissa data i vissa kolumner betyder inte att det finns ett problem. Data från iostat ska alltid samlas in och analyseras för möjliga flaskhalsar. Långa svarstider kan tyda på att disken når en mättnadspunkt.
Kommentar
Du kan använda pidstat -d kommandot för att visa I/O-statistik per process.
Nätverksresurs
Nätverk kan uppleva två huvudsakliga flaskhalsar: låg bandbredd och hög svarstid.
Du kan använda vnstat för att samla in bandbreddsinformation live. Är dock vnstat inte tillgängligt i alla distributioner. Det allmänt tillgängliga iptraf-ng verktyget är ett annat alternativ för att visa trafik i realtidsgränssnittet.
Svarstid för nätverk
Nätverksfördröjning i två olika system kan fastställas med hjälp av ett enkelt ping kommando i ICMP (Internet Control Message Protocol):
[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
Om du vill stoppa pingaktiviteten väljer du Ctrl+C.
Nätverksbandbredd
Du kan verifiera nätverksbandbredden med hjälp av verktyg som iperf3. Verktyget iperf3 fungerar på den server/klientmodell där programmet startas genom att -s ange flaggan på servern. Klienter ansluter sedan till servern genom att ange IP-adressen eller det fullständigt kvalificerade domännamnet (FQDN) för servern tillsammans med -c flaggan. Följande kodfragment visar hur du använder iperf3 verktyget på servern och klienten.
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.
Några vanliga iperf3 parametrar för klienten visas i följande tabell.
| Parameter | Description |
|---|---|
-P |
Anger antalet parallella klientströmmar som ska köras. |
-R |
Omvänt trafik. Som standard skickar klienten data till servern. |
--bidir |
Testar både uppladdning och nedladdning. |
Minnesresurs
Minne är en annan felsökningsresurs att kontrollera eftersom program kanske eller kanske inte använder en del av minnet. Du kan använda verktyg som free och top för att granska den totala minnesanvändningen och avgöra hur mycket minne olika processer förbrukar:
[root@rhel78 ~]# free -m
total used free shared buff/cache available
Mem: 7802 435 5250 9 2117 7051
Swap: 0 0 0
I Linux-system är det vanligt att se 99 procents minnesanvändning. I utdata free finns det en kolumn med namnet buff/cache. Linux-kerneln använder ledigt (oanvänt) minne för att cachelagra I/O-begäranden för bättre svarstider. Den här processen kallas för en sidcache. Under minnesbelastning (scenarier där minnet börjar ta slut) returnerar kerneln det minne som används för sidcacheminnet så att program kan använda det minnet.
I utdata free anger den tillgängliga kolumnen hur mycket minne som är tillgängligt för processer att använda. Det här värdet beräknas genom att lägga till mängden buff-/cacheminne och ledigt minne.
Du kan konfigurera top kommandot för att sortera processer efter minnesanvändning. Som standard top sorterar efter CPU-procentandel (%). Om du vill sortera efter minnesanvändning (%), väljer du Skift+M när du kör .top Följande text visar utdata från top kommandot:
[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
[...]
Kolumnen RES indikerar resident minne. Detta representerar faktisk processanvändning. Verktyget top ger ett liknande utdata som free när det gäller kilobyte (KB).
Minnesanvändningen kan öka mer än förväntat om programmet får minnesläckor. I ett scenario med minnesläckage kan program inte frigöra minnessidor som inte längre används.
Här är ett annat kommando som används för att visa de mest minneskrävande processerna:
ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
Följande text visar exempelutdata från kommandot:
[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
[...]
Du kan identifiera minnestryck från OOM-avlivningshändelser (Out of Memory), enligt följande exempelutdata:
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 anropas när både RAM-minne (fysiskt minne) och SWAP (disk) har förbrukats.
Kommentar
Du kan använda pidstat -r kommandot för att visa minnesstatistik per process.
Avgöra om det finns en resursbegränsning
Du kan avgöra om det finns en begränsning genom att använda de tidigare indikatorerna och känna till den aktuella konfigurationen. Begränsningen kan jämföras med den befintliga konfigurationen.
Här är ett exempel på en diskbegränsning:
En D2s_v3 virtuell dator kan hantera 48 MB/s utan dataflöde. Till den här virtuella datorn är en P30-disk ansluten som klarar 200 MB/s. Programmet kräver minst 100 MB/s.
I det här exemplet är den begränsande resursen dataflödet för den totala virtuella datorn. Kravet för programmet jämfört med vad disk- eller VM-konfigurationen kan ge anger den begränsande resursen.
Om programmet kräver en measurement1-resurs>>< och den aktuella konfigurationen för< resursen> endast< kan leverera measurement2>, kan det här kravet vara en begränsande faktor.<
Definiera den begränsande resursen
När du har fastställt att en resurs ska vara den begränsande faktorn i den aktuella konfigurationen kan du identifiera hur den kan ändras och hur den påverkar arbetsbelastningen. Det finns situationer där det kan finnas en begränsning av resurser på grund av ett kostnadsbesparande mått, men programmet kan fortfarande hantera flaskhalsen utan problem.
Till exempel:
Om programmet kräver 128 GB (mätning) ram (resurs) och den aktuella konfigurationen för RAM (resurs) bara kan leverera 64 GB (mätning) kan det här kravet vara en begränsande faktor.
Nu kan du definiera den begränsande resursen och vidta åtgärder baserat på den resursen. Samma begrepp gäller för andra resurser.
Om dessa begränsande resurser förväntas som ett kostnadsbesparande mått bör programmet kringgå flaskhalsarna. Men om samma kostnadsbesparande mått finns och programmet inte enkelt kan hantera bristen på resurser kan den här konfigurationen orsaka problem.
Göra ändringar baserat på erhållna data
Att utforma för prestanda handlar inte om att lösa problem utan om att förstå var nästa flaskhals kan uppstå och hur du kan kringgå den. Flaskhalsar finns alltid och kan bara flyttas till en annan plats i designen.
Om programmet till exempel begränsas av diskprestanda kan du öka diskstorleken för att tillåta mer dataflöde. Nätverket blir dock nästa flaskhals. Eftersom resurserna är begränsade finns det ingen idealisk konfiguration och du måste åtgärda problem regelbundet.
Genom att hämta data i föregående steg kan du nu göra ändringar baserat på faktiska, mätbara data. Du kan också jämföra dessa ändringar med den baslinje som du tidigare mätt för att kontrollera att det finns en påtaglig skillnad.
Ta följande som exempel:
När du fick en baslinje när programmet kördes fastställde du att systemet hade en konstant processoranvändning på 100 procent i en konfiguration av två processorer. Du observerade ett belastningsgenomsnitt på 4. Detta innebar att systemet köade begäranden. En ändring av ett 8-CPU-system minskade CPU-användningen till 25 procent och belastningsgenomsnittet minskades till 2 när samma belastning tillämpades.
I det här exemplet finns det en mätbar skillnad när du jämför de erhållna resultaten med de ändrade resurserna. Före ändringen fanns det en tydlig resursbegränsning. Men efter ändringen finns det tillräckligt med resurser för att öka belastningen.
Migrera från lokalt till molnet
Migreringar från en lokal installation till molnbaserad databehandling kan påverkas av flera prestandaskillnader.
Processor
Beroende på arkitekturen kan en lokal installation köra processorer som har högre klockhastigheter och större cacheminnen. Resultatet skulle bli minskade bearbetningstider och högre instruktioner per cykel (IPC). Det är viktigt att förstå skillnaderna i CPU-modeller och mått när du arbetar med migreringar. I det här fallet kanske en en-till-en-relation mellan CPU-antal inte räcker.
Till exempel:
I ett lokalt system som har fyra processorer som körs på 3,7 GHz finns det totalt 14,8 GHz tillgängligt för bearbetning. Om motsvarande antal processorer skapas med hjälp av en D4s_v3 virtuell dator som backas upp av 2,1 GHz-processorer har den migrerade virtuella datorn 8,1 GHz tillgängligt för bearbetning. Detta motsvarar en minskning av prestanda med 44 procent.
Disk
Diskprestanda i Azure definieras av typ och storlek på disken (förutom Ultra-disk, vilket ger flexibilitet när det gäller storlek, IOPS och dataflöde). Diskstorleken definierar IOPS- och dataflödesgränser.
Svarstid är ett mått som är beroende av disktyp i stället för diskstorlek. De flesta lokala lagringslösningar är diskmatriser som har DRAM-cacheminnen. Den här typen av cache ger svarstider på under millisekunder (cirka 200 mikrosekunder) och ett högt dataflöde för läsning/skrivning (IOPS).
Genomsnittliga Svarstider för Azure visas i följande tabell.
| Disktyp | Svarstid |
|---|---|
| Ultradisk/Premium SSD v2 | Tresiffriga μs (mikrosekunder) |
| Premium SSD/Standard SSD | Ensiffrig ms (millisekunder) |
| Standard HDD | Tvåsiffrig ms (millisekunder) |
Kommentar
En disk begränsas om den når sina IOPS- eller bandbreddsgränser, eftersom svarstiden annars kan öka till 100 millisekunder eller mer.
Fördröjningsskillnaden mellan en lokal (ofta mindre än en millisekunder) och Premium SSD (ensiffriga millisekunder) blir en begränsande faktor. Observera skillnaderna i svarstid mellan lagringserbjudandena och välj det erbjudande som bättre passar programmets krav.
Nätverk
De flesta lokala nätverksinstallationer använder 10 Gbit/s-länkar. I Azure definieras nätverksbandbredden direkt av storleken på de virtuella datorerna (VM). Vissa nätverksbandbredder kan överstiga 40 Gbit/s. Se till att du väljer en storlek som har tillräckligt med bandbredd för dina programbehov. I de flesta fall är begränsningsfaktorn dataflödesgränserna för den virtuella datorn eller disken i stället för nätverket.
Minne
Välj en VM-storlek som har tillräckligt med RAM-minne för det som för närvarande är konfigurerat.
Prestandadiagnostik (PerfInsights)
PerfInsights är det rekommenderade verktyget från Azure Support för prestandaproblem med virtuella datorer. Den är utformad för att täcka metodtips och dedikerade analysflikar för CPU, minne och I/O. Du kan köra den antingen OnDemand via Azure Portal eller inifrån den virtuella datorn och sedan dela data med Azure Support-teamet.
Kör PerfInsights
PerfInsights är tillgängligt för både Windows- och Linux-operativsystemet. Kontrollera att Linux-distributionen finns i listan över distributioner som stöds för prestandadiagnostik för Linux.
Köra och analysera rapporter via Azure Portal
När PerfInsights installeras via Azure Portal installerar programvaran ett tillägg på den virtuella datorn. Användare kan också installera PerfInsights som ett tillägg genom att gå direkt till bladet Tillägg på den virtuella datorn och sedan välja ett alternativ för prestandadiagnostik.
Azure Portal alternativ 1
Bläddra på vm-bladet och välj alternativet Prestandadiagnostik . Du uppmanas att installera alternativet (använder tillägg) på den virtuella dator som du valde det för.
Azure Portal alternativ 2
Bläddra till fliken Diagnostisera och lösa problem på bladet Virtuell dator och leta efter länken Felsök under Prestandaproblem för virtuella datorer.
Vad du ska leta efter i PerfInsights-rapporten
När du har kört PerfInsights-rapporten beror platsen för innehållet på om rapporten kördes via Azure Portal eller som en körbar fil. För båda alternativen kan du komma åt den genererade loggmappen eller (om i Azure Portal) ladda ned lokalt för analys.
Kör genom Azure Portal
Öppna PerfInsights-rapporten. Fliken Resultat loggar eventuella avvikande värden när det gäller resursförbrukning. Om det finns instanser av långsamma prestanda på grund av specifik resursanvändning kategoriserar fliken Resultat varje sökning som antingen Hög påverkan eller Medelpåverkan .
I följande rapport ser vi till exempel att resultat av medelpåverkan som är relaterade till Lagring har identifierats, och vi ser motsvarande rekommendationer. Om du expanderar händelsen Resultat visas flera viktiga detaljer.
Mer information om PerfInsights i Linux-operativsystemet finns i Så här använder du PerfInsights Linux i Microsoft Azure.
Mer information
Kontakta oss för att få hjälp
Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.