Linux または Windows での Azure 仮想マシンのパフォーマンスのトラブルシューティング

この記事では、ボトルネックの監視と監視による仮想マシン (VM) の一般的なパフォーマンスのトラブルシューティングについて説明し、発生する可能性のある問題に対して可能な修復を提供します。 監視に加えて、Perfinsights を使用することもできます。これは、IO/CPU/メモリに関するベスト プラクティスの推奨事項と主要なボトルネックを含むレポートを提供できます。 Perfinsights は、Azure の Windows VM と Linux VM の両方で使用できます。

この記事では、監視を使用してパフォーマンスのボトルネックを診断する方法について説明します。

監視の有効化

Azure IAAS 仮想マシンの監視

ゲスト VM を監視するには、Azure VM 監視を使用します。これにより、特定の高レベルのリソース条件がアラートされます。 VM 診断が有効になっているかどうかをチェックするには、「Azure リソース ログの概要」を参照してください。 次のような場合は、診断が有効になっていない可能性が最も高くなります。

microsoft Azure portal を使用して VM 診断を有効にする

VM 診断を有効にするには:

1. VM に移動します。

2. [ 診断設定] をクリックします。

3. ストレージ アカウントを選択し、[ ゲスト レベルの監視を有効にする] をクリックします。

   

診断設定に使用するストレージ アカウントは、[診断設定] の [エージェント] タブからチェックできます。

Azure portalを使用してストレージ アカウントの診断を有効にする

Azure の仮想マシンの IO パフォーマンスを分析する予定の場合、ストレージは非常に重要なレベルです。 ストレージ関連のメトリックについては、追加の手順として診断を有効にする必要があります。 これは、ストレージ関連のカウンターのみを分析する場合にも有効にすることができます。

1. VM を選択して、VM が使用しているストレージ アカウント (またはアカウント) を特定します。 [ 設定] をクリックし、[ ディスク] をクリックします。

   

2. ポータルで、VM のストレージ アカウント (またはアカウント) に移動し、次の手順に従います。

   1. 上記の手順で見つけたストレージ アカウントの [概要] をクリックします。
   2. 既定のメトリックが表示されます。

   

3. いずれかのメトリックをクリックすると、メトリックを構成および追加するためのオプションが追加された別のブレードが表示されます。

   

これらのオプションを構成するには:

1. [ メトリック] を選択します。
2. [リソース (ストレージ アカウント)] を選択します。
3. 名前空間を選択する
4. [ メトリック] を選択します。
5. 集計の種類を選択 する
6. このビューはダッシュボードにピン留めできます。

ボトルネックの監視

必要なメトリックの初期セットアップ プロセスを完了し、VM と関連するストレージ アカウントの診断を有効にした後、分析フェーズに移行できます。

監視へのアクセス

調査する Azure VM を選択し、[監視] を選択 します。

観察のタイムライン

リソースのボトルネックがあるかどうかを特定するには、データを確認します。 マシンが正常に実行されているのに、パフォーマンスが最近低下したことが報告されている場合は、報告された変更前、変更中、および問題後のパフォーマンス メトリック データを含むデータの時間範囲を確認してください。

CPU ボトルネックを確認する

1. グラフを編集します。
2. 時間範囲を設定します。
3. 次に、カウンターに CPU 使用率ゲスト OS を追加する必要があります
4. 保存します。

CPU で傾向を観察する

パフォーマンスの問題を確認するときは、傾向に注意し、影響を受けるかどうかを理解してください。 次のセクションでは、ポータルの監視グラフを使用して傾向を表示します。 また、同じ期間に異なるリソースの動作を相互参照する場合にも役立ちます。 グラフをカスタマイズするには、[ Azure Monitor データ プラットフォーム] をクリックします。

Spiking – Spiking は、スケジュールされたタスク/既知のイベントに関連している可能性があります。 タスクを特定できる場合は、タスクが必要なパフォーマンス レベルで実行されているかどうかを判断します。 パフォーマンスが許容される場合は、リソースを増やす必要がない場合があります。

スパイクアップと定数 – 多くの場合、新しいワークロードを示します。 認識されたワークロードでない場合は、VM で監視を有効にして、動作の原因となるプロセス (またはプロセス) を確認します。 プロセスが認識されたら、消費の増加が非効率的なコードによって引き起こされているか、通常の消費によって引き起こされているかを判断します。 通常の消費の場合は、プロセスが必要なパフォーマンス レベルで動作するかどうかを決定します。

定数 – VM が常にこのレベルで実行されているか、または、診断が有効になってからそのレベルでのみ実行されているかどうかを判断します。 その場合は、問題の原因となっているプロセス (またはプロセス) を特定し、そのリソースをさらに追加することを検討してください。

着実に増加 – 消費の継続的な増加は、多くの場合、非効率的なコードまたはより多くのユーザー ワークロードを引き受けるプロセスのいずれかです。

CPU 使用率の高い修復

アプリケーションまたはプロセスが正しいパフォーマンス レベルで実行されておらず、95% + CPU 使用率の定数が表示されている場合は、次のいずれかのタスクを実行できます。

• 直ちに解放する - VM のサイズをコア数の多いサイズに増やす
• 問題を理解する – アプリケーション/プロセスを特定し、それに応じてトラブルシューティングを行います。

VM を増やし、CPU がまだ 95% 実行されている場合は、この設定によってパフォーマンスが向上しているか、アプリケーションのスループットが許容レベルまで向上しているかを判断します。 そうでない場合は、その個々のアプリケーション\プロセスのトラブルシューティングを行います。

Windows または Linux 用の Perfinsights を使用して、CPU 消費を促進しているプロセスを分析できます。

メモリのボトルネックを確認する

メトリックを表示するには:

1. セクションを追加します。
2. タイルを追加します。
3. ギャラリーを開きます。
4. [メモリ使用量] を選択し、ドラッグします。 タイルがドッキングされたら、右クリックして [6x4] を選択します。

メモリの傾向を観察する

[メモリ使用量] には、VM で消費されているメモリの量が表示されます。 傾向と、問題が発生した時刻にマップされるかどうかを理解します。 使用可能なメモリは常に 100 MB を超える必要があります。

スパイクと定数/一定の安定した消費 - リレーショナル データベース エンジンなどの一部のアプリケーションでは大量のメモリが割り当てられるので、メモリ使用率が高い場合はパフォーマンスが低下する原因にならない可能性があります。この使用率は重要でない可能性があります。 ただし、メモリ不足のアプリケーションが複数ある場合は、メモリの競合によってトリミングやディスクへのページング/スワップが発生し、パフォーマンスが低下する可能性があります。 このパフォーマンス低下は、多くの場合、アプリケーションのパフォーマンスへの影響の顕著な原因です。

消費の着実な増加 – アプリケーションの "ウォームアップ" が可能な場合、この消費量は、起動するデータベース エンジンの間で一般的です。 ただし、アプリケーションのメモリ リークの兆候である可能性もあります。 アプリケーションを特定し、動作が予期されるかどうかを理解します。

ページまたはスワップ ファイルの使用状況 – Windows ページング ファイル (D:上にある) または Linux Swap ファイル ( /dev/sdb上にある) を使用しているかどうかを確認します。 これらのファイル以外にこれらのボリュームに何も存在しない場合は、それらのディスクの高い読み取り/書き込みをチェックします。 この問題は、メモリの不足状態を示しています。

メモリ使用率の高い修復

高いメモリ使用率を解決するには、次のいずれかのタスクを実行します。

• 即時リリーフまたはページまたはスワップ ファイルの使用状況の場合 - VM のサイズをメモリを増やして 1 つに増やし、監視します。
• 問題を理解する – アプリケーション/プロセスを特定し、高消費メモリ アプリケーションを特定するためのトラブルシューティングを行います。
• アプリケーションがわかっている場合は、メモリ割り当てを上限にできるかどうかを確認します。

より大きな VM にアップグレードした後も、100% まで継続的に増加している場合は、アプリケーション/プロセスを特定し、トラブルシューティングを行います。

Windows または Linux 用の Perfinsights を使用して、メモリ消費を促進しているプロセスを分析できます。

ディスクのボトルネックを確認する

VM のストレージ サブシステムをチェックするには、VM 診断のカウンターとストレージ アカウント診断を使用して、Azure VM レベルで診断をチェックします。

VM 固有のトラブルシューティングでは、 Windows または Linux 用の Perfinsights を使用できます。これは、IO を駆動しているプロセスを分析するのに役立ちます。

ゾーン冗長アカウントとPremium Storage アカウントのカウンターはありません。 これらのカウンターに関連する問題については、サポート ケースを発生させます。

監視でのストレージ アカウントの診断の表示

次の項目を操作するには、ポータルで VM のストレージ アカウントに移動します。

1. 監視グラフを編集します。
2. 時間範囲を設定します。
3. 次の手順で説明するカウンターを追加します。
4. 変更を保存します。

ディスクの傾向を確認する (標準ストレージのみ)

ストレージに関する問題を特定するには、ストレージ アカウント診断と VM 診断のパフォーマンス メトリックを確認します。

以下のチェックごとに、問題の時間範囲内で問題が発生した場合の主な傾向を調べます。

Azure ストレージの可用性を確認する – ストレージ アカウント メトリックを追加する: 可用性

可用性が低下する場合は、プラットフォームに問題がある可能性があります。Azure 状態チェック。 そこに問題が表示されない場合は、新しいサポート 要求を発生させます。

Azure ストレージ のタイムアウトを確認する - ストレージ アカウントメトリックを追加する

• ClientTimeOutError
• ServerTimeOutError
• AverageE2ELatency
• AverageServerLatency
• TotalRequests

*TimeOutError メトリックの値は、IO 操作に時間がかかりすぎてタイムアウトしたことを示します。次の手順を実行すると、潜在的な原因を特定するのに役立ちます。

AverageServerLatency が TimeOutErrors で同時に増加すると、プラットフォームの問題になる可能性があります。 この状況で新しいサポート 要求を発生させます。

AverageE2ELatency は、クライアントの待機時間を表します。 アプリケーションによって IOPS がどのように実行されているかを確認します。 TotalRequests メトリックの増加または常に高い値を探します。 このメトリックは IOPS を表します。 ストレージ アカウントまたは単一 VHD の制限に達し始めている場合、待機時間は調整に関連している可能性があります。

Azure ストレージの調整を確認する - ストレージ アカウントメトリックを追加する: ThrottlingError

調整の値は、ストレージ アカウント レベルで調整されていることを示します。つまり、アカウントの IOPS 制限に達していることを意味します。 メトリック TotalRequests を確認することで、IOP のしきい値に達しているかどうかを判断できます。

各 VHD の制限は 500 IOPS または 60 MBits ですが、ストレージ アカウントあたり 20000 IOPS の累積制限によって制限されることに注意してください。

このメトリックでは、調整の原因となっている BLOB と、その影響を受ける BLOB を確認できません。 ただし、ストレージ アカウントの IOPS またはイングレス/エグレスの制限に達しています。

IOPS の制限に達しているかどうかを確認するには、ストレージ アカウント 診断に移動し、TotalRequests をチェックして、20,000 件の TotalRequests に近づいているかどうかを確認します。 パターンの変更、初めて制限が表示されるかどうか、またはこの制限が一定の時間に発生するかどうかを特定します。

Standard Storage の新しいディスク オファリングでは、IOPS とスループットの制限が異なる場合がありますが、Standard Storage アカウントの累積制限は 20000 IOPS です (Premium Storage にはアカウントレベルまたはディスク レベルで異なる制限があります)。 さまざまな Standard Storage ディスク オファリングとディスクごとの制限の詳細を確認してください。

• Windows 上の VM ディスクのスケーラビリティとパフォーマンスのターゲット。

関連情報

• Premium ページ BLOB ストレージ アカウントのスケーラビリティとパフォーマンスのターゲット

ストレージ アカウントの帯域幅は、ストレージ アカウント メトリック TotalIngress と TotalEgress によって測定されます。 冗長性とリージョンの種類に応じて、帯域幅のしきい値が異なります。

• 標準ストレージ アカウントのスケーラビリティとパフォーマンスの目標

ストレージ アカウントの冗長性の種類とリージョンのイングレスとエグレスの制限に対して TotalIngress と TotalEgress を確認します。

VM に接続されている VHD のスループット制限を確認します。 VM メトリック ディスクの読み取りと書き込みを追加します。

Standard Storage の新しいディスク オファリングでは、IOPS とスループットの制限が異なります (VHD ごとに IOPS は公開されません)。 データを確認して、ディスクの読み取りと書き込みを使用して、VM レベルで VHD の合計スループット MB の制限に達しているかどうかを確認し、VM ストレージ構成を最適化して 1 つの VHD 制限を超えてスケーリングします。 さまざまな Standard Storage ディスク オファリングとディスクごとの制限の詳細を確認してください。

• Windows 上の VM ディスクのスケーラビリティとパフォーマンスのターゲット。

ディスク使用率/待機時間の高い修復

クライアント待機時間を短縮し、VM IO を最適化して過去の VHD 制限をスケーリングする

• Azure での Windows 用 IO の最適化

• Azure での Linux 用 IO の最適化

調整を減らす

ストレージ アカウントの上限に達した場合は、ストレージ アカウント間で VHD のバランスを再調整します。 「Azure Storage のスケーラビリティとパフォーマンスのターゲット」を参照してください。

スループットを向上させ、待機時間を短縮する

待機時間に依存するアプリケーションがあり、高スループットが必要な場合は、DS および GS シリーズ VM を使用して VHD を Azure Premium ストレージに移行します。

これらの記事では、特定のシナリオについて説明します。

• Azure Premium Storage への移行

• SQL Serverで Azure Premium Storageを使用する

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

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