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

適用対象: ✔️ Linux VM

まとめ

CPU、メモリ、ディスクの入出力のパフォーマンスに関する問題のトラブルシューティングを行い、Azure の Linux 仮想マシン (VM) 上のボトルネックを特定します。

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

パフォーマンスの問題は、さまざまなオペレーティングシステムとアプリケーションで発生する可能性があります。各シナリオには、対象を絞ったトラブルシューティングアプローチが必要です。 Linux VM では、通常、CPU、メモリ、ネットワーク、入出力 (I/O) という 1 つ以上のコアリソース領域でパフォーマンスの問題が発生します。各リソースは個別の症状を示し、多くの場合、重複しており、さまざまな診断方法と修復戦略が必要です。

多くの場合、アプリケーションまたは構成の問題は、プラットフォーム自体ではなく、パフォーマンスの低下を引き起こします。たとえば、キャッシュレイヤーが正しく構成されていない Web アプリケーションでは、キャッシュから提供されるのではなく、過剰な要求が配信元サーバーにルーティングされる可能性があります。この構成ミスにより、CPU の負荷と応答時間が増加します。同様に、ストレージの配置はデータベースワークロードに影響を与える可能性があります。 MySQL または MariaDB データベースの再実行ログがオペレーティングシステムディスクまたはデータベースのパフォーマンス要件を満たしていないストレージ上に存在する場合、I/O 競合により待機時間が長くなり、1 秒あたりのトランザクション数 (TPS) が減少する可能性があります。

効果的なトラブルシューティングは、まず問題を理解し、CPU、メモリ、ネットワーク、I/O のいずれであるかに関係なく、スタック内にボトルネックが存在する場所を特定することです。パフォーマンスベースラインの確立は重要です。これにより、変更前と変更後のメトリックを比較し、それらの変更によって測定可能な改善が行われるかどうかを判断できます。

仮想マシンでのパフォーマンスの問題のトラブルシューティングは、基本的に物理システムの場合と同じです。目標は、全体的なパフォーマンスを制限しているリソースを特定することです。ボトルネックは常に任意のシステムに存在します。パフォーマンスのトラブルシューティングは、現在のボトルネックを特定し、可能な場合は制限の緩いリソースに移行するプロセスです。

このガイドは、ボトルネックの分離と対象となる診断の適用に重点を置くことで、Linux ベースの Azure VM のパフォーマンスの問題を特定して解決するのに役立ちます。

ボトルネックの可能性を特定する

個別のリソース使用率ではなく、システムの動作とメトリックの関係を監視してトラブルシューティングを開始します。パフォーマンスのボトルネックは多くの場合、間接的に発生し、制約付きリソースが常に最も明白なわけではありません。

次の表は、一般的な観察とメトリックパターンを、最初に調査する可能性の最も高いリソースにマップします。

観測または信号	調査のボトルネックの可能性	根拠
平均負荷が高いが、CPU 使用率が低い	ディスク (入力/出力)	プロセスは、CPU 上で実行されるのではなく、I/O で待機中にブロックされます
負荷平均が低いにもかかわらず、CPU使用率が高い	アプリケーション設計またはシングルスレッドワークロード	CPUはビジー状態ですが、利用可能なコア全体での負荷は飽和していません。
負荷中の要求待ち時間の増加、CPU が飽和しない	ディスクまたはネットワーク	使用率の制限に達する前に待機時間が長くなることがよくあります
安定したワークロードでの急激な CPU 使用率の変動	CPU 制限またはバースト制限	プラットフォームの制約により、CPU の可用性が異なる場合があります
低スループットで高い I/O 待機時間	ディスクの飽和またはスロットリング	帯域幅制限に達する前の待機時間の増加
時間の経過と同時にメモリ使用量を徐々に増加させる	メモリリークまたはキャッシュの増加	メモリの負荷はすぐにではなく徐々に発達する
使用可能なディスク領域にもかかわらずメモリ不足 (OOMKilled) イベント	[メモリ]	ディスクの可用性によって RAM の枯渇が軽減されない
許容範囲内のディスク指標だが、アプリケーションのI/Oは遅い	アプリケーション I/O パターン	小さい操作または同期 I/O 操作によってパフォーマンスが制限される
予想を下回るネットワークスループット	VM サイズまたはネットワークインターフェイスカード (NIC) の制限	ネットワーク帯域幅は VM SKU によって制限されます
ピーク使用時にのみパフォーマンスが低下する	容量の制約	リソースの制限に達するのはコンカレンシーの下のみです

最も関連性の高いパターンを特定したら、対応するリソースセクションに進み、詳細な診断と検証を行います。

Important

ボトルネックは、個々の使用率値ではなく、メトリック間のリレーションシップによって識別されます。 CPU、メモリ、ディスク、およびネットワークデータを常に一緒に解釈します。

パフォーマンスの分析情報を収集する

これらのパフォーマンス分析情報を使用して、リソースのボトルネックが存在するかどうかを検証します。

調査対象のリソースに応じて、さまざまなツールでパフォーマンスデータが収集されます。次の表に、プライマリリソースのツールの例を示します。

リソース	ツール
CPU	`top`、 `htop`、 `mpstat`、 `pidstat`、 `vmstat`
Disk	`iostat`、 `iotop`、 `vmstat`
ネットワーク	`ip`、 `vnstat`、 `iperf3`
[メモリ]	`free`、 `top`、 `vmstat`

次のセクションでは、調査に使用できるパフォーマンスデータとツールについて説明します。

CPU リソース

CPU 使用率は、プロセッサがアクティブに作業を実行する時間とアイドル状態の残りの時間の割合を表します。同様に、プロセスは CPU (使用率の 80% usr など) に時間を費やすか、(アイドル状態が 80% のように) 使われません。 CPU 使用率を確認するためのメインツールが top。

top ツールは、既定で対話型モードで実行されます。 1 秒ごとに更新され、CPU 使用率で並べ替えられたプロセスが表示されます。

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% を消費していることがわかります。

注

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% です。アイドル状態の CPU 値が 48.5% である場合は、この結果を確認できます。 ( top コマンド出力では、アイドル状態の CPU 値が id ラベルの前に表示されます)。

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

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

Important

負荷平均は、CPU 使用率のコンテキストを提供します。低アイドル CPU の高負荷は飽和を示しますが、アイドル状態の CPU の高負荷は多くの場合、CPU 以外のボトルネックを指します。

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

次の用語は、I/O パフォーマンスカウンターを識別して理解する方法を説明するのに役立ちます。

用語	説明
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 秒ごとに一定量のデータが書き込まれるか読み取られたことを意味します。この速度は/<time>、またはメガバイト/秒 (MB/秒) で測定します。

スループットと I/O サイズの値がわかっている場合は、スループットを I/O サイズで割って IOPS を計算できます。両方の値を同じ測定単位に正規化する必要があります。たとえば、I/O サイズがキロバイト (KB) で定義されている場合は、計算を実行する前にスループットを KB に変換する必要があります。

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

Throughput / IOSize = IOPS

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

注

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

レイテンシ

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

iostat の出力について

iostat ツールは、sysstat パッケージの一部として、ディスクのパフォーマンスと使用状況のメトリックに関する分析情報を提供します。 iostat は、ディスクサブシステムに関連するボトルネックを特定するのに役立ちます。

単純なコマンドを使用して、 iostat ユーティリティを実行できます。基本的な構文を次に示します。

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

パラメーターによって、 iostat が提供する情報が決まります。コマンドパラメーターを指定しない場合、 iostat は基本的な詳細を表示します。

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 を実行します。

iostat -dxctm 1

iostat結果をさらに拡張するには、次のパラメーターを使用します。

パラメーター	アクション
`-d`	デバイス使用率レポートを表示します。
`-x`	拡張統計を表示します。このパラメーターは、IOPS、待機時間、キューサイズを提供するため、重要です。
`-c`	CPU 使用率レポートを表示します。
`-t`	表示される各レポートの時刻を印刷します。このパラメーターは、長時間実行する場合に便利です。
`-m`	人間が判読できる形式で、1 秒あたりの統計をメガバイト単位で表示します。

コマンド内の数字 1 は、1 秒ごとに更新するように iostat に指示します。更新を停止するには、 Ctrl+C を選択します。

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

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からデータを常にキャプチャし、ボトルネックの可能性を分析する。待機時間が長い場合は、ディスクが飽和点に達していることを示している可能性があります。

注

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

Important

個々の iostat 値は、単独で問題を示すわけではありません。負荷の下で長い待機時間またはキューの深さが持続することは、ディスクの飽和状態をより強く示します。

ネットワークリソース

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

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

ネットワーク待機時間

インターネット制御メッセージプロトコル (ICMP) の単純な ping コマンドを使用して、2 つの異なるシステム間のネットワーク待ち時間を確認できます。

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 ツールを使用する方法を示しています。

[サーバー]

iperf3 -s

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

Client

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

Important

Azure のネットワークパフォーマンスは、VM サイズによって制限されます。スループットの制限は、多くの場合、ネットワーク自体ではなく、VM またはディスクの制限に起因します。

メモリリソース

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

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 の割合 (%) で並べ替えられます。メモリ使用率 (%) で並べ替えるには、Shift キーと M キーを押して top を実行します。次のテキストは、 top コマンドからの出力を示しています。

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

次のテキストは、コマンドからの出力例を示しています。

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

次の出力例に示すように、メモリプレッシャーを Out of Memory (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 コマンドを使用して、プロセスごとのメモリ統計を表示します。

Important

Linux では、メモリ使用率が高くなります。メモリ不足は、キャッシュの使用量ではなく、使用可能なメモリの不足、スワップアクティビティ、OOMkilled イベントによって示されます。

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

インジケーターを現在の構成と関連付けることで、リソースの制約を特定できます。

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

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

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

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

制限リソースを定義する

現在の構成でリソースのボトルネックを特定したら、考えられる変更を評価し、ワークロードへの影響を評価します。場合によっては、コスト最適化の選択肢としてボトルネックが存在し、アプリケーションは許容されるパフォーマンス制限内で動作し続けます。

たとえば、アプリケーションで 128 GB (測定) の RAM (リソース) が必要で、現在の構成で 64 GB (リソース) のみが提供されている場合、メモリはワークロードのボトルネックになります。

ボトルネックリソースを特定したら、制約を定義し、適切なアクションを実行します。この方法はすべてのリソースに適用されます。

一部のボトルネックはコスト削減の構成に起因し、アプリケーションで許容できる場合は許容されます。アプリケーションがリソースの削減を許容できない場合、構成が問題になります。

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

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

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

前の手順からデータを収集した後、実際の測定可能なデータに基づいてシステムを調整します。これらの変更を以前に確立されたベースラインと比較して、測定可能な改善を確認します。

次の例を確認してください。

ベースラインでは、2 つの CPU システムで 100% の CPU 使用率が示され、負荷平均は 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% の低下を表します。

Disk

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

待機時間は、ディスクサイズではなくディスクの種類によって異なります。ほとんどのオンプレミスストレージソリューションでは、DRAM キャッシュと共にディスクアレイが使用されます。この種類のキャッシュでは、ミリ秒未満の待機時間 (約 200 マイクロ秒) と高い読み取り/書き込みスループット (IOPS) が提供されます。

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

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

注

ディスクは、IOPS または帯域幅の制限に達した場合、スロットリングされます。そうしないと、待機時間が 100 ミリ秒以上に急増する可能性があります。

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

ネットワーク

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

[メモリ]

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

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

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

PerfInsights を実行する

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

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

Azure portal を使用して PerfInsights をインストールすると、ソフトウェアによって VM に拡張機能がインストールされます。また、拡張機能として 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 影響のいずれかに分類されます。

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

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

詳細

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-30

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

まとめ

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

ボトルネックの可能性を特定する

パフォーマンスの分析情報を収集する

CPU リソース

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

IOPS

スループット

レイテンシ

iostat の出力について

値を理解する

ネットワーク リソース

ネットワーク待機時間

ネットワーク帯域幅

メモリ リソース

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

制限リソースを定義する

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

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

CPU

Disk

ネットワーク

[メモリ]

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

PerfInsights を実行する

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

Azure portal オプション 1

Azure portal オプション 2

PerfInsights レポートで注目すべき内容

Azure portal を使用して実行する

詳細

フィードバック

その他のリソース

ネットワークリソース

メモリリソース