Linux でのパフォーマンスの問題のトラブルシューティングとボトルネックの分離

パフォーマンスの問題とボトルネック

異なるオペレーティング システムとアプリケーションでパフォーマンスの問題が発生した場合は、それぞれのケースでトラブルシューティングを行う固有のアプローチが必要です。 CPU、メモリ、ネットワーク、入出力 (I/O) は、問題が発生する可能性がある重要な領域です。 これらの領域はそれぞれ異なる症状 (場合によっては同時に) 表示され、さまざまな診断と解決策が必要です。

パフォーマンスの問題は、アプリケーションまたはセットアップの構成ミスが原因で発生する可能性があります。 たとえば、キャッシュ レイヤーが正しく構成されていない Web アプリケーションです。 この状況により、キャッシュから処理されるのではなく、配信元サーバーに戻る要求が増えます。

別の例では、MySQL または MariaDB データベースのやり直しログは、オペレーティング システム (OS) ディスクまたはデータベース要件を満たしていないディスクにあります。 このシナリオでは、リソースの競合と応答時間 (待機時間) が高いため、1 秒あたりのトランザクション数 (TPS) が少なくなる可能性があります。

問題を完全に理解していれば、スタック上の場所 (CPU、メモリ、ネットワーク、I/O) をより適切に特定できます。 パフォーマンスの問題をトラブルシューティングするには、変更後にメトリックを比較し、全体的なパフォーマンスが向上したかどうかを評価できる ベースライン を確立する必要があります。

仮想マシン (VM) のパフォーマンスの問題のトラブルシューティングは、物理システムでのパフォーマンスの問題を解決するのと同じ方法です。 これは、システムで ボトルネック を引き起こしているリソースまたはコンポーネントを特定することです。

ボトルネックは常に存在することを理解することが重要です。 パフォーマンスのトラブルシューティングは、ボトルネックが発生する場所と、問題の少ないリソースに移動する方法を理解することです。

このガイドは、Linux 環境での Azure Virtual Machinesのパフォーマンスの問題を検出して解決するのに役立ちます。

パフォーマンス ポインターを取得する

リソース制約が存在するかどうかを確認または拒否するパフォーマンス ポインターを取得できます。

調査対象のリソースによっては、そのリソースに関連するデータを取得するのに役立つツールが多数あります。 次の表に、メイン リソースの例を示します。

リソース ツール
CPU top, htop, mpstat, pidstat, vmstat
ディスク iostat, iotop, vmstat
Network ip, vnstat, iperf3
メモリ free, top, vmstat

次のセクションでは、メイン リソースを検索するために使用できるポインターとツールについて説明します。

CPU リソース

CPU の一定の割合が使用されるかどうか。 同様に、プロセスは CPU で時間を費やす (使用率が 80% usr など) か、(アイドル状態が 80% など) かのどちらかです。 CPU 使用率を確認するメイン ツールは ですtop

このツールは top 、既定で対話型モードで実行されます。 1 秒ごとに更新され、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

プロセスが CPU の dd 99.7% を消費していることがわかります。

注:

  • [1] を選択すると、topツールで CPU ごとの使用量を表示できます。

  • このツールは top 、プロセスがマルチスレッドで複数の CPU にまたがる場合、合計使用量が 100% を超えて表示されます。

もう 1 つの便利なリファレンスは、負荷平均です。 負荷平均は、1 分、5 分、15 分の間隔での平均システム負荷を示します。 値は、システムの負荷のレベルを示します。 この値の解釈は、使用可能な CPU の数によって異なります。 たとえば、1 CPU システムの負荷平均が 2 の場合、システムは非常に読み込まれ、プロセスがキューに入り始めます。 4 つの CPU システムの負荷平均が 2 の場合、全体的な CPU 使用率は約 50% です。

注:

コマンドを実行 nproc すると、CPU 数をすばやく取得できます。

前の例では、負荷平均は 1.04 です。 これは 2 つの CPU システムです。つまり、CPU 使用率は約 50% です。 この結果は、48.5% のアイドル CPU 値に気付いた場合に確認できます。 (コマンド出力 top では、アイドル状態の CPU 値がラベルの前に id 表示されます)。

負荷平均は、システムのパフォーマンスの概要として使用します。

コマンドを uptime 実行して、負荷平均を取得します。

ディスク (I/O) リソース

I/O パフォーマンスの問題を調査すると、次の用語が問題の発生場所を理解するのに役立ちます。

用語 説明
IO サイズ トランザクションごとに処理されるデータの量 。通常はバイト単位で定義されます。
IO スレッド ストレージ デバイスと対話しているプロセスの数。 この値はアプリケーションによって異なります。
ブロック サイズ バッキング ブロック デバイスによって定義された I/O サイズ。
セクター サイズ ディスクの各セクターのサイズ。 この値は通常 512 バイトです。
IOPS 1 秒あたりの入力出力操作。
Latency I/O 操作が完了するまでの時間。 この値は通常、ミリ秒単位 (ms) で測定されます。
スループット 特定の時間にわたって転送されるデータの量の関数。 この値は通常、1 秒あたりのメガバイト (MB/秒) として定義されます。

IOPS

1 秒あたりの入力出力操作 数 (IOPS) は、特定の時間 (この場合は秒) にわたって測定される入力および出力 (I/O) 操作の数の関数です。 I/O 操作は、読み取りまたは書き込みのいずれかです。 削除または破棄は、ストレージ システムに対する操作としてカウントすることもできます。 各操作には、I/O サイズと等しく対応する割り当て単位があります。

I/O サイズは、通常、トランザクションごとに書き込まれるデータまたは読み取りデータの量としてアプリケーション レベルで定義されます。 一般的に使用される I/O サイズは 4K です。 ただし、より多くのスレッドを含む I/O サイズが小さいほど、IOPS 値が高くなります。 各トランザクションは比較的高速に完了できるため (サイズが小さいため)、I/O を小さくすると、同じ時間でより多くのトランザクションを完了できます。

逆に、同じ数のスレッドがあるが、より大きな I/O を使用するとします。 各トランザクションの完了に時間がかかるため、IOPS が低下します。 ただし、スループットは増加します。

次の例について考えます。

1,000 IOPS は、1 秒ごとに 1000 の操作が完了することを意味します。 各操作には約 1 ミリ秒かかります。 (1 秒で 1,000 ミリ秒です)。理論的には、各トランザクションの完了時間は約 1 ミリ秒、待機時間は約 1 ミリ秒です。

IOSize の値と IOPS を把握することで、IOSize に IOPS を掛けてスループットを計算できます。

以下に例を示します。

  • 4K IOSize で 1,000 IOPS = 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 とは異なり、スループットは時間の経過に伴うデータ量の関数です。 つまり、1 秒ごとに一定量のデータが書き込まれるか読み取られます。 この速度は、データ/<時間> (メガバイト/秒) で測定<されます。>

スループットと IOSize の値がわかっている場合は、スループットを IOSize で割って IOPS を計算できます。 単位を最小の意味合いに正規化する必要があります。 たとえば、IOSize がキロバイト (kb) で定義されている場合、スループットを変換する必要があります。

数式の形式は次のように記述されます。

Throughput / IOSize = IOPS

この式をコンテキストに入れるには、IOSize が 4K の場合、10 MB/秒のスループットを考慮してください。 数式に値を入力すると、 結果は 10,240/4=2,560 IOPS になります

注:

10 MB は 10,240 KB と正確に等しくなります。

Latency

待機時間は、各操作が完了するまでにかかる平均時間の測定です。 どちらの概念も時間の関数であるため、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 統計を 1 秒あたりメガバイト単位で表示します。人間が判読しやすい形式です。

コマンドの数字 1 は、 iostat 1 秒ごとに更新するように指示します。 更新を停止するには、CtrlCキーを押します+。

追加のパラメーターを含める場合、出力は次のテキストのようになります。

    [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 1 秒あたりの読み取り (IOPS)
w/s 1 秒あたりの書き込み数 (IOPS)
rMB/s 1 秒あたりの読み取りメガバイト数 (スループット)
wMB/s 1 秒あたりの書き込みメガバイト数 (スループット)
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 統計を表示できます。

ネットワーク リソース

ネットワークでは、低帯域幅と待機時間の 2 つのメインボトルネックが発生する可能性があります。

を使用 vnstat して、帯域幅の詳細をライブ キャプチャできます。 ただし、 vnstat すべてのディストリビューションで使用できるわけではありません。 広く利用可能な iptraf-ng ツールは、リアルタイムインターフェイストラフィックを表示するための別のオプションです。

ネットワーク待機時間

2 つの異なるシステムのネットワーク待機時間は、インターネット制御メッセージ プロトコル (ICMP) の単純な 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 アクティビティを停止するには、CtrlCキーを押します+。

ネットワークの帯域幅

などの 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 アップロードとダウンロードの両方をテストします。

メモリ リソース

メモリは、アプリケーションがメモリの一部を使用する場合と使用しない場合があるため、チェックするもう 1 つのトラブルシューティング リソースです。 や などのfreetopツールを使用して、全体的なメモリ使用率を確認し、さまざまなプロセスで消費されているメモリ量を判断できます。

[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、使用可能な列は、プロセスが使用できるメモリの量を示します。 この値は、バフ/キャッシュ メモリと空きメモリの量を追加することによって計算されます。

メモリ使用率でプロセスを top 並べ替えるコマンドを構成できます。 既定では、 top CPU の割合 (%) で並べ替えられます。 メモリ使用率 (%)で並べ替えるには、 を実行topするときに Shift+M を選択します。 次のテキストは、 コマンドからの出力を 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) の観点からと同様の出力 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

OOM は、RAM (物理メモリ) と SWAP (ディスク) の両方が使用された後に呼び出されます。

注:

コマンドを pidstat -r 使用して、プロセスごとのメモリ統計を表示できます。

リソース制約が存在するかどうかを判断する

制約が存在するかどうかを判断するには、前のインジケーターを使用し、現在の構成を把握します。 制約は、既存の構成と比較できます。

ディスク制約の例を次に示します。

D2s_v3 VM では、キャッシュされていないスループットを 48 MB/秒で実行できます。 この VM には、200 MB/秒の P30 ディスクが接続されています。 アプリケーションには、少なくとも 100 MB/秒が必要です。

この例では、制限リソースは VM 全体のスループットです。 アプリケーションの要件と、ディスクまたは VM の構成で提供できる要件は、制約のあるリソースを示します。

アプリケーションで measurement1><リソース>が必要<で、リソース>の現在の構成<measurement2> のみを<提供できる場合、この要件が制限要因になる可能性があります。

制限リソースを定義する

現在の構成の制限要因となるリソースを決定したら、そのリソースを変更する方法と、それがワークロードにどのように影響するかを特定します。 コスト削減策のためにリソースの制限が存在する可能性がありますが、アプリケーションは問題なくボトルネックを処理できます。

以下に例を示します。

アプリケーションで RAM (リソース) の 128 GB (測定) が必要で、RAM (リソース) の現在の構成で 64 GB (測定) のみを提供できる場合、この要件が制限要因になる可能性があります。

これで、制限リソースを定義し、そのリソースに基づいてアクションを実行できます。 同じ概念が他のリソースにも当てはまります。

これらの制限リソースがコスト削減策として予想される場合、アプリケーションはボトルネックを回避する必要があります。 ただし、同じコスト削減策が存在し、アプリケーションがリソース不足を簡単に処理できない場合、この構成によって問題が発生する可能性があります。

取得したデータに基づいて変更を行う

パフォーマンスのための設計は、問題の解決ではなく、次のボトルネックが発生する可能性がある場所とその回避方法を理解することです。 ボトルネックは常に存在し、設計の別の場所にのみ移動できます。

たとえば、アプリケーションがディスク パフォーマンスによって制限されている場合は、ディスク サイズを増やしてスループットを高めることができます。 ただし、ネットワークは次のボトルネックになります。 リソースは限られているため、理想的な構成がないため、定期的に問題に対処する必要があります。

前の手順でデータを取得することで、実際の測定可能なデータに基づいて変更を加えることができます。 また、これらの変更を以前に測定したベースラインと比較して、具体的な違いがあることを確認することもできます。

次の例について考えます。

アプリケーションの実行中にベースラインを取得すると、2 つの CPU の構成で、システムの CPU 使用率が一定の 100% であると判断しました。 負荷平均が 4 であるのを確認しました。 これは、システムが要求をキューに入れていたことを意味します。 8 CPU システムへの変更により、CPU 使用率が 25% に減少し、同じ負荷が適用されたときに負荷平均が 2 に減少しました。

この例では、取得した結果を変更されたリソースと比較すると測定可能な違いがあります。 変更前は、明確なリソース制約が存在していました。 ただし、変更後は、負荷を増やすのに十分なリソースがあります。

オンプレミスからクラウドへの移行

オンプレミスのセットアップからクラウド コンピューティングへの移行は、いくつかのパフォーマンスの違いの影響を受ける可能性があります。

CPU

アーキテクチャによっては、オンプレミスのセットアップでは、クロック速度が高く、キャッシュが大きい CPU が実行される場合があります。 その結果、処理時間が短縮され、サイクルあたりの命令数が増えます (IPC)。 移行に取り組む場合は、CPU モデルとメトリックの違いを理解することが重要です。 この場合、CPU カウント間の 1 対 1 の関係では十分でない可能性があります。

以下に例を示します。

3.7 GHz で実行される 4 つの CPU を備えたオンプレミス システムでは、処理に合計 14.8 GHz を使用できます。 2.1 GHz CPU でサポートされているD4s_v3 VM を使用して CPU 数で同等のものが作成された場合、移行された VM の処理に使用できる 8.1 GHz があります。 これは、パフォーマンスの約 44% の低下を表します。

ディスク

Azure のディスク パフォーマンスは、ディスクの種類とサイズによって定義されます (Ultra disk を除き、サイズ、IOPS、スループットに関する柔軟性が提供されます)。 ディスク サイズは、IOPS とスループットの制限を定義します。

待機時間は、ディスク サイズではなくディスクの種類に依存するメトリックです。 ほとんどのオンプレミス ストレージ ソリューションは、DRAM キャッシュを持つディスク アレイです。 この種類のキャッシュは、ミリ秒未満 (約 200 マイクロ秒) の待機時間と高い読み取り/書き込みスループット (IOPS) を提供します。

Azure の平均待機時間を次の表に示します。

ディスクの種類 Latency
Ultra disk/Premium SSD v2 3 桁の μs (マイクロ秒)
Premium SSD/Standard SSD 1 桁の ms (ミリ秒)
Standard HDD 2 桁の ms (ミリ秒)

注:

ディスクが IOPS または帯域幅の制限に達すると調整されます。そうしないと、待機時間が 100 ミリ秒以上に急増する可能性があるためです。

オンプレミス (多くの場合、1 ミリ秒未満) と Premium SSD (1 桁のミリ秒) の待機時間の差が制限要因になります。 ストレージ オファリング間の待機時間の違いに注意し、アプリケーションの要件に適したオファリングを選択します。

Network

ほとんどのオンプレミス ネットワーク セットアップでは、10 Gbps のリンクが使用されます。 Azure では、ネットワーク帯域幅は仮想マシン (VM) のサイズによって直接定義されます。 一部のネットワーク帯域幅は 40 Gbps を超える可能性があります。 アプリケーションのニーズに十分な帯域幅を持つサイズを選択してください。 ほとんどの場合、制限要因は、ネットワークではなく VM またはディスクのスループット制限です。

メモリ

現在構成されているものに対して十分な RAM を持つ VM サイズを選択します。

パフォーマンス診断 (PerfInsights)

PerfInsights は、VM のパフォーマンスの問題にAzure サポートから推奨されるツールです。 CPU、メモリ、I/O のベスト プラクティスと専用の分析タブをカバーするように設計されています。 Azure portalまたは VM 内から OnDemand を実行し、Azure サポート チームとデータを共有できます。

PerfInsights を実行する

PerfInsights は、 Windows OS と Linux OS の両方で使用できます。 Linux ディストリビューションが、Linux のパフォーマンス診断で サポートされているディストリビューション の一覧にあることを確認します。

Azure portalを使用してレポートを実行および分析する

PerfInsights がAzure portalを介してインストールされると、ソフトウェアによって VM に拡張機能がインストールされます。 ユーザーは、[VM 内の拡張機能] ブレードに直接移動し、パフォーマンス 診断 オプションを選択することで、PerfInsights を拡張機能としてインストールすることもできます。

Azure portal オプション 1

[VM] ブレードを参照し、[パフォーマンス 診断] オプションを選択します。 選択した VM にオプション (拡張機能を使用) をインストールするように求められます。

[パフォーマンス診断レポート] 画面を示し、ユーザーにパフォーマンス 診断のインストールを求めるスクリーンショット。

Azure portal オプション 2

[VM] ブレードの [問題の診断と解決] タブを参照し、[VM のパフォーマンスの問題] の下にある [トラブルシューティング] リンクを探します。

[VM] ブレードの [問題の診断と解決] タブと、[VM のパフォーマンスの問題] の [トラブルシューティング] リンクを示すスクリーンショット。

PerfInsights レポートで探す内容

PerfInsights レポートを実行した後、コンテンツの場所は、レポートがAzure portal経由で実行されたか、実行可能ファイルとして実行されたかによって異なります。 どちらのオプションでも、生成されたログ フォルダーにアクセスするか、(Azure portalの場合) 分析のためにローカルにダウンロードします。

Azure portalを実行する

[パフォーマンス診断レポート] 画面を示し、生成された診断レポートが強調表示されているスクリーンショット。

PerfInsights レポートを開きます。 [ 結果 ] タブには、リソース使用量の観点から外れ値が記録されます。 特定のリソース使用量が原因でパフォーマンスが低下する場合、[ 結果 ] タブでは、各結果が [影響が大きい ] または [ 中程度 の影響] のいずれかに分類されます。

たとえば、次のレポートでは、ストレージに関連する 中程度 の影響の結果が検出され、対応する推奨事項が表示されます。 [結果] イベントを展開すると、いくつかの重要な詳細が表示されます。

PerfInsights レポートを示し、影響レベル、検索、影響を受けたリソース、推奨事項など、レポートの結果の詳細を示すスクリーンショット。

Linux OS の PerfInsights の詳細については、「 Microsoft Azure で PerfInsights Linux を使用する方法」を参照してください。

詳細

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。