共用方式為


針對 Linux 中的效能和隔離瓶頸進行疑難排解

適用於:✔️ Linux VM

效能問題和瓶頸

在不同的作業系統或應用程式中發生效能問題時,每個問題都需要唯一的疑難排解方法。 CPU、記憶體、網路和輸入/輸出 (I/O) 是發生問題的關鍵區域。 這其中每一個區域都會顯示不同的徵兆 (有時會同時產生),因而需要不同的診斷和解決方案。

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

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

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

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

請務必瞭解瓶頸一律存在。 效能疑難解答全都是關於瞭解瓶頸發生的位置,以及如何將其移至較不違規的資源。

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

取得效能指標

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

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

資源 工具
CPU top、、 htopmpstatpidstatvmstat
磁碟 iostat、 、 iotopvmstat
網路 ip、 、 vnstatiperf3
記憶體 free、 、 topvmstat

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

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 使用量。

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

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

注意

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

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

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

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 來計算輸送量。

例如:

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

  • 1,000 IOPS at 1M IOSize = 1,000 MB/秒,或 1 GB/秒(精確 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 為單位顯示統計數據,這是更人性化的可讀形式。

命令中的數位 1iostat 指示每秒重新整理一次。 若要停止重新整理,請選取 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 此工具。

  • Server

    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百分比排序 。。 若要依記憶體使用率排序 ,請在執行 時選取 Shift+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 提供與 free KB 的類似輸出。

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

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

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 中,已連結 P30 磁碟,其容量為 200 MB/秒。 應用程式至少需要 100 MB/秒。

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

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

定義限制資源

在您判斷資源為目前組態中的限制因素之後,請識別資源如何變更,以及它如何影響工作負載。 有一些情況可能會因為節省成本措施而限制資源,但應用程式仍能夠處理瓶頸,而不會發生問題。

例如:

如果應用程式需要 128 GB 的 RAM(測量)RAM(資源),而 RAM (resource) 的目前設定只能提供 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 三位數的 is (微秒)
進階 SSD/標準 SSD 單一位數毫秒 (毫秒)
標準 HDD 兩位數毫秒(毫秒)

注意

如果磁碟達到 IOPS 或頻寬限制,就會進行節流,因為否則延遲可能會尖峰至 100 毫秒以上。

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

網路

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

記憶體

針對目前設定的項目,選取具有足夠 RAM 的 VM 大小。

效能診斷 (PerfInsights)

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

執行 PerfInsights

PerfInsights 適用於 WindowsLinux 作業系統。 確認您的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 的詳細資訊,請參閱 如何在 azure Microsoft 中使用 PerfInsights Linux。

其他相關資訊

與我們連絡,以取得說明

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