針對Linux中的效能問題進行疑難解答並找出瓶頸

效能問題和瓶頸

當不同的操作系統和應用程式發生效能問題時,每個案例都需要唯一的方法來進行疑難解答。 CPU、記憶體、網路和輸入/輸出 (I/O) 是可能發生問題的主要區域。 這些區域中的每一個都會顯示不同的徵 (有時會同時) ,而且需要不同的診斷和解決方案。

效能問題可能是因為應用程式或安裝程序的設定錯誤所造成。 例如,具有未正確設定快取層的 Web 應用程式。 這種情況會觸發更多迴流至源伺服器的要求,而不是從快取提供服務。

在另一個範例中,MySQL 或 MariaDB 資料庫的重做記錄位於作業系統 (OS) 磁碟或不符合資料庫需求的磁碟上。 在此案例中,您可能會看到 TPS) 每秒 (較少的交易,因為資源競爭和回應時間 (延遲) 。

如果您完全了解問題,您可以更清楚地識別堆疊 (CPU、記憶體、網路、I/O) 。 若要針對效能問題進行疑難解答,您必須建立 基準 ,讓您在進行變更之後比較計量,並評估整體效能是否已改善。

針對虛擬機 (VM 進行疑難解答) 效能問題與解決實體系統上的效能問題並無不同。 這是關於判斷哪個資源或元件造成系統瓶頸。

請務必瞭解瓶頸永遠存在。 效能疑難解答全都與瞭解瓶頸發生的位置,以及如何將其移至較不符的資源有關。

本指南可協助您探索並解決 Linux 環境中 Azure 虛擬機器 中的效能問題。

取得效能指標

您可以取得效能指標,確認或拒絕資源條件約束是否存在。

根據所調查的資源,許多工具可協助您取得與該資源相關的數據。 下表包含主要資源的範例。

資源 工具
CPU top, htop, mpstat, pidstat, vmstat
磁碟 iostat, iotop, vmstat
網路 ip, vnstat, iperf3
記憶體 free, top, vmstat

下列各節討論可用來尋找主要資源的指標和工具。

CPU 資源

是否使用特定百分比的CPU。 同樣地,處理程式會將時間花在CPU (例如80%的 usr 使用量) ,或不 (例如80%閑置) 。 確認 CPU 使用量的主要工具是 top

top 工具預設會以互動式模式執行。 它會每秒重新整理一次,並顯示依 CPU 使用量排序的行程:

[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

現在,查看該輸出中的 dd 程式行:

   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

您可以看到行程 dd 耗用 99.7% 的 CPU。

注意事項

  • 您可以選取 [1],top在工具中顯示每個 CPU 使用量。

  • top如果進程是多線程且跨越多個CPU,則此工具會顯示超過100%的總使用量。

另一個有用的參考是負載平均值。 負載平均顯示 1 分鐘、5 分鐘和 15 分鐘間隔的平均系統負載。 值表示系統的負載層級。 解譯此值取決於可用的CPU數目。 例如,如果一個CPU系統上的負載平均值為2,系統就會載入,讓進程開始排入佇列。 如果四個 CPU 系統的負載平均值為 2,則整體 CPU 使用量大約為 50%。

注意事項

您可以執行 命令,快速取得CPU計數 nproc

在上一個範例中,負載平均值為 1.04。 這是兩個CPU系統,這表示大約50%的CPU使用量。 如果您注意到 48.5% 的閒置 CPU 值,您可以確認此結果。 (在命令輸出中 top ,閑置 CPU 值會顯示在 id label.)

使用負載平均值作為系統執行方式的快速概觀。

uptime執行 命令以取得負載平均值。

磁碟 (I/O) 資源

當您調查 I/O 效能問題時,下列詞彙可協助您了解問題發生的位置。

術語 描述
IO 大小 每個交易所處理的數據量,通常以位元組為單位定義。
IO 線程 與存儲設備互動的進程數目。 此值取決於應用程式。
區塊大小 支援區塊裝置所定義的 I/O 大小。
扇區大小 磁碟上每個扇區的大小。 這個值通常是512個字節。
IOPS 每秒輸入輸出作業數。
延遲 I/O 作業完成所需的時間。 此值通常以毫秒為單位, (毫秒) 。
輸送量 在特定時間內傳輸之數據量的函式。 此值通常定義為每秒 MB (MB/秒) 。

IOPS

每秒輸入輸出作業 (IOPS) 是一種函式,其中包含在特定時間 (測量的輸入和輸出 (I/O) 作業數目,在此案例中為秒) 。 I/O 作業可以是讀取或寫入。 刪除或捨棄也可以計算為對記憶體系統的作業。 每個作業都有一個配置單位,其對應等於 I/O 大小。

I/O 大小通常會在應用層級定義為每個交易寫入或讀取的數據量。 常用的 I/O 大小為 4K。 不過,包含更多線程的較小 I/O 大小會產生較高的 IOPS 值。 由於每個交易的完成速度相對較快, (因為其大小) ,所以較小的 I/O 可讓您在相同時間內完成更多交易。

相反地,假設您有相同數目的線程,但使用較大的 I/O。 IOPS 會減少,因為每個交易需要較長的時間才能完成。 不過,輸送量會增加。

請考慮下列範例:

1,000 IOPS 表示每秒有一千個作業完成。 每個作業大約需要一毫秒。 (一秒有 1,000 毫秒。) 理論上,每筆交易大約要完成一毫秒,或大約 1 毫秒的延遲。

藉由瞭解 IOSize 值和 IOPS,您可以將 IOSize 乘以 IOPS 來計算輸送量。

例如:

  • 4K IOSize 的 1,000 IOPS = 4,000 KB/秒,或 4 MB/秒 (3.9 MB/秒,以精確)

  • 1M IOSize 的 1,000 IOPS = 1,000 MB/秒,或 1 GB/s (976 MB/秒,以精確)

您可以撰寫更易於方程式的版本,如下所示:

IOPS * IOSize = IOSize/s (Throughput)

輸送量

不同於 IOPS,輸送量是一段時間內數據量的函式。 這表示每秒寫入或讀取一定數量的數據。 此速度是以 <數據>/<量時間>或每秒 MB (MB/秒) 來測量。

如果您知道輸送量和 IOSize 值,您可以將輸送量除以 IOSize 來計算 IOPS。 您應該將單位正規化為最小的外層。 例如,如果 IOSize 定義為 KB (kb) ,則應轉換輸送量。

方程式格式的撰寫方式如下:

Throughput / IOSize = IOPS

若要將此方程式放入內容中,請考慮 IOSize 為 4K 時的輸送量為 10 MB/秒。 當您在方程式中輸入值時,結果為 10,240/4=2,560 IOPS

注意事項

10 MB 精確地等於 10,240 KB。

延遲

延遲是測量每個作業完成所需的平均時間量。 IOPS 和延遲是相關的,因為這兩個概念都是時間的函式。 例如,在 100 IOPS 時,每個作業大約需要 10 毫秒才能完成。 但是在較低的 IOPS 中,可以更快速地擷取相同的數據量。 延遲也稱為搜尋時間。

瞭解iostat輸出

作為 sysstat 套件的一部分,此 iostat 工具提供磁碟效能和使用計量的深入解析。 iostat 有助於識別與磁碟子系統相關的瓶頸。

您可以 iostat 在簡單的命令中執行。 基本語法如下所示:

iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>

參數會指定所提供的資訊 iostat 。 在沒有任何命令參數的情況下, iostat 顯示基本詳細數據:

[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 會顯示所有現有區塊裝置的數據,但會為每個裝置提供最少的數據。 您可以使用參數,藉由提供擴充數據 (,例如輸送量、IOPS、佇列大小和延遲) 來協助找出問題。

iostat 由指定觸發程式來執行:

sudo iostat -dxctm 1

若要進一步展開 iostat 結果,請使用下列參數。

參數 動作
-d 顯示裝置使用率報告。
-x 顯示擴充統計數據。 這個參數很重要,因為它提供IOPS、延遲和佇列大小。
-c 顯示 CPU 使用率報告。
-t 列印每個顯示報表的時間。 此參數適用於長時間執行。
-m 以每秒 MB 為單位顯示統計數據,這是更容易閱讀的形式。

命令中的數 1 值會指示 iostat 每秒重新整理一次。 若要停止重新整理,請選取 Ctrl+C

如果您包含額外的參數,輸出會類似下列文字:

    [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

瞭解值

下表顯示輸出中 iostat 的主要數據行。

描述
r/s 每秒讀 (IOPS)
w/s 每秒寫入 (IOPS)
rMB/s 每秒讀取 MB (輸送量)
wMB/s 每秒寫入 MB (輸送量)
avgrq-sz 扇區的平均 I/O 大小;將此數位乘以扇區大小,通常是512個字節,以取得以位元組為單位的I/O大小 (I/O 大小)
avgqu-sz 佇列平均大小 (等候提供服務的 I/O 作業數目)
await 裝置所提供 I/O 的平均時間以毫秒為單位, (延遲)
r_await 裝置所提供 I/O 的平均讀取時間以毫秒為單位, (延遲)
w_await 裝置所提供 I/O 的平均讀取時間以毫秒為單位, (延遲)

所呈現 iostat 的數據是參考數據,但特定數據行中存在特定數據並不表示發生問題。 一律應擷取並分析來自 iostat 的數據,以找出可能的瓶頸。 高延遲可能表示磁碟到達飽和點。

注意事項

您可以使用 pidstat -d 命令來檢視每個行程的 I/O 統計數據。

網路資源

網路可能會遇到兩個主要瓶頸:低頻寬和高延遲。

您可以使用 vnstat 即時擷取頻寬詳細數據。 不過, vnstat 不適用於所有散發套件。 廣泛使用的 iptraf-ng 工具是檢視即時介面流量的另一個選項。

網路等待時間

您可以使用因特網控制訊息通訊協定中的簡單 ping 命令來判斷兩個不同系統中的網路等待時間 (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

若要停止 Ping 活動,請選取 Ctrl+C

網路頻寬

您可以使用 之類的 iperf3工具來驗證網路頻寬。 此 iperf3 工具可在啟動應用程式的伺服器/用戶端模型上運作,方法是在伺服器上指定 -s 旗標。 用戶端接著會將伺服器的IP位址或完整功能變數名稱指定 (FQDN) 與旗標一起 -c 連線到伺服器。 下列代碼段示範如何在伺服器和用戶端上使用 iperf3 工具。

  • 伺服器

    root@ubnt:~# iperf3 -s
    -----------------------------------------------------------
    Server listening on 5201
    -----------------------------------------------------------
    
  • 用戶端

    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.
    

下表顯示用戶端的一些常見 iperf3 參數。

參數 描述
-P 指定要執行的平行用戶端數據流數目。
-R 反轉流量。 根據預設,用戶端會將數據傳送至伺服器。
--bidir 測試上傳和下載。

記憶體資源

記憶體是另一個要檢查的疑難解答資源,因為應用程式可能或可能不會使用記憶體的一部分。 您可以使用和 top 之類的free工具來檢閱整體記憶體使用率,並判斷各種進程耗用多少記憶體:

[root@rhel78 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           7802         435        5250           9        2117        7051
Swap:             0           0           0

在 Linux 系統中,通常會看到 99% 的記憶體使用率。 在輸出中 free ,有一個名為的數據 buff/cache行。 Linux 核心會使用免費 (未使用的) 記憶體來快取 I/O 要求,以獲得更好的回應時間。 此程序稱為 頁面快取。 在記憶體壓力 (記憶體不足) 的情況下,核心會傳回用於 頁面快取 的記憶體,讓應用程式可以使用該記憶體。

在輸出中 free可用 的數據行會指出進程可用的記憶體數量。 此值的計算方式是新增buff/cache記憶體和可用記憶體的數量。

您可以設定 命令, top 依記憶體使用率排序進程。 根據預設, 會 top 依 CPU 百分比 (% ) 排序。 若要依記憶體使用率 (%) 排序,請在執行 時選取 [移位+M ] top。 下列文字顯示命令的 top 輸出:

[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
[...]

數據行 RES 表示 常駐記憶體。 這代表實際的進程使用量。 此 top 工具提供類似 KB (KB) 的輸出 free

如果應用程式發生 記憶體流失,記憶體使用率可能會超出預期。 在記憶體流失案例中,應用程式無法釋放不再使用的記憶體頁面。

以下是用來檢視最常耗用記憶體進程的另一個命令:

ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head

下列文字顯示命令的範例輸出:

[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
[...]

您可以識別記憶體不足 (OOM) Kill 事件的記憶體壓力,如下列範例輸出所示:

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

在取用 RAM (物理記憶體) 和 SWAP (磁碟) 之後,就會叫用 OOM。

注意事項

您可以使用 pidstat -r 命令來檢視每個行程記憶體統計數據。

判斷資源條件約束是否存在

您可以使用先前的指標並瞭解目前的組態,判斷條件約束是否存在。 條件約束可以與現有的組態進行比較。

以下是磁碟條件約束的範例:

D2s_v3 VM 能夠有 48 MB/秒的未快取輸送量。 在此 VM 中,會連結可 200 MB/秒的 P30 磁碟。 應用程式至少需要 100 MB/秒。

在此範例中,限制資源是整體 VM 的輸送量。 應用程式的需求與磁碟或 VM 組態可提供的專案,表示限制資源。

如果應用程式需要 <measurement1><資源>,且資源的目前設定<>只能<提供 measurement2>,則此需求可能是限制因素。

定義限制資源

在您判斷資源是目前組態的限制因素之後,請識別其變更方式,以及其如何影響工作負載。 在某些情況下,可能會因為節省成本的量值而存在限制資源,但應用程式仍然能夠處理瓶頸,而不會發生任何問題。

例如:

如果應用程式需要 RAM (資源) 的 128 GB (度 ) ,且 RAM (資源) 目前的設定只能提供 64 GB (度量) ,則此需求可能是限制因素。

現在,您可以定義限制資源,並根據該資源採取動作。 相同的概念也適用於其他資源。

如果這些限制資源預期為節省成本的量值,應用程式應該解決瓶頸。 不過,如果存在相同的節省成本量值,且應用程式無法輕易處理資源不足的問題,此設定可能會造成問題。

根據取得的數據進行變更

設計效能並不是要解決問題,而是要瞭解下一個瓶頸的發生位置,以及如何解決此問題。 瓶頸永遠存在,而且只能移至設計的不同位置。

例如,如果應用程式受限於磁碟效能,您可以增加磁碟大小以允許更多輸送量。 不過,網路接著會成為下一個瓶頸。 因為資源有限,所以沒有理想的設定,您必須定期解決問題。

藉由取得先前步驟中的數據,您現在可以根據實際可測量的數據進行變更。 您也可以將這些變更與先前測量的基準進行比較,以確認有形的差異。

請考慮下列範例:

當您在應用程式執行時取得基準時,您判斷系統在兩個 CPU 的組態中有 100% 的常數 CPU 使用量。 您觀察到負載平均值為 4。 這表示系統正在佇列要求。 變更 8-CPU 系統會將 CPU 使用量降低至 25%,而套用相同的負載時,負載平均值會降低為 2。

在此範例中,當您比較取得的結果與變更的資源時,會有可測量的差異。 變更之前,有明確的資源條件約束。 但在變更之後,有足夠的資源可增加負載。

從內部部署移轉至雲端

從內部部署設定移轉至雲端運算可能會受到數個效能差異的影響。

CPU

視架構而定,內部部署安裝程式可能會執行具有較高時鐘速度和較大快取的CPU。 結果會減少處理時間,而 IPC) (每個週期的指示也會增加。 當您進行移轉時,請務必瞭解 CPU 模型和計量的差異。 在此情況下,CPU 計數之間的一對一關聯性可能不夠。

例如:

在具有四個 CPU 且在 3.7 GHz 執行的內部部署系統中,總共有 14.8 GHz 可供處理。 如果使用由 2.1-GHz CPU 支援的D4s_v3 VM 來建立 CPU 計數中的對等專案,則已移轉的 VM 有 8.1 GHz 可供處理。 這表示效能大約降低44%。

磁碟

Azure 中的磁碟效能是由磁碟 (的類型和大小所定義,但 Ultra 磁碟除外,其可在大小、IOPS 和輸送量) 方面提供彈性。 磁碟大小會定義 IOPS 和輸送量限制。

延遲是相依於磁碟類型而非磁碟大小的計量。 大部分的內部部署記憶體解決方案都是具有 DRAM 快取的磁碟數位。 這種快取類型提供約 200 毫秒的 (,) 延遲和 IOPS) (高讀取/寫入輸送量。

下表顯示平均 Azure 延遲。

磁碟類型 延遲
Ultra 磁碟/進階 SSD v2 三位數 μs (微秒)
進階 SSD/標準 SSD 單一位數 ms (毫秒)
標準 HDD 兩位數毫秒 (毫秒)

注意事項

如果磁碟達到其 IOPS 或頻寬限制,則會進行節流,否則延遲可能會突然增加至 100 毫秒以上。

內部部署 (通常小於毫秒) 與進階 SSD 之間的延遲差異 (單一位數毫秒) 成為限制因素。 請注意記憶體供應專案之間的延遲差異,然後選取更符合應用程式需求的供應專案。

網路

大部分的內部部署網路設定都會使用 10 Gbps 連結。 在 Azure 中,網路頻寬會直接由 VM) (虛擬機大小來定義。 某些網路頻寬可能超過 40 Gbps。 請確定您選取的大小足以滿足應用程式需求。 在大部分情況下,限制因素是 VM 或磁碟的輸送量限制,而不是網路。

記憶體

選取具有足夠 RAM 供目前設定的 VM 大小。

效能診斷 (PerfInsights)

針對 VM 效能問題,PerfInsights 是來自 Azure 支援 的建議工具。 其設計目的是要涵蓋 CPU、記憶體和 I/O 的最佳做法和專用分析索引標籤。 您可以透過 Azure 入口網站 或從 VM 內執行 OnDemand,然後與 Azure 支援 小組共享數據。

執行 PerfInsights

PerfInsights 適用於 WindowsLinux OS。 確認您的Linux發行版位於Linux效能診斷 支援的發行版 清單中。

透過 Azure 入口網站 執行和分析報表

透過 Azure 入口網站 安裝 PerfInsights 時,軟體會在 VM 上安裝擴充功能。 使用者也可以直接移至 [VM] 刀鋒視窗中的 [擴充功能],然後選取效能診斷選項,以將PerfInsights安裝為擴充功能。

Azure 入口網站 選項 1

流覽 [VM] 刀鋒窗口,然後選取 [ 效能診斷] 選項。 系統會要求您安裝選項, (在您選取的 VM 上使用擴充功能) 。

顯示 [效能診斷報告] 畫面的螢幕快照,並要求使用者安裝效能診斷。

Azure 入口網站 選項 2

流覽至 [VM] 刀鋒視窗中的 [診斷和解決問題] 索引卷標,並尋找 [VM 效能問題] 底下的 [疑難解答] 連結。

此螢幕快照顯示 [VM] 刀鋒視窗中的 [診斷和解決問題] 索引標籤,以及 [VM 效能問題] 底下的 [疑難解答] 連結。

PerfInsights 報告中要尋找的內容

執行 PerfInsights 報表之後,內容的位置取決於報表是透過 Azure 入口網站 還是可執行文件執行。 針對任一選項,請存取產生的記錄檔資料夾,如果在本機下載以進行分析,則 Azure 入口網站) (。

執行 Azure 入口網站

顯示 [效能診斷報告] 畫面的螢幕快照,並醒目提示產生的診斷報告。

開啟 PerfInsights 報告。 [ 結果 ] 索引標籤會根據資源耗用量記錄任何極端值。 如果有因為特定資源使用量而效能變慢的實例,[ 結果 ] 索引卷標會將每個發現分類為 [高 影響] 或 [ 度影響]。

例如,在下列報告中,我們看到偵測到與記憶體相關的 度影響結果,並且看到對應的建議。 如果您展開 [結果 ] 事件,您會看到數個主要詳細數據。

顯示 PerfInsights 報表的螢幕快照,並詳細說明報表的結果,包括影響層級、尋找、受影響的資源和建議。

如需Linux OS中 PerfInsights 的詳細資訊,請檢閱 如何在 Microsoft Azure 中使用 PerfInsights Linux

其他相關資訊

與我們連絡,以取得說明

如果您有問題或需要相關協助,請建立支援要求,或詢問 Azure community 支援。 您也可以將產品意見反應提交給 Azure 意應見反社群