次の方法で共有

Azure Windows 仮想マシンでのメモリの高い問題のトラブルシューティング

  • [アーティクル]

適用対象: ✔️ Windows VM

パフォーマンスの問題はさまざまなオペレーティング システムまたはアプリケーションで発生し、いずれの問題にも固有のトラブルシューティング アプローチが必要です。 CPU、メモリ、ネットワーク、入出力 (I/O) は、多くの場合、パフォーマンスの問題が発生する際の重要な要因です。 領域ごとに異なる症状が発生し (同時に発生する場合もあります)、異なる診断アプローチと解決策が必要です。

この記事では、Windows オペレーティング システム (OS) を実行する Azure 仮想マシン (VM) で発生するメモリ使用量の高い問題 (メモリ不足とも呼ばれます) について説明します。 Linux ディストリビューションを実行している Azure VM のトラブルシューティング ガイダンスについては、「 Linux でのパフォーマンスのトラブルシューティングとボトルネックの分離」を参照。

Azure Windows VM でのメモリ不足の問題

I/O とネットワーク待機時間の問題とは別に、CPU やメモリのトラブルシューティングには、ほとんどの場合、オンプレミス サーバーと同じツールと手順が必要です。 Azure VM で推奨されるツールの 1 つは、PerfInsights (Windows と Linux の両方で使用できます) です。 PerfInsights を使用すると、わかりやすいレポートで Azure VM のベスト プラクティス診断を確認できます。 PerfInsights はラッパー ツールでもあり、ツール内で選択されたフラグに応じて、Perfmon、Xperf、および Netmon データを収集するために役立ちます。 Azure VM で PerfInsights を実行するために、Microsoft サポートに連絡する必要はありません。 PerfInsights は一般公開されています。 ローカルまたは指定したストレージ アカウントでレポートが生成されます。

Perfmon や Procmon などのオンプレミス サーバーに使用されるパフォーマンストラブルシューティング ツールのほとんどは、Azure Windows VM で動作します。 ただし、PerfInsights は、Azure のベスト プラクティス、SQL のベスト プラクティス、高解像度の IO 待機時間グラフ、メモリとメモリのタブなど、より多くの分析情報を提供するように Azure VM 向けに明示的に設計されています。 この記事では、メモリのトラブルシューティングに関連PerfInsights の一部について説明します。

メモリ不足とは

実行中のプロセスからの要求に基づいて、システムが物理メモリ (ランダム アクセス メモリ (RAM)) または仮想メモリ (ページング ファイルによってサポート) でクランチされると、OS はスワップ ファイルを使用して RAM 内のアクティブページを調整し続けます。 このケースは、メモリ不足があり、OS が要求の厳しいアプリの作業領域を取得するために一生懸命働いていることを示しています。 メモリ リークはもう 1 つのバリエーションです。 これは主に、OS がより多くの割り当てを求め続け、最終的に仮想メモリの枯渇につながるコーディングの不具合の結果です。

多くの問題は、ワークロードに直接関係しています。 マシンに存在するワークロードの種類によって、メモリを含むリソースの消費が促進されます。

一般的な要因

メモリ不足の状況における一般的な要因を次に示します。 これらの要因のいずれかが存在する場合は、この問題の根本に近くなります。

  • インターネット インフォメーション サービス (IIS)、Microsoft SharePoint、SQL Server、サード パーティ製アプリケーションなどのアプリに主に適用される最近のコード変更または展開。

  • OS レベルの更新プログラムまたはアプリケーション レベルの累積的な更新プログラムと修正プログラムに関連する可能性がある最新の更新プログラム。

  • クエリの変更または古いインデックス。 SQL Server および Oracle データ層アプリケーションには、クエリ プランの最適化ももう 1 つの要因として含まれています。 データの変更や適切なインデックスの不足により、複数のクエリで最適なデータ ページよりも多くのデータ ページがメモリに格納され、スワップ領域にストレスが発生する可能性があります。

  • Azure VM 固有 - RDAgent などの特定のプロセスと、監視エージェント、MMA エージェント、セキュリティ クライアントなどの拡張機能固有のプロセスでは、メモリ消費量が多くなる可能性があります。 これらのプロセスは、構成、既知の問題の観点、または場合によっては回帰ビルドから表示する必要があります。

メモリ負荷に関する問題のトラブルシューティング

問題のトラブルシューティングの目的は、犯人のプロセスを可能な限りゼロにすることです。 さらなる分析は、メモリ消費量が多いプロセスに固有です。

たとえば、プロセスが SQL Server (sqlservr.exe) の場合、次の手順では、 MaxServerMemory などの設定を分析し 特定の期間に最も多くのメモリ サイクルを使用しているクエリを分析します。 Azure での SQL Server のベスト プラクティスの詳細については、「 VM サイズ: Azure VM 上の SQL Server のパフォーマンスのベスト プラクティス」を参照してください。

スコープ メモリ不足の問題

問題をトラブルシューティングする際には、次の質問事項を確認してください。

  • この問題のパターンはありますか? たとえば、メモリ不足の問題は、毎日、週、または月の特定の時間に発生しますか? その場合、ジョブ、プロセス、レポート、またはユーザーログインに関連付けることができますか?

  • アプリ層 - 最近のコード変更後にメモリ不足の問題が発生しましたか? Windows で更新プログラムを適用したか、新しいアプリケーション ビルドをデプロイしましたか? ユーザー ベースが急激に急増したか、負荷分散が混乱し、別の負荷パターンが発生しましたか?

  • データ層 - ユーザー数の増加、データの流入の増加、プルされるレポートの数の増加など、ワークロードの変更後にメモリ不足の問題が発生しましたか? このワークロードは最近 Azure に移行されましたか? それは今まで正常に動作しましたか?

  • Azure の場合、メモリ不足の問題は次のいずれかの条件で開始されましたか?

    • 最近の再デプロイまたは再起動後
    • VM の種類または層が変更されたのはいつですか?
    • VM に新しい拡張機能が追加された後
    • ロード バランサーの変更が行われた後
    • VMSS のセットアップに対してスケール イン/スケールアウトがあり、その結果、不変の負荷が発生しましたか?

Azure に関する注意事項

  • 最も重要なのは、ワークロードを理解することです。 VM SKU (オファリング/タイプ) を選択すると、毎月のホスティング コスト全体を調べる傾向があるため、メモリ スペックを過小評価する可能性があります。 ワークロードがメモリを集中的に消費する場合は、小さい VM SKU を選択すると、メモリの問題が少なくなる可能性があります。 ワークロードのさまざまな構成をテストして、必要な最適なコンピューティング機能を決定します。

  • Azure Virtual Desktop (AVD) などのマルチユーザーセットアップを計画していますか? メモリを含むリソースは、セッションがアクティブな間のリソース共有に基づいて考慮する必要があります。

  • アプリは、動作コンテキストをメモリに取り込むよう設計されていますか? たとえば、メモリ内で動作するように MongoDB を構成できます。つまり、メモリとスワップスペースが頻繁に使用されます。 そのため、選択した VM の種類 (オファリング) がこの要件を満たしている必要があります。

SQL Server、Oracle、RDS (リモート デスクトップ サービス)、Azure Virtual Desktop、 IIS、SharePoint などの他の既知のアプリケーション/構成には、これらのワークロードに最適な最小限の構成に関する推奨事項を含む Azure のベスト プラクティスに関する記事があります。

メモリ不足に関する継続的な問題

問題が現在発生している場合、これはプロセス トレースをキャプチャして問題の原因を特定するために最適な機会です。 このプロセスを見つけるには、オンプレミスの Windows サーバーで使用していた既存のツール ( Procmon、Perfmon、 RAMMAP、 xPerf Windows Toolkit ResourceExplorer など) を使用できます。

Azure VM の Azure サポートでは、次のツールをお勧めします。

PerfInsights

PerfInsights は、VM のパフォーマンスの問題に関して Azure サポートから推奨されているツールです。 ベスト プラクティスについて説明し、メモリ、CPU、および高解像度の I/O グラフ用の専用の分析タブを備えています。 OnDemand は、Azure portal または VM 内で実行できます。 これは Azure portal と深く統合されており、一般的な Windows ゲスト層アプリケーションのベスト プラクティスに関する推奨事項についても説明します。

Azure サポート チームとアクティブなチケットがある場合は、PerfInsights データを共有したり、必要に応じて個別に使用したりできます。

PerfInsights を取得する

PerfInsights は、Windows と Linux OS の両方に用意されています。

Windows のオプションをいくつか次に示します。

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

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

Azure portal - オプション 1

パフォーマンス診断 オプションを選択します。 選択した VM にオプション (拡張機能を使用) をインストールするように求められます。 例については、次のスクリーンショットを参照してください。

[パフォーマンス診断のインストール] オプションのスクリーンショット。

パフォーマンス診断のインストールを選択します。 実行診断 パネルが表示されます。 [診断の実行] パネルで、実行する分析の種類選択できます。 メモリ分析の推奨される選択肢は、 パフォーマンス分析 と パフォーマンス分析です。

4 種類の分析のスクリーンショット。

選択内容に基づいて、その他のオプションが表示されます。 例については、次のスクリーンショットを参照してください。

その他の診断オプションを示すスクリーンショット。

スクリーンショットの番号付きオプションは、次のコメントに関連しています。

  1. 診断を実行 を選択します。

  2. Analysis オプションで、パフォーマンス分析またはAdvanced パフォーマンス分析を選択します。 基本的なコレクションでは、VM の構成とベスト プラクティスに関する推奨事項が主に収集されます。 ただし、トラブルシューティングの目的でさらに詳細なデータが必要になります。これは、パフォーマンス分析またはAdvanced パフォーマンス分析コレクション フラグのみがキャプチャできます。

  3. データ収集のトレース期間を選択します。 メモリのトラブルシューティングの場合は、15 分以上を選択します。 Azure portal モードでは、最大 15 分のデータを収集できます。 収集期間が長い場合は、VM 内から実行可能ファイルとしてプログラムを実行する必要があります。

  4. Azure サポートからこのデータの収集を求められた場合は、 Support 要求番号 フィールドにチケット番号を追加できます。 このフィールドは省略可能です。

  5. Microsoft Corp. からこのソフトウェアを入手していること、および法律条項とプライバシー ポリシーを読んで同意したことを確認しますエンドユーザー使用許諾契約書 (EULA) に同意します。 このケースをサポートする Azure サポート チームがこのレポートを利用できるようにする場合は、 Microsoft と診断情報を共有することに同意します チェック ボックスをオンにします。

パフォーマンス診断レポートは、サブスクリプションのストレージ アカウントのいずれかに格納されます。 後で表示してダウンロードすることができます。 診断を送信すると、この同じ パフォーマンス診断 ビューには、過去のレポート コレクションと、 High/Medium/Low カテゴリの結果の概要も表示されます。 例については、次のスクリーンショットを参照してください。

パフォーマンス診断レポートのスクリーンショット。

任意のレポートを選択して、次のレベルの詳細を表示できます。 レポートのダウンロードを選択して、詳細な分析のためにレポートダウンロードすることもできます。 例については、次のスクリーンショットを参照してください。

パフォーマンス診断レポートの詳細を示すスクリーンショット。

Azure portal - オプション 2

VM ブレードで Diagnose と問題の解決 を選択し、右側のパネルで VM パフォーマンスの問題 を探します。 例については、次のスクリーンショットを参照してください。

[問題の診断と解決] パネルのスクリーンショット。

[トラブルシューティング] を選択すると、PerfInsights のインストール ページが読み込まれます。 このページには、内部チェックが実行され、過去 24 時間のこの VM のメモリ不足のインスタンスが表示される自動診断も表示されます。 実行パフォーマンス診断 Azure portal の PerfInsights ビューに切り替えるリンクも、このページのトラブルシューティング手順に表示されます。

[VM パフォーマンスの問題] パネルのスクリーンショット。

VM から PerfInsights を実行する

この方法は、PerfInsights を長期間実行する場合に使用できます。 PerfInsights の記事では、PerfInsights を実行可能ファイルとして実行するために必要なさまざまなコマンドとフラグについて詳しく説明します。 高いメモリ使用量を分析するには、次のいずれかのモードとコマンドを使用します。

  • 高度なシナリオ

    PerfInsights /run advanced xp /d 900 /AcceptDisclaimerAndShareDiagnostics

  • VM の低速 (パフォーマンス) シナリオ

    PerfInsights /run vmslow /d 900 /AcceptDisclaimerAndShareDiagnostics

コマンドは 15 分間実行されます。 コマンドの出力は、PerfInsights 実行可能ファイルを保存するのと同じフォルダーにあります。 その他のコマンド オプションについては、PerfInsights の実行操作方法に関するを参照してください。

レポートの要注目点

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

収集されたデータにアクセスする

フォルダー構造は次のようになります。

ログ フォルダーの構造を示すスクリーンショット。

  1. Perfmon、Xperf、Netmon、SMB ログ、イベント ログなどの追加コレクションは、 output フォルダーにあります。

    GeneralCounters_000001.blg ファイルと System.evtx ファイルを示すスクリーンショット。

  2. 実際のレポートと分析と推奨事項は、 Perfinsights Report.htmlです。

  3. パフォーマンス (VMlow) と高度なシナリオの両方で、PerfInsights の実行中にパフォーマンス情報が収集されます。

  4. イベント ログでは、役に立つシステムレベルまたはプロセスのクラッシュの詳細をすばやく確認できます。

開始する場所

PerfInsights レポートを開きます。 [検出結果] タブには、リソース消費の観点から外れ値がログに記録されます。 メモリ使用量が多い、またはその他のリソース制約のインスタンスがある場合、 Findings タブでは、 High 影響または Medium 影響のいずれかとして分類されます。

[結果] タブに記録されたリソース消費量を示すスクリーンショット。

[検出結果] イベントを展開すると、いくつかの重要な詳細が表示されます。 タブには、平均メモリ消費量ごとに降順にプロセスが一覧表示されます。 プロセスがシステムまたはアプリ (SQL Server、IIS、またはサード パーティ製アプリ) に関連付けられているかどうかを示します。

[結果] タブに記録されたキーの詳細を示すスクリーンショット。

[詳細]

Memory の下には、専用のサブタブ Top Memory Consumers があります。 このタブは、詳細なパターン分析に使用でき、データ キャプチャ期間中のプロセスの詳細を表示します。

Top メモリ コンシューマー タブには、High Memory Usage Periods と Top Memory Consumers の 2 つのセクションがあります。

メモリ使用率の高い期間を示すスクリーンショット。

  • メモリ使用量の長い期間: このセクションでは、メモリ消費量が多い場合のタイム バーを示します。 また、全体的なコミット済みメモリ %も表示されます。これは、メモリ不足の主要なインジケーターの 1 つです。 AvailablePhysicalMemory%は、システムがメモリ上で実行されているシンの程度、または使用可能なままであることを示します。

  • 上位メモリ コンシューマー: このセクションは、データ キャプチャ間隔中の高メモリ コンシューマーに関するプロセス レベルの詳細を示しているため、同様に重要です。 これは、プロセスの詳細とそのメモリ使用量パターンの両方を示しています。 この一覧は、メモリコンシューマーの平均が高い順に並べ替えられます。 EndTime - StartTime (EndTime - StartTime) を書き留めます。これは、全体的なデータ収集期間中に高いメモリを消費するプロセスの実際の期間です。

    高メモリ コンシューマーを示すスクリーンショット。

これらの 2 つのタブは、次のトラブルシューティング手順のパスを設定するために必要なすべてです。 メモリの状態が高くなるプロセスによっては、前に質問された質問に対処する必要があります。 SQL (sqlservr)や IIS (w3wp) などのプロセスでは、この条件の原因となっているクエリまたはコードの変更に関する特定のドリルダウンが必要です。

WmiPrvSE SvcHost などのシステム プロセスの場合は、別のパスに従う必要があります。 これらのプロセスの前提条件は、最新の OS 累積的なパッチを適用する必要があるということです。

RDAgent、Operations Management Suite (OMS)、セキュリティ拡張機能の実行可能ファイルなどの Azure VM 関連のプロセスでは、これらのプロセスが最新バージョンであることを確認する必要があります。 プロセスが最新のビルドにアップグレードされた後も問題が解決しない場合は、Azure サポート チームに問い合わせてください。

システム イベント ログでは、イベント ID 2004 を警告としてログに記録することもできます。 また、消費量に基づく上位 3 つのプロセスも表示されます。

イベント 2004 の警告の詳細を示すスクリーンショット。

Perfmon

Perfmon は、Windows OS 上のリソースの問題をトラブルシューティングするための最も古いツールの 1 つです。 推奨事項や結果を含む明確なレポートは提供されません。 代わりに、収集されたデータを探索し、さまざまなカウンター カテゴリで特定のフィルターを使用する必要があります。

PerfInsights は、VMSlow および高度なシナリオの追加ログとして Perfmon を収集します。 ただし、Perfmon は個別に収集でき、次の追加の利点があります。

  • リモートで収集できます。
  • タスクを使用してスケジュールできます。
  • ロールオーバー機能を使用して、長期間または連続モードで収集できます。

PerfInsights に示されているのと同じ例を考えて、Perfmon がこのデータを表示する方法を確認します。 メモリ正常性のクイック インジケーターは、 Available MBytes カウンターを介して行われます。これは、必要なシステムまたはプロセスへの割り当てに使用できる物理メモリを示します。 OS は競合を検出すると、WorkingSet を切り取るためにプロセスにフラグを設定し始めますが、一般的なボールパーク番号は、 Available Mbytes の赤いフラグとして 200 Mb (> 200 Mb) を超えることになります。

Perfmon は Windows (サーバーまたはクライアント) で既定で使用でき、UI またはコマンド ライン ツールを使用して呼び出すことができます。 Windows で Perfmon を読み込むには、 Start>Run を選択し、「 Perfmon」と入力して、 OK を選択します。 Perfmon に対して行われるデータ収集には、 *.blg 拡張子が付きます。

カウンターは、さまざまなリソース カテゴリに追加できます。 メモリのトラブルシューティングを行うには、 Memory>Available MBytes を選択します。 例については、次のスクリーンショットを参照してください。

使用可能なカウンターを示し、[Available MBytes]\(使用可能な MB\) を選択するスクリーンショット。

このカウンターを追加すると、 AvailableMBytes データ キャプチャ間隔中または実行時のパターンが表示されます。 PerfInsights output フォルダーから Perfmon (*.blg) ファイルを開きMemory>Available MBytes の下にカウンターを追加します。 マシンで使用可能なメモリ内の dip がどのように表示されるかを確認します。 例については、次のスクリーンショットを参照してください。

データ キャプチャ間隔中の AvailableMBytes のパターンを示すスクリーンショット。

しかし、質問(どのアプリがメモリを過剰に消費しているか)は残っています。 PerfInsights、リソース モニター、ログのパフォーマンス分析 (PAL) などのツールは、わかりやすい UI またはレポートを使用してこれらのアプリを特定するのに役立ちます。

手動のデータ分析を使用して行う必要があるため、プロセスをゼロにするのは少し面倒です。

Perfmon には、プロセス カウンター カテゴリがあります。 このカテゴリには、ワーキング セット、プライベート バイト、仮想バイトなどのカウンターがいくつかあります。 これらは、データ収集期間中に実行される各プロセスのメモリ使用量パターンを示します。

メモリの継続的な需要を示す段階的または急激な上昇を持つプロセスでは、パターンを観察する必要があります。 _Total/PrivateBytes カウンターに近いパターン マッチングに基づいてプロセスをゼロダウンする方法を次に示します。

PrivateBytes カウンターのパターンを示すスクリーンショット。

Perfmon 分析を簡略化する

Perfmon で使用できる既定のユーザー対応レポートはありません。 グラフの種類は異なりますが、プロセスのフィルター処理 (または原因プロセスを特定するために必要な作業) は手動です。 *.blgファイルを使用し、よりわかりやすい出力を提供する便利なツールがいくつかあります。 そのうちの1つはPALツールです。 PAL ツールは、*.blg ファイルを使用して詳細なレポートを生成できます。

使用可能なツールの一覧は、Perfmon 用の PerfInsights だけではありません。 既存のツール (Procmon、 RAMMAP、 xPerf Windows Toolkit ResourceExplorer など) を使用できます。 必要に応じて、多くのサードパーティ製ツールを使用できます。

Azure 監視ツール

運用システムには一貫した監視が必要であるため、Microsoft は事前にアラートを取得し、履歴パターンに使用してアプリ環境のリソース要件をよりよく理解します。 幸いなことに、Azure VM (Windows と Linux の両方) は Azure Monitoring 機能と深く統合されています。この機能により、堅牢な自動メトリック収集と、レポートを作成したり、サードパーティ製ツールを使用してチームのニーズに合ったレポートを作成したりするためのいくつかの手段が提供されます。

重要な運用 VM が特定のリソースしきい値 (メモリなど) に達している場合は、カスタム アラートを作成できます。 この場合は、電子メールまたはテキストを使用してチームにアラートを送信できます。

Azure VM には、メモリ、ネットワーク I/O、I/O バイトなどの基本情報を含む信頼性の高いメトリックがあります。 Azure Monitor などの高度なメトリックの場合は、指定したストレージ アカウントを構成して使用するために、いくつかの選択のみを行う必要があります。

基本 (既定) のカウンター

Azure VM が作成されると、基本的な既定のメトリックが事前に有効になります。 これらのメトリックでは、Azure Monitoring を有効にするために追加の構成は必要ありません (VM に拡張機能がインストールされます)。 これらの基本的なメトリックの機能は、Azure Monitoring が提供する機能ほど網羅的ではありませんが、基本的な VM リソースの正常性を引き続き表示できます。

次のスクリーンショットは、VM のメモリ メトリックの下の Azure portal にパターンがどのように表示されるかを示しています。 このスクリーンショットは、PerfInsights と Perfmon 分析を共有するために以前に使用したのと同じ期間のものです。

メモリ メトリックを示すスクリーンショット。

Azure Monitor を有効にする

Azure Monitor メトリックを有効にすると、ソフトウェアによって VM に拡張機能がインストールされ、詳細なメトリックの収集が開始されます。

Azure Monitoring が Azure 仮想マシン (Windows および Linux) で提供する完全なカスタマイズを調べることができます。

事後対応のトラブルシューティング

問題が既に発生している場合は、最初に高メモリの問題の原因を検出する必要があります。 データ収集モードは問題が既に発生しているほど役に立たないため、事後対応の姿勢は難しい場合があります。 前のセクションで共有したように、Azure Monitor で構成されたメトリックは、構成された保持時間に基づいて履歴データを保持しているため、ここで大きな役割を果たすことができます。

この問題が 1 回だけ発生した場合、どのアプリが原因であるかを特定することは困難な可能性があります。

繰り返しパターンを扱っている場合は、次に問題が発生する可能性が高い期間中にデータを収集する機会があります。 PerfInsights と Perfmon は便利なツールですが、好みのツールも使用できます。

PerfInsights には、スケジュールされた実行機能がまだありません。 ただし、Perfmon は、次のセクションで共有されているように、コマンド ラインを使用して実行およびスケジュールできます。

Logman コマンド

Logman create counter コマンドは、コマンド ラインを使用して Perfmon コレクションを実行するために使用されます。 タスク マネージャーを使用してスケジュールを設定したり、リモートで実行したりできます。

コマンド サンプルを次に示します (リモート コレクション モードを含む)。

Logman create counter LOGNAME -u DOMAIN\USERNAME * -f bincirc -v mmddhhmm -max 300 -c "\\SERVERNAME\LogicalDisk(*)\*" "\\SERVERNAME\Memory\*" "\\SERVERNAME\Network Interface(*)\*" "\\SERVERNAME\Paging File(*)\*" "\\SERVERNAME\PhysicalDisk(*)\*" "\\SERVERNAME\Process(*)\*" "\\SERVERNAME\Redirector\*" "\\SERVERNAME\Server\*" "\\SERVERNAME\System\*" "\\SERVERNAME\Terminal Services\*" "\\SERVERNAME\Processor(*)\*" "\\SERVERNAME\Cache\*" -si 00:01:00

Logman.exeは、同じ VNET 内のピア Azure VM コンピューターから開始できます。

このようなパラメーターの詳細については、「logman create counter」を参照してください。

問題の発生中に Perfmon データが収集された後の、データを分析するためのその他の手順は、前に説明したものと同じです。

まとめ

パフォーマンスの問題の場合は、ワークロードを理解することが問題を解決するための鍵となります。 運用ワークロードに重点を置いて、さまざまな VM SKU と異なるディスク ストレージ オプションのオプションを評価する必要があります ( Azure 仮想マシン セレクターを使用)。 異なる VM 上で解決策をテストするプロセスは、最適な決定を下すために役立ちます。

ユーザー操作とデータ量は異なるため、常にバッファーを VM のメモリ、コンピューティング、ネットワーク、および I/O 機能に保持します。 これにより、ワークロードの突然の変化は、この追加のリソース バッファーによって吸収される可能性があります。

ワークロードが間もなく増加することが予想される場合は、より高い VM オファリングに移行するか、コンピューティング/メモリ/IO 機能を増やします。 ワークロードがメモリを集中的に消費する場合は、メモリと CPU の比率 高い VM SKU を慎重に選択。

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

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