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

[アーティクル]
03/27/2024

適用対象: ✔️ Linux VM

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

異なるオペレーティングシステムとアプリケーションでパフォーマンスの問題が発生した場合は、それぞれのケースでトラブルシューティングを行う独自のアプローチが必要です。 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`
ネットワーク	`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

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

Note

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

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

Note

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

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

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

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

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

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

Term	説明
IO サイズ	トランザクションごとに処理されるデータの量。通常はバイト単位で定義されます。
IO スレッド	ストレージデバイスと対話しているプロセスの数。この値は、アプリケーションによって異なります。
ブロックサイズ	バッキングブロックデバイスで定義されている I/O サイズ。
セクターサイズ	ディスクの各セクターのサイズ。通常、この値は 512 バイトです。
IOPS	1 秒あたりの入力出力操作数。
待機時間	I/O 操作が完了するまでの時間。通常、この値はミリ秒単位 (ミリ秒) で測定されます。
スループット	特定の時間にわたって転送されるデータの量の関数。通常、この値はメガバイト/秒 (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 秒ごとに 1,000 の操作が完了することを意味します。各操作には約 1 ミリ秒かかります。 (1 秒で 1,000 ミリ秒です)。理論上、各トランザクションの完了には約 1 ミリ秒、または待機時間は約 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/秒 (正確には 976 MB/秒)

より数式に優しいバージョンは、次のように記述できます。

IOPS * IOSize = IOSize/s (Throughput)

スループット

IOPS とは異なり、スループットは時間の経過に伴うデータ量の関数です。つまり、1 秒ごとに一定量のデータが書き込まれるか読み取られます。この速度は、 <amount-of-data>/<time>、またはメガバイト/秒 (MB/秒) で測定されます。

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

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

Throughput / IOSize = IOPS

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

Note

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

Latency

待機時間は、各操作が完了するまでの平均時間の測定です。両方の概念が時間の関数であるため、IOPS と待機時間は関連しています。たとえば、100 IOPS の場合、各操作の完了には約 10 ミリ秒かかります。ただし、同じ量のデータを、より低い IOPS でさらに迅速にフェッチできます。待機時間はシーク時間とも呼ばれます。

iostat の出力について

iostat ツールは、sysstat パッケージの一部として、ディスクのパフォーマンスと使用状況のメトリックに関する分析情報を提供します。 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 は、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`	1 秒あたりの読み取り (IOPS)
`w/s`	1 秒あたりの書き込み数 (IOPS)
`rMB/s`	1 秒あたりの読み取りメガバイト数 (スループット)
`wMB/s`	書き込みメガバイト/秒 (スループット)
`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からのデータは常にキャプチャされ、ボトルネックの可能性を分析する必要があります。待機時間が長い場合は、ディスクが飽和点に達していることを示している可能性があります。

Note

pidstat -d コマンドを使用して、プロセスごとの I/O 統計を表示できます。

ネットワークリソース

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

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

ネットワーク待機時間

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 アクティビティを停止するには、 Ctrl+C を選択します。

ネットワーク帯域幅

iperf3などのツールを使用して、ネットワーク帯域幅を確認できます。 iperf3 ツールは、サーバーで -s フラグを指定して、アプリケーションを起動するサーバー/クライアントモデルで動作します。その後、クライアントは、サーバーの IP アドレスまたは完全修飾ドメイン名 (FQDN) を -c フラグと組み合わせて指定して、サーバーに接続します。次のコードスニペットは、サーバーとクライアントで iperf3 ツールを使用する方法を示しています。

[サーバー]

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.

次の表に、クライアントの一般的な iperf3 パラメーターをいくつか示します。

パラメーター	説明
`-P`	実行する並列クライアントストリームの数を指定します。
`-R`	トラフィックを反転します。既定では、クライアントはサーバーにデータを送信します。
`--bidir`	アップロードとダウンロードの両方をテストします。

メモリリソース

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

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

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と同様の出力を提供します。

メモリ使用率は、アプリケーションで メモリリークが発生した場合に予想以上に増加する可能性があります。メモリリークのシナリオでは、アプリケーションは使用されなくなったメモリページを解放できません。

メモリ消費量の多いプロセスを表示するために使用されるもう 1 つのコマンドを次に示します。

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 (ディスク) の両方が消費された後に呼び出されます。

Note

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

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

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

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

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

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

アプリケーションに <measurement1><resource> が必要であり、 <resource の現在の構成> が <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 ディスクを除き、サイズ、IOPS、スループットに関する柔軟性が提供されます)。ディスクサイズは、IOPS とスループットの制限を定義します。

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

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

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

Note

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

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

ネットワーク

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

[メモリ]

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

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

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

PerfInsights を実行する

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

Azure portal を使用したレポートの実行と分析

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

Azure portal オプション 1

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

Azure portal オプション 2

VM ブレードの Diagnose and Solve Problems タブに移動し、VM パフォーマンスの問題の下にある トラブルシューティング リンクを探します。

PerfInsights レポートで検索する内容

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

Azure portal を使用して実行する

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

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

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

詳細

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

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

次の方法で共有

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

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

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

CPU リソース

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

IOPS

スループット

Latency

iostat の出力について

値を理解する

ネットワークリソース

ネットワーク待機時間

ネットワーク帯域幅

メモリリソース

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

制限リソースを定義する

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

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

CPU

ディスク

ネットワーク

[メモリ]

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

PerfInsights を実行する

Azure portal を使用したレポートの実行と分析

Azure portal オプション 1

Azure portal オプション 2

PerfInsights レポートで検索する内容

Azure portal を使用して実行する

詳細

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

フィードバック

その他のリソース

次の方法で共有

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

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

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

CPU リソース

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

IOPS

スループット

Latency

iostat の出力について

値を理解する

ネットワーク リソース

ネットワーク待機時間

ネットワーク帯域幅

メモリ リソース

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

制限リソースを定義する

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

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

CPU

ディスク

ネットワーク

[メモリ]

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

PerfInsights を実行する

Azure portal を使用したレポートの実行と分析

Azure portal オプション 1

Azure portal オプション 2

PerfInsights レポートで検索する内容

Azure portal を使用して実行する

詳細

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

フィードバック

その他のリソース

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

ネットワークリソース

メモリリソース