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

發行項
07/17/2023

效能問題和瓶頸

效能問題會發生在不同的作業系統或應用程式中，而且每個問題都需要唯一的方法來進行疑難排解。大部分的問題都與 CPU、記憶體、網路和輸入/輸出相關 (I/O) 作為發生問題的主要區域。這些區域中的每一個都會產生不同的徵兆 (有時會同時) ，而且需要不同的診斷和解決方案。

在某些情況下，效能問題可能是因為應用程式/安裝程式的設定錯誤所造成。例如，快取層未正確設定的 Web 應用程式。這種情況會導致更多要求回流至源伺服器，而不是由快取提供服務。

另一個範例是 MySQL/MariaDB 的重做記錄位於作業系統 (OS) 磁片，或位於不符合資料庫需求的磁片上。因資源競爭而導致每秒交易 (TPS) 減少。

能夠完全瞭解問題有助於識別堆疊上的設定錯誤會導致效能降低的位置。針對效能問題進行疑難排解需要建立基準，這會與之後所做的變更進行比較，並評估整體效能是否改善。

針對虛擬機器 (VM 進行疑難排解) 效能問題與針對實體電腦上的效能問題進行疑難排解並無不同;這是關於尋找造成系統瓶頸的資源或元件。

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

取得效能指標

如果資源條件約束存在，則可以取得效能指標來確認或拒絕。

視所調查的資源而定，有數個工具可協助取得與上述資源相關的資料。

範例如下：

資源	工具
CPU	top、htop
磁片	Iostat
網路	vnstat、iptraf-ng
記憶體	自由

若要進一步擴充，以下是尋找四個主要資源的一些指標和工具。

CPU

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 程式列 ：

22804 root 20 0 108096 616 516 R 99.7 0.0 1:05.71 dd

我們可以看到其耗用 100% 的 CPU (請注意， top 如果進程是多執行緒且跨越多個 CPU) ，則會顯示高於 100% 的使用量。

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

在上述範例中，負載平均值為 1.04。這是兩個 CPU 系統，表示大約 50% 的 CPU 使用量。此結果可由 48% 閒置 CPU 確認。

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

磁片

有數個字詞需要定義，以進一步瞭解 I/O 條件約束。

處理 I/O 效能問題時，下列詞彙有助於瞭解問題所在位置。

IO 大小：每個交易處理的資料量，通常以位元組為單位定義。
IO 執行緒：與存放裝置互動的進程數目取決於應用程式。
區塊大小：定義于檔案系統，是將寫入儲存體裝置的資料量。
磁區大小：磁片上每個磁區的大小，通常是 512 個位元組。
IOPS：每秒輸入輸出作業數。
延遲：I/O 作業完成所需的時間量。
輸送量：特定時間傳輸資料量的函式，通常定義為每秒 MB 或 MB。

IOPS

每秒輸入輸出作業 (IOPS) 是 I/O) 作業 (輸入和輸出數目的函式，在此案例中為秒數。 I/O 作業可以是讀取或寫入，刪除也可以計算為儲存體系統的作業。每個作業都會有一個配置單位，對應于 I/O 大小。

通常定義于應用層級，I/O 大小是每個交易將寫入或讀取的資料量。常見的 I/O 大小為 4k。具有更多執行緒的較小 IO 會產生較高的 IOPS，因為每個交易的完成速度都相當快速 (，因為其大小) ，因此可以在相同時間內完成更多專案。

相反地，具有相同數目的執行緒，但 I/O 大小較大時，IOPS 會隨著每筆交易需要較長的時間才能完成而關閉。

請考慮下列範例：

1000 IOPS 表示每秒會完成一千個作業，因此每個作業大約需要一毫秒 (一秒) 1000 毫秒。理論上，每筆交易大約需要一毫秒才能完成，或大約延遲 1 毫秒。

瞭解 IOSize 和 IOPS，我們可以將 IOSize 乘以 IOPS 來計算輸送量。

例如：

4K IOSize 的 1000 IOPS = 4000 KB/秒，或精確) 4 MB/秒 (3.9 MB/秒，或 1000 IOPS 在 1M = 1000 MB/秒，或 1 GB/秒 (976 MB/秒在技術上正確) 。

較易於方程式的版本會列為： IOPS * IOSize = IOSize/s (輸送量)

輸送量

與 IOPS 相反，輸送量是一段時間的資料量函數。這表示每秒會寫入或讀取特定數量的資料，此速度是以 AMOUNTOFDATA/時間 或每秒 MB/秒 (MB) 來測量。

使用輸送量和 IOSize 時，我們可以將輸送量除以 IOSize 來計算 IOPS，單位應該正規化為最小值，例如，如果 IOSize 定義為 KB 或 KB，則應轉換輸送量。

方程式格式看起來像這樣： THROUGHPUT / IOSize = IOPS

若要將此方程式放入內容中，請考慮 IOSize 為 4K 時的輸送量為 10 MB/秒，將數位新增至方程式看起來如下： 10240/4=2560 IOPS

(10 MB 等於 10240 KB)

延遲

延遲是測量每個作業完成時的平均時間量，IOPS 和延遲會連線，因為兩者都是時間的函式。例如，在 100 IOPS 中，每個作業大約需要 10ms 才能完成。但是即使 IOPS 較低，也可以更快速地擷取相同的資料量。延遲也稱為搜尋時間。

瞭解 iostat 輸出

iostat 是 sysstat 套件的公用程式一部分，此公用程式提供磁片效能和使用計量的深入解析。 iostat 有助於識別與磁片子系統相關的瓶頸。

iostat 是要執行的簡單命令，因為基本語法如下：

iostat <parameters> <time to refresh in seconds> <times to iterate> <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/秒：每秒讀取 MB (輸送量)
wMB/秒：每秒寫入 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 的資料，以找出可能的瓶頸。高延遲可能是表示磁片到達飽和點。

網路

網路上可能有兩個主要瓶頸：低頻寬和高延遲。

vnstat 可用來即時擷取頻寬詳細資料。不過， vnstat 無法在所有散發套件上使用。公 iptraf-ng 用程式已廣泛使用，而且是檢視即時介面流量的另一個選項。

若要判斷延遲，請執行 ping。

[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。

記憶體

記憶體是另一個要檢查的疑難排解資源，因為應用程式是否使用記憶體的一部分。和 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 百分比 (%) 排序。若要依記憶體使用率 (%) 排序，請在執行 top 時選取 Shift+M。

[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
  1086 root      20   0  586440  20100   6708 S   0.0  0.3   0:02.07 tuned
  3278 root      20   0  401788  19080   4808 S   0.0  0.2   0:01.44 python
  1475 root      20   0  222764  13876   4260 S   0.0  0.2   0:00.21 python
   773 polkitd   20   0  614328  13160   4688 S   0.0  0.2   0:00.62 polkitd
 10637 nxautom+  20   0  585784  12324   3616 S   0.0  0.2   0:04.03 python
   845 root      20   0  547976   8716   6644 S   0.0  0.1   0:00.80 NetworkManager
  1472 root      20   0  222764   7992   5176 S   0.0  0.1   0:01.39 rsyslogd
 10592 nxautom+  20   0  187924   7460   3004 S   0.0  0.1   0:02.56 python
     1 root      20   0  128404   6960   4148 S   0.0  0.1   0:09.29 systemd
  1389 root      20   0  307900   6708   4884 S   0.0  0.1   0:31.47 omiagent

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
  3124 omsagent        omsagent /opt/microsoft/omsagent/rub  0.1  0.6
  1680 python          root     python -u bin/WALinuxAgent-  1.8  0.4
 45921 python          omsagent python /opt/microsoft/omsco  3.0  0.1
 45909 python          omsagent python /opt/microsoft/omsco  2.7  0.1
 45912 python          omsagent python /opt/microsoft/omsco  3.0  0.1
 45953 python          omsagent python /opt/microsoft/omsco 11.0  0.1
 45902 python          omsagent python /opt/microsoft/omsco  3.0  0.1
  3278 python          root     python /var/lib/waagent/Mic  0.0  0.1

您可以從記憶體不足 (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。

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

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

以下是磁片條件約束的範例 ：「D2s_v3 VM 能夠有 48MB/秒的未快取輸送量，因此 P30 磁片已連結，且能夠有 200 MB。應用程式至少需要 100 MB/秒。」

在上述範例中，限制資源是整體 VM 的輸送量。應用程式的需求，與磁片或 VM 組態可提供的需求，會顯示什麼是限制資源。

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

定義限制資源

一旦將資源判斷為目前設定的限制因素之後，請識別其變更方式，以及其如何影響工作負載。有些實例可能會因為節省成本量值而存在限制資源，但應用程式仍然能夠處理瓶頸，而不會發生任何問題。

例如：

「如果應用程式需要< RAM (資源) >< 的 128 GB (度量) >，且RAM (資源) > 目前的 <組態只能提供< 64 GB (度量) >，則此需求可能是限制因素。」

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

如果預期這些限制資源是節省成本的量值，工作負載應該解決瓶頸。不過，如果存在相同的節省成本量值，而且工作負載無法輕鬆地處理資源不足的問題，您就必須解決此問題。

根據取得的資料執行變更

設計效能與解決問題無關。效能問題無法完全解決，因為一律會有限制的資源。瓶頸一律會存在，而且只能移至設計的不同位置。

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

使用先前步驟中取得的資料，現在可以根據實際可測量的資料來進行變更。這些變更也可以與之前測量的基準進行比較，以確認有形的差異。

檢查下列範例：

「在應用程式執行時取得基準時，判斷系統具有常數 100% CPU 使用量，且設定為兩個 CPU。觀察到負載平均值為 4，表示系統正在佇列要求。對 8CPU 系統的變更將 CPU 使用量降低至 25%，且負載平均已降低為 2 且負載完全相同。」

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

從內部部署移轉至雲端

從內部部署移轉牽涉到從內部部署設定移至雲端。

內部部署運算和雲端運算之間有幾個效能差異：

CPU：根據架構，內部部署安裝程式可能會以較高的時脈速度和更大的快取來執行 CPU，導致處理時間減少，以及每個週期的指示 (IPC) 。在進行移轉時，請務必瞭解 CPU 模型和計量的差異。在此情況下，CPU 計數之間的一對一關聯性可能不夠。

例如：

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

磁片：Azure 中的磁片效能是由磁片 (的類型和大小所定義，但 UltraSSD 除外，其可在大小、IOPS 和輸送量) 上提供彈性，而磁片大小會定義 IOPS 和輸送量限制。

延遲是相依于磁片類型而非磁片大小的計量。大部分的內部部署儲存體解決方案都是具有 DRAM 快取的磁片陣列，而這種類型的快取 (200us~) 延遲，以及 IOPS) (高讀取/寫入輸送量。

平均 Azure 延遲為：

UltraSSD：300 到 600 (微秒)
PremiumSSD/StandardSSD：3 毫秒到 10 毫秒 (毫秒)
StandardHDD：50 毫秒到 100 毫秒 (毫秒)

注意事項

若沒有作用中的節流功能，延遲可能會在節流磁片時增加到 800~1000ms。

內部部署 (200) 與 PremiumSSD (3000 或 3 毫秒) 之間的延遲差異極為禁止，在延遲) 方面，PremiumSSD (速度比內部部署慢 94%。

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

記憶體：選取具有足夠 RAM 的 VM 大小，以用於目前設定的內容。

效能診斷 (PerfInsights)

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

執行 PerfInsights

PerfInsights 適用于 Windows 和 Linux OS。確認您的散發版本位於 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 社群支援。

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

效能問題和瓶頸

取得效能指標

CPU

磁片

IOPS

輸送量

延遲

瞭解 iostat 輸出

瞭解值

網路

記憶體

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

定義限制資源

根據取得的資料執行變更

從內部部署移轉至雲端

效能診斷 (PerfInsights)

執行 PerfInsights

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

Azure 入口網站選項 1

Azure 入口網站選項 2

PerfInsights 報告中要尋找的內容

執行Azure 入口網站

其他資源

與我們連絡，以取得說明

意見反應

意見反應

其他資源

其他資源

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