パフォーマンスに関する推奨事項

Azure Advisor のパフォーマンスに関する推奨事項は、ビジネスに不可欠なアプリケーションのスピードと応答性を向上させるために役立ちます。 Advisor のパフォーマンスに関する推奨事項は、Advisor ダッシュボードの [パフォーマンス] タブで取得できます。

1. Azure Portal にサインインします。

2. 任意のページから [Advisor] を検索して選択します。

3. Advisor ダッシュボードで、[パフォーマンス] タブを選びます。

AI + 機械学習

429 このリソースでスロットリングが検出されました

1 日の時間枠で、このリソースに対して 1,000 以上の 429 個のスロットリングエラーが発生していることを確認しました。 自動スケーリングを有効にして、より高い呼び出しボリュームをより適切にハンドルし、429 エラーの数を減らすことを検討してください。

Azure AI サービスの自動スケーリングについて詳しく知る。

Text Analytics モデル バージョンの非推奨

最新かつ最高品質のモデルを利用するために、モデル バージョンを新しいモデル バージョンまたは最新のものにアップグレードします。

詳細については、「Cognitive Service - TAUpgradeToLatestModelVersion (Text Analytics モデルバージョンの非推奨)」を参照してください。

Text Analytics モデル バージョンの非推奨

最新かつ最高品質のモデルを利用するために、モデル バージョンを新しいモデル バージョンまたは最新のものにアップグレードします。

詳細については、「Cognitive Service - TAUpgradeModelVersiontoLatest (Text Analytics モデルバージョンの非推奨)」を参照してください。

最新の Cognitive Service Text Analytics API バージョンにアップグレードしてください

モデルの品質、パフォーマンス、およびサービスの可用性に関して最適な結果を得るために、最新の API バージョンにアップグレードします。 また、V3.0 以降、個人データの認識やエンティティの認識、別のエンドポイントとして利用できるエンティティのリンクなどの新しい機能を使用できます。 プレビュー エンドポイントの変更に関しては、SA エンドポイントでのオピニオン マイニング、個人データ エンドポイントでの編集済みのテキスト プロパティがあります

Cognitive Service - UpgradeToLatestAPI (最新の Cognitive Service Text Analytics API バージョンにアップグレードする) に関する詳細を確認してください。

Azure Cognitive Service for Language の最新 API バージョンにアップグレードする

モデルの品質、パフォーマンス、およびサービスの可用性に関して最適な結果を得るために、最新の API バージョンにアップグレードします。

Cognitive Service - UpgradeToLatestAPILanguage (Azure Cognitive Service for Language の最新 API バージョンにアップグレードする) に関する詳細を確認してください。

最新の Cognitive Service Text Analytics SDK バージョンにアップグレードしてください

モデルの品質、パフォーマンス、およびサービスの可用性に関して最適な結果を得るために、最新の SDK バージョンにアップグレードします。 また、V3.0 以降、個人データの認識やエンティティの認識、別のエンドポイントとして利用できるエンティティのリンクなどの新しい機能を使用できます。 プレビュー エンドポイントの変更に関しては、SA エンドポイントでのオピニオン マイニング、個人データ エンドポイントでの編集済みのテキスト プロパティがあります

Cognitive Service - UpgradeToLatestSDK (最新の Cognitive Service Text Analytics SDK バージョンにアップグレードする) に関する詳細を確認してください。

最新の Cognitive Service Language SDK バージョンにアップグレードする

モデルの品質、パフォーマンス、およびサービスの可用性に関して最適な結果を得るために、最新の SDK バージョンにアップグレードします。

Cognitive Service - UpgradeToLatestSDKLanguage (最新の Cognitive Service Language SDK バージョンにアップグレードする) に関する詳細を確認してください。

最新の Azure AI Language SDK バージョンにアップグレードする

モデルの品質、パフォーマンス、およびサービスの可用性に関して最適な結果を得るために、最新の SDK バージョンにアップグレードします。 また、V3.0 以降、個人データの認識やエンティティの認識、別のエンドポイントとして利用できるエンティティのリンクなどの新しい機能を使用できます。 プレビュー エンドポイントの変更に関しては、SA エンドポイントでのオピニオン マイニング、個人データ エンドポイントでの編集済みのテキスト プロパティがあります。

Azure AI Language について詳しく知る。

分析

パフォーマンスを最適化するために Data Explorer のリソースを適切なサイズにする

この推奨事項では、推奨されるデータ容量 (80%) を超えるすべての Data Explorer リソースを表示します。 パフォーマンスを向上させるための推奨される操作は、示されている推奨される構成にスケーリングすることです。

Data Explorer リソース - 適切なサイズの ADX リソース (最適なパフォーマンスのための適切なサイズの Data Explorer リソース。) に関する詳細を確認してください。

Data Explorer のテーブルのキャッシュ ポリシーを確認する

この推奨事項では、構成されているキャッシュ期間 (ポリシー) より過去のクエリが多い Data Explorer のテーブルが表示されます (キャッシュ範囲外のデータにアクセスするクエリの割合で、上位 10 個のテーブルが示されます)。 パフォーマンスを向上させるために推奨されるアクション: このテーブルに対するクエリを、(定義されたポリシー内で) 必要最小限の時間範囲に制限します。 または、時間範囲全体のデータが必要な場合は、キャッシュ期間を推奨される値に増やします。

Data Explorer リソース - UpdateCachePoliciesForAdxTables (Data Explorer のテーブルのキャッシュ ポリシーを確認する) に関する詳細を確認してください。

Data Explorer のテーブル キャッシュ ポリシーを減らし、パフォーマンスを良くする

テーブル キャッシュ ポリシーを減らすと、リソースのキャッシュから未使用のデータが解放され、パフォーマンスが向上します。

Data Explorer リソース - ReduceCacheForAzureDataExplorerTablesToImprovePerformance (Data Explorer のテーブル キャッシュ ポリシーを減らし、パフォーマンスを良くする) に関する詳細を確認してください。

キャッシュ ポリシーのキャッシュを増やす

前月の実際の使用量に基づいてキャッシュ ポリシーを更新して、テーブルのホット キャッシュを増やします。 保持期間は常にキャッシュ期間よりも長くする必要があります。 キャッシュを増やして保持期間がキャッシュ期間より短くなる場合は、保持ポリシーを更新してください。 分析は、データをスキャンしたユーザー クエリにのみ基づいています。

詳細については、「Data Explorer リソース - IncreaseCacheForAzureDataExplorerTablesToImprovePerformance (キャッシュ ポリシーのキャッシュを増やす)」を参照してください。

Data Explorerリソースに最適化された自動スケーリングを有効化する

リソースは、パフォーマンスを向上させるために自動的にスケーリングされたようです（過去1週間の実際の使用状況、キャッシュ使用率、インジェスト使用率、CPU、およびストリーミング・インジェスト使用率に基づく）。 コストとパフォーマンスを最適化するために、最適化された自動スケーリングの有効化をおすすめします。

詳細については、「Data Explorer リソース - PerformanceEnableOptimizedAutoscaleAzureDataExplorer (Data Explorer のリソースの最適化された自動スケーリングを有効にする)」を参照してください。

最新のデータに対する読み取りが発生します

75% を超える読み取り要求が Memstore で発生しています。読み取りは主に最近のデータに対して行われていることを示しています。 最近のデータの読み取りが示唆しているのは、Memstore でフラッシュが行われたとしても、最近のファイルはアクセスされる必要があり、キャッシュに格納される必要があるということです。

HDInsight クラスター - HBaseMemstoreReadPercentage (最新のデータに対する読み取りが発生する) に関する詳細を確認してください。

クラスターのパフォーマンスを向上させるには、HBase クラスターで高速書き込み機能を使用することを検討してください。

HDInsight チームのシステム ログに、クラスターで過去 7 日間に次のようなシナリオが発生したことが示されているため、このアドバイザーの推奨事項が表示されています。

1. WAL の同期時に長い待機時間が発生

2. 大量の書き込み要求 (1 時間に 1000 を超える avg_write_requests/second/node)

これらの条件は、クラスターで書き込み時に長い待機時間が発生しており、その原因はクラスターの高い負荷である可能性があることを示しています。

クラスターのパフォーマンスを向上させるには、Azure HDInsight HBase の高速書き込み機能の利用を検討してください。 HDInsight の Apache HBase クラスター用高速書き込み機能では、クラウド ストレージを使用する代わりに、Premium SSD マネージド ディスクをすべての RegionServer (ワーカー ノード) にアタッチします。 その結果、書き込み待機時間が短縮され、アプリケーションの回復性が向上します。

この機能の詳細については、次のリンクを参照してください:

HDInsight クラスター - AccWriteCandidate (クラスターのパフォーマンスを向上させるため、HBase クラスターで高速書き込み機能を使用することを検討する) に関する詳細を確認してください。

75% を超えるクエリがフル スキャン クエリです

クラスターに対する 75% を超えるスキャン クエリが、リージョンまたはテーブルのフル スキャンを実行しています。 リージョンまたはテーブルのフル スキャンを回避するようにスキャン クエリを変更してください。

HDInsight クラスター - ScanQueryTuningcandidate (75% を超えるクエリがフル スキャン クエリである) に関する詳細を確認してください。

更新プログラムのブロックが発生しているときは、リージョン数を確認します

更新プログラムがブロックされないようにするには、リージョン数を調整する必要があります。 新しいノードの追加によって、クラスターのスケールアップが必要になる場合があります。

HDInsight クラスター - RegionCountCandidate (更新プログラムのブロックが発生しているときは、リージョン数を確認する) に関する詳細を確認してください。

フラッシャー スレッドを増やすことを検討します

リージョン サーバーのフラッシュ キューのサイズが 100 を超えているか、更新プログラムのブロックが頻発しています。 フラッシュ ハンドラーを調整することをお勧めします。

HDInsight クラスター - FlushQueueCandidate (フラッシャー スレッドを増やすことを検討する) に関する詳細を確認してください。

コンパクションを高速で完了するために、コンパクション スレッドを増やすことを検討します

リージョン サーバーのコンパクション キューが 2,000 を超えており、より多くのデータでコンパクションが必要であることが示唆されています。 低速のコンパクションは、読み取るファイルの数が増えるにつれて、読み取りパフォーマンスに影響を与える可能性があります。 コンパクションが行われていないファイルの増加も、ファイルが Azure ファイル システムと対話する方法に関連するヒープ使用量に影響を与える可能性があります。

HDInsight クラスター - CompactionQueueCandidate (コンパクションを高速で完了するために、コンパクション スレッドを増やすことを検討する) に関する詳細を確認してください。

クラスター化列ストア インデックス (CCI) が設定されている 6,000 万行未満のテーブル

クラスター化列ストア テーブルは、データ内のセグメントにまとめられます。 セグメントの品質を高くすることは、列ストア テーブルで最適なクエリ パフォーマンスを実現するために不可欠です。 セグメントの品質は、圧縮後の行グループに含まれる行数を使って判断できます。

Synapse ワークスペース - SynapseCCIGuidance (クラスター化列ストア インデックス (CCI) が設定されている 6,000 万行未満のテーブル) に関する詳細を確認してください。

SynapseManagementClient SDK のバージョンを更新する

新しい SynapseManagementClient では .NET SDK 4.0 以降が使用されています。

Synapse ワークスペース - UpgradeSynapseManagementClientSDK (SynapseManagementClient SDK のバージョンを更新する) に関する詳細を確認してください。

Compute

vSAN の容量使用率が重大しきい値を超えました

vSAN の容量使用率が 75% に達しました。 SLA のコンプライアンスのためには、クラスターの使用率が 75% の重大しきい値を下回っている必要があります。 新しいノードを vSphere クラスターに追加して容量を増やすか、VM を削除して使用量を減らすか、VM のワークロードを調整します

Azure VMware Solution プライベート クラウド - vSANCapacity (vSAN の容量使用率が重大しきい値を超えた) に関する詳細を確認してください。

Automanage を最新の API バージョンに更新する

このサブスクリプションのリソースに対する SDK 呼び出しに、古い API が使用されていることがわかりました。 最新の機能とパフォーマンスの向上を確実に享受できるように、最新の SDK バージョンに切り替えることをお勧めします。

詳細については、仮想マシン - UpdateToLatestApi (Automanage を最新の API バージョンに更新してください) に関する記事を参照してください。

ユーザーの場所の近くに VM をデプロイすることにより、ユーザー エクスペリエンスと接続性を向上させます。

お使いの VM は、ユーザーが Azure Virtual Desktop と接続している場所とは異なる、または離れたリージョンにあると判断しました。 ユーザーのリージョンが離れていると、接続応答時間が長くなり、全体的なユーザー エクスペリエンスに影響を与える可能性があります。

仮想マシン - RegionProximitySessionHosts (ユーザーの場所の近くに VM をデプロイすることにより、ユーザー エクスペリエンスと接続性を向上させる) に関する詳細を確認してください。

Managed Disks を使用してディスク I/O スロットリングを防ぐ

ご使用の仮想マシンのディスクは、そのスケーラビリティ ターゲットに達したストレージ アカウントに属しており、I/O スロットリングの影響を受けます。 仮想マシンのパフォーマンス低下を防ぎ、ストレージ管理を簡略化するには、Managed Disks を使用します。

仮想マシン - ManagedDisksStorageAccount (Managed Disks を使用してディスク I/O スロットリングを防ぐ) に関する詳細を確認してください。

パフォーマンスを向上させるために、マネージド ディスクを Standard HDD から Premium SSD に変換する

お使いの Standard HDD ディスクがパフォーマンス目標に近づいていることがわかりました。 Azure Premium SSD は、IO 集中型ワークロードがある仮想マシン向けに、高パフォーマンスで待ち時間の少ないディスク サポートを提供します。 Standard HDD ディスクを Premium SSD ディスクにアップグレードして、ディスクのパフォーマンスを向上させてください。 アップグレードには VM の再起動が必要です。これには 3 分から 5 分かかります。

ディスク - MDHDDtoPremiumForPerformance (パフォーマンスを向上させるために、マネージド ディスクを Standard HDD から Premium SSD に変換する) に関する詳細を確認してください。

高速ネットワークを有効にして、ネットワークのパフォーマンスと待機時間を改善する

高速ネットワークをサポートできる可能性がある既存のデプロイの VM リソースで、この機能が有効になっていないことが検出されました。 ドキュメントに記載されているように、VM OS イメージが高速ネットワークをサポートしている場合は、クラウドでのネットワーク ワークロードのパフォーマンスと待機時間を最適化するために、これらの VM でこの無料機能を有効にするようにしてください

仮想マシン - AccelNetConfiguration (高速ネットワークを有効にして、ネットワークのパフォーマンスと待機時間を改善する) に関する詳細を確認してください。

運用ワークロードに SSD ディスクを使用する

同じ VM 上で SSD ディスクと Standard HDD ディスクが使用されていることがわかりました。 開発テストとバックアップ向けには Standard HDD マネージド ディスクをお勧めします。運用環境向けには Premium SSD または Standard SSD を使用することをお勧めします。 Premium SSD は、IO 集中型ワークロードがある Virtual machines 向けに、高パフォーマンスで待ち時間の短いディスク サポートを提供します。 Standard SSD は、一貫性とより短い待ち時間を提供します。 待機時間、信頼性、および可用性を向上させるために、ディスク構成を今すぐアップグレードしてください。 アップグレードには VM の再起動が必要です。これには 3 分から 5 分かかります。

仮想マシン - MixedDiskTypeToSSDPublic (運用ワークロードに SSD ディスクを使用する) に関する詳細を確認してください。

運用 Virtual Machines と運用ディスクを一致させ、パフォーマンスと待機時間を向上させる

最適なパフォーマンスを得るには、運用環境の仮想マシンに運用ディスクが必要です。 運用レベルの仮想マシンを実行していますが、Standard HDD の低パフォーマンスのディスクを使用していることがわかっています。 接続されているディスクを Standard SSD または Premium SSD のいずれかの運用ディスクにアップグレードすると、より一貫したエクスペリエンスになり、待機時間が短縮されます。

仮想マシン - MatchProdVMProdDisks (運用 Virtual Machines と運用ディスクを一致させ、パフォーマンスと待機時間を向上させる) に関する詳細を確認してください。

高速ネットワークでは、VM の停止と起動が必要になる場合があります

高速ネットワークが必要な場合でも、既存のデプロイの VM リソースで使用されていないことが検出されました。 このようなケースはまれですが、高速ネットワークの使用を再開するには、必要に応じて、都合のよいときに VM を停止し、起動します。

詳細については、「仮想マシン - AccelNetDisengaged (高速ネットワークでは、VM の停止と起動が必要になる場合があります)」を参照してください。

ログ ディスクに Ultra Disk の低遅延を活用し、データベース ワークロード パフォーマンスを改善する

Ultra Disk は、データベース ワークロードと同じリージョンで利用できます。 Ultra Disk を利用すると、データベース ワークロードのスループットと IOPS が高くなり、ディスク ストレージが一貫して低遅延になります。Oracle DB の場合、お使いの Oracle DB バージョンに基づき、Ultra Disk で 4k または 512E のセクター サイズを使用できます。 SQL Server の場合、ログ ディスクに Ultra Disk を使用すると、データベースのパフォーマンスが向上する可能性があります。 ログ ディスクを Ultra Disk に移行する方法については、こちらの指示をご覧ください。

仮想マシン - AzureStorageVmUltraDisk (ログ ディスクに Ultra Disk の低遅延を活用し、データベース ワークロード パフォーマンスを改善する) に関する詳細を確認してください。

リソースの枯渇を防ぎ、パフォーマンスを向上させるために、最もアクティブな仮想マシンのサイズをアップグレードする

過去 7 日間のデータを分析し、さまざまなメトリック (つまり、CPU、メモリ、VM IO) にわたって使用率が高い仮想マシン (VM) を特定しました。 これらの VM は、SKU の制限に近付いているか、または上限に達しているため、パフォーマンスの問題が発生する可能性があります。 パフォーマンスを向上させるために、SKU のアップグレードを検討してください。

詳細については、「仮想マシン - UpgradeSizeHighVMUtilV0 (リソースの枯渇を防ぎ、パフォーマンスを向上させるために、最もアクティブな仮想マシンのサイズをアップグレードする)」を参照してください。

Containers

サポートされていない Kubernetes バージョンが検出されます

サポートされていない Kubernetes バージョンが検出されます。 Kubernetes クラスターでサポートされているバージョンが実行されていることを確認します。

Kubernetes サービス - UnsupportedKubernetesVersionIsDetected (サポートされていない Kubernetes バージョンが検出される) に関する詳細を確認してください。

サポートされていない Kubernetes バージョンが検出されます

サポートされていない Kubernetes バージョンが検出されます。 Kubernetes クラスターでサポートされているバージョンが実行されていることを確認します。

詳細については、HDInsight クラスター プール - UnsupportedHiloAKSVersionIsDetected (サポートされていない Kubernetes バージョンが検出されました) に関する記事を参照してください。

1 つのノード プールを使用するクラスター

1 つのノード プールを使用するのではなく、1 つ以上のノード プールを追加することをお勧めします。 複数のプールは、アプリケーションから重要なシステム ポッドを分離するのに役立ちます。これにより、間違ったまたは悪意のあるアプリケーション ポッドが誤ってシステム ポッドを強制終了することを防ぐことができます。

詳細については、「Kubernetes サービス - ClustersWithASingleNodePool (1 つのノード プールを使用するクラスター)」を参照してください。

Fleet API を最新バージョンに更新する

サブスクリプションのリソースに対する SDK 呼び出しに、古い Fleet API が使われていることがわかりました。 最新の機能とパフォーマンスの向上を確実に享受できるように、最新の SDK バージョンに切り替えることをお勧めします。

詳細については、「Kubernetes fleet manager | プレビュー - UpdateToLatestFleetApi (Fleet API を最新バージョンに更新する)」を参照してください。

データベース

Azure Cosmos DB クエリ ページ サイズ (MaxItemCount) を -1 に構成する

Azure Cosmos DB コンテナーのクエリに 100 のクエリ ページ サイズが使用されています。 高速なスキャンのために、-1 のページ サイズの使用をお勧めします。

Azure Cosmos DB アカウント - CosmosDBQueryPageSize (Azure Cosmos DB クエリ ページ サイズ (MaxItemCount) を -1 に構成する) に関する詳細を確認してください。

Azure Cosmos DB コンテナーに複合インデックスを追加する

Azure Cosmos DB コンテナーで ORDER BY クエリが実行されていますが、これにより高額な要求ユニット (RU) 料金が発生します。 RU の消費を改善し、これらのクエリの待機時間を短縮するために、コンテナーのインデックス作成ポリシーに複合インデックスを追加することをお勧めします。

Azure Cosmos DB アカウント - CosmosDBOrderByHighRUCharge (Azure Cosmos DB コンテナーに複合インデックスを追加する) に関する詳細を確認してください。

必要な対象にのみインデックスを付けるように Azure Cosmos DB インデックス作成ポリシーを最適化する

Azure Cosmos DB コンテナーで使用される既定のインデックス作成ポリシーでは、ドキュメント内のすべてのプロパティにインデックスが付けられます。 大きいドキュメントが格納されるため、大量のプロパティにインデックスが付けられます。その結果、要求ユニットの消費量が高くなり、書き込み待機時間が長くなります。 書き込みパフォーマンスを最適化するには、既定のインデックス作成ポリシーをオーバーライドして、クエリで使用されるプロパティにのみインデックスを付けるようにすることをお勧めします。

Azure Cosmos DB アカウント - CosmosDBDefaultIndexingWithManyPaths (必要な対象にのみインデックスを付けるように Azure Cosmos DB インデックス作成ポリシーを最適化する) に関する詳細を確認してください。

最適なデータ分散のために階層パーティション キーを使用する

アカウントには、コンテナー内の論理パーティション サイズが 20 GB の制限を超えることを許可するカスタム設定があります。 この設定は、異なるパーティション キーでアプリケーションを再設計する時間を提供するための一時的な手段として、Azure Cosmos DB チームが適用しました。 上限が引き上げられていると SLA の保証が適用されないため、長期的な解決策としては推奨されません。 現在は、階層型パーティション キー (プレビュー) を使用して、アプリケーションを再設計できます。 この機能を使用すると、最大 3 つのパーティション キーを設定することで、20 GB の制限を超えることができ、マルチテナントのシナリオや合成キーを使用するワークロードに最適です。

Azure Cosmos DB アカウント - CosmosDBHierarchicalPartitionKey (最適なデータ分散のために階層パーティション キーを使用する) に関する詳細を確認してください。

SDK で直接接続を使用するように Azure Cosmos DB アプリケーションを構成する

Azure Cosmos DB アプリケーションが Azure Cosmos DB .NET または Java SDK を介してゲートウェイ モードを使用していることが検出されました。 短い待機時間と高い拡張性のために、直接接続へ切り替えることをお勧めします。

Azure Cosmos DB アカウント - CosmosDBGatewayMode (SDK で直接接続を使用するように Azure Cosmos DB アプリケーションを構成する) に関する詳細を確認してください。

最適なリソース使用率のためのスケールアップによるパフォーマンスの向上

最高のパフォーマンスを維持するには、システムのリソースの効率を最大化することが重要です。 Microsoft のシステムは CPU 使用率を厳密に監視し、12 時間にわたって 90% のしきい値を超えると、プロアクティブ アラートがトリガーされます。 このアラートは、Azure Cosmos DB for MongoDB 仮想コア ユーザーに CPU 使用率の上昇を通知するだけでなく、より高いレベルへのスケールアップに関する重要なガイダンスも提供します。 より堅牢なレベルにアップグレードすることで、パフォーマンスを向上させ、システムがピーク時に動作するようにすることができます。

詳細については、「Azure Cosmos DB for MongoDB 仮想コア クラスターのスケーリングと構成」を参照してください。

PerformanceBoostervCore

CPU 使用率が 12 時間以内に 90% を超えると、使用率の高さに関する通知がユーザーに送信されます。 さらに、パフォーマンスを向上させるために、より高い階層にスケールアップすることをお勧めします。

詳細については、「Cosmos DB アカウント - ScaleUpvCoreRecommendation (PerformanceBoostervCore)」を参照してください。

MariaDB サーバーの容量の上限を拡張する

システムは、現在プロビジョニングされているストレージ値の上限に近づいているため、サーバーが制約を受ける可能性があることを示しています。 ストレージの制限に近づくと、パフォーマンスが低下したり、サーバーが読み取り専用モードに移行したりする可能性があります。 継続的なパフォーマンスを確保するために、プロビジョニングされたストレージ容量を増やすか、ストレージ容量を自動的に増やすために "自動拡張" 機能をオンにすることをお勧めします。

MariaDB サーバー - OrcasMariaDbStorageLimit (MariaDB サーバーの容量の上限を拡張する) に関する詳細を確認してください。

MariaDB サーバーの仮想コアを増加させる

システムは、過去 7 日間より長い期間にわたって CPU の利用率が高くなっていることを示しています。 高い CPU 使用率は、クエリのパフォーマンスの低下につながる可能性があります。 パフォーマンスを向上させるには、より大きなコンピューティング サイズに移行することをお勧めします。

MariaDB サーバー - OrcasMariaDbCpuOverload (MariaDB サーバーの仮想コアを増加させる) に関する詳細を確認してください。

MariaDB サーバーを上位の SKU にスケーリングする

システムは、指定された SKU でサポートされている接続の最大数が原因でサーバーが接続要求をサポートできない可能性があり、その結果多数の接続要求が失敗しパフォーマンスに悪影響が及ぶ可能性があることを示しています。 パフォーマンスを向上させるには、仮想コアを増やすか、メモリ最適化 SKU への切り替えによってより多くのメモリの SKU に移行することをお勧めします。

MariaDB サーバー - OrcasMariaDbConcurrentConnection (MariaDB サーバーを上位の SKU にスケーリングする) に関する詳細を確認してください。

MariaDB サーバーをメモリ最適化 SKU へ移行する

システムは、このサーバーのバッファー プールに、クエリのパフォーマンスの低下と IOPS の増加の原因となる高いチャーンがあることを示しています。 パフォーマンスを向上させるには、ワークロードのクエリをレビューし、消費メモリを最小に抑えられないかどうかを確認します。 そのような機会が見つからない場合は、メモリの多い上位の SKU に移行するか、より多くの IOPS を得るために記憶域のサイズを増やすことをお勧めします。

MariaDB サーバー - OrcasMariaDbMemoryCache (MariaDB サーバーをメモリ最適化 SKU へ移行する) に関する詳細を確認してください。

監査ログの信頼性を向上する

システムは、サーバーの監査ログが過去 1 日間失われた可能性があることを示しています。 監査ログの喪失は、サーバーの CPU 負荷が高い場合、またはサーバーで短期間に大量の監査ログが生成された場合に発生する可能性があります。 audit_log_events、audit_log_exclude_users、audit_log_include_users のサーバー パラメーターを使用して、監査目的で必要なイベントのみをログに記録することをお勧めします。 ワークロードが原因でサーバーの CPU 使用率が高い場合は、サーバーの仮想コアを増やしてパフォーマンスを向上させることをお勧めします。

MariaDB サーバー - OrcasMariaDBAuditLog (監査ログの信頼性を向上する) に関する詳細を確認してください。

MySQL サーバーの容量の上限を拡張する

システムは、現在プロビジョニングされているストレージ値の上限に近づいているため、サーバーが制約を受ける可能性があることを示しています。 ストレージの制限に近づくと、パフォーマンスが低下したり、サーバーが読み取り専用モードに移行したりする可能性があります。 継続的なパフォーマンスを確保するために、プロビジョニングされたストレージ容量を増やすか、ストレージ容量を自動的に増やすために "自動拡張" 機能をオンにすることをお勧めします。

MySQL サーバー - OrcasMySQLStorageLimit (MySQL サーバーの容量の上限を拡張する) に関する詳細を確認してください。

MySQL サーバーを上位の SKU にスケーリングする

システムは、指定された SKU でサポートされている接続の最大数が原因でサーバーが接続要求をサポートできない可能性があり、その結果多数の接続要求が失敗しパフォーマンスに悪影響が及ぶ可能性があることを示しています。 パフォーマンスを向上させるには、仮想コアを増やすか、メモリ最適化 SKU への切り替えによってより多くのメモリの SKU に移行することをお勧めします。

MySQL サーバー - OrcasMySQLConcurrentConnection (MySQL サーバーを上位の SKU にスケーリングする) に関する詳細を確認してください。

MySQL サーバーの仮想コアを増加させる

システムは、過去 7 日間より長い期間にわたって CPU の利用率が高くなっていることを示しています。 高い CPU 使用率は、クエリのパフォーマンスの低下につながる可能性があります。 パフォーマンスを向上させるには、より大きなコンピューティング サイズに移行することをお勧めします。

MySQL サーバー - OrcasMySQLCpuOverload (MySQL サーバーの仮想コアを増加させる) に関する詳細を確認してください。

MySQL サーバーをメモリが最適化された SKU へ移行する

システムは、このサーバーのバッファー プールに、クエリのパフォーマンスの低下と IOPS の増加の原因となる高いチャーンがあることを示しています。 パフォーマンスを向上させるには、ワークロードのクエリをレビューし、消費メモリを最小に抑えられないかどうかを確認します。 そのような機会が見つからない場合は、メモリの多い上位の SKU に移行するか、より多くの IOPS を得るために記憶域のサイズを増やすことをお勧めします。

MySQL サーバー - OrcasMySQLMemoryCache (MySQL サーバーをメモリ最適化 SKU へ移行する) に関する詳細を確認してください。

MySQL 読み取りレプリカ サーバーを追加する

システムは、読み取り負荷の高いワークロードが実行中であり、その結果このサーバーでリソース競合が発生する可能性があることを示しています。 リソース競合により、サーバーのクエリのパフォーマンスが低下する可能性があります。 パフォーマンスを向上させるには、読み取りレプリカを追加し、そのレプリカに読み取りワークロードの一部をオフロードすることをお勧めします。

MySQL サーバー - OrcasMySQLReadReplica (MySQL 読み取りレプリカ サーバーを追加する) に関する詳細を確認してください。

MySQL 接続管理を向上させる

システムは、お使いの MySQL サーバーに接続しているアプリケーションが接続を適切に管理しておらず、その結果リソースの不要な消費が発生し、アプリケーションの待機時間が全体的に長くなる可能性があることを示しています。 接続管理を向上させるには、有効期間の短い接続の数を減らし、不要なアイドル状態の接続を排除することをお勧めします。 これを行うには、ProxySQL などのサーバー側の接続プーラーを構成します。

MySQL サーバー - OrcasMySQLConnectionPooling (MySQL 接続管理を向上させる) に関する詳細を確認してください。

監査ログの信頼性を向上する

システムは、サーバーの監査ログが過去 1 日間失われた可能性があることを示しています。 これは、サーバーの CPU 負荷が高い場合、またはサーバーで短期間に大量の監査ログが生成された場合に発生する可能性があります。 audit_log_events、audit_log_exclude_users、audit_log_include_users のサーバー パラメーターを使用して、監査目的で必要なイベントのみをログに記録することをお勧めします。 ワークロードが原因でサーバーの CPU 使用率が高い場合は、サーバーの仮想コアを増やしてパフォーマンスを向上させることをお勧めします。

MySQL サーバー - OrcasMySQLAuditLog (監査ログの信頼性を向上する) に関する詳細を確認してください。

MySQL の一時テーブルのサイズを最適化してパフォーマンスを向上させる

システムは、一時テーブルのパラメーター設定が低いため、お使いの MySQL サーバーで不要な I/O オーバーヘッドが発生している可能性があることを示しています。 これにより、ディスク ベースの不要なトランザクションが発生し、パフォーマンスが低下する可能性があります。 "tmp_table_size" パラメーターと "max_heap_table_size" パラメーターの値を大きくして、ディスク ベースのトランザクションの数を減らすことをお勧めします。

MySQL サーバー - OrcasMySqlTmpTables (MySQL の一時テーブルのサイズを最適化してパフォーマンスを向上させる) に関する詳細を確認してください。

MySQL 接続の待機時間の向上

システムは、お使いの MySQL サーバーに接続するアプリケーションで、接続が適切に管理されていない可能性があることを示しています。 これにより、アプリケーションの待機時間が長くなる可能性があります。 接続の待機時間を向上させるには、接続のリダイレクトを有効にすることをお勧めします。 これを行うには、PHP ドライバーの接続のリダイレクト機能を有効にします。

MySQL サーバー - OrcasMySQLConnectionRedirection (MySQL 接続の待機時間を向上させる) に関する詳細を確認してください。

MySQL フレキシブル サーバーのストレージの上限を増やす

システムは、現在プロビジョニングされているストレージ値の上限に近づいているため、サーバーが制約を受ける可能性があることを示しています。 ストレージの制限に近づくと、パフォーマンスが低下したり、サーバーが読み取り専用モードに移行したりする可能性があります。 継続的なパフォーマンスを確保するために、プロビジョニングされたストレージ容量を増やすことをお勧めします。

Azure Database for MySQL のフレキシブル サーバー - OrcasMeruMySqlStorageUpsell (MySQL フレキシブル サーバーのストレージの上限を増やす) に関する詳細を確認してください。

MySQL フレキシブル サーバーを、より上位の SKU にスケーリングする

システムは、お使いのフレキシブル サーバーは現在の SKU に関連付けられている接続制限を超えていることを示しています。 接続リクエストの失敗件数が多くなると、サーバーのパフォーマンスに悪影響を及ぼす可能性があります。 パフォーマンスを向上させるには、仮想コアの数を増やすか、より上位の SKU に切り替えることをお勧めします。

Azure Database for MySQL のフレキシブル サーバー - OrcasMeruMysqlConnectionUpsell (MySQL フレキシブル サーバーを、より上位の SKU にスケーリングする) に関する詳細を確認してください。

MySQL フレキシブル サーバーの仮想コアを増加させます。

システムは、過去 7 日間より長い期間にわたって CPU の利用率が高くなっていることを示しています。 高い CPU 使用率は、クエリのパフォーマンスの低下につながる可能性があります。 パフォーマンスを向上させるには、より大きなコンピューティング サイズに移行することをお勧めします。

Azure Database for MySQL のフレキシブル サーバー - OrcasMeruMysqlCpuUpcell (MySQL フレキシブル サーバーの仮想コアを増加させる) に関する詳細を確認してください。

MySQL の一時テーブルのサイズを最適化してパフォーマンスを向上させます。

システムは、一時テーブルのパラメーター設定が低いため、お使いの MySQL サーバーで不要な I/O オーバーヘッドが発生している可能性があることを示しています。 不要な I/O オーバーヘッドにより、ディスク ベースの不要なトランザクションが発生し、パフォーマンスが低下する可能性があります。 "tmp_table_size" パラメーターと "max_heap_table_size" パラメーターの値を大きくして、ディスク ベースのトランザクションの数を減らすことをお勧めします。

Azure Database for MySQL のフレキシブル サーバー - OrcasMeruMysqlTmpTable (MySQL の一時テーブルのサイズを最適化してパフォーマンスを向上させる) に関する詳細を確認してください。

MySQL サーバーをメモリが最適化された SKU へ移行する

システムは、このサーバーのメモリ使用率が高く、それが原因でクエリ パフォーマンスの低下と IOPS の増加となる可能性があることを示しています。 パフォーマンスを向上させるには、ワークロードのクエリをレビューし、消費メモリを最小に抑えられないかどうかを確認します。 そのような機会が見つからない場合は、メモリの多い上位の SKU に移行するか、より多くの IOPS を得るために記憶域のサイズを増やすことをお勧めします。

Azure Database for MySQL のフレキシブル サーバー - OrcasMeruMysqlMemoryUpsell (MySQL サーバーをメモリが最適化された SKU へ移行する) に関する詳細を確認してください。

MySQL 読み取りレプリカ サーバーを追加する

システムは、読み取り負荷の高いワークロードが実行中であり、その結果このサーバーでリソース競合が発生する可能性があることを示しています。 これにより、サーバーのクエリのパフォーマンスが低下する可能性があります。 パフォーマンスを向上させるには、読み取りレプリカを追加し、そのレプリカに読み取りワークロードの一部をオフロードすることをお勧めします。

Azure Database for MySQL のフレキシブル サーバー - OrcasMeruMysqlReadReplicaUpsell (MySQL 読み取りレプリカ サーバーを追加する) に関する詳細を確認してください。

work_mem を増やして、並べ替えとハッシュによるディスクの過度な書き込みを回避する

システムは、PostgreSQL サーバーに対して work_mem の構成が小さすぎることを示しています。これにより、ディスクの書き込みとクエリ パフォーマンスの低下が生じます。 これを改善するには、サーバーの work_mem の制限値を大きくすることをお勧めします。これにより、ディスクで並べ替えやハッシュが発生した際にこのシナリオが起こるのを減らすことができ、全体的なクエリ パフォーマンスが向上します。

PostgreSQL サーバー - OrcasPostgreSqlWorkMem (work_mem を増やして、並べ替えとハッシュによるディスクの過度な書き込みを回避する) に関する詳細を確認してください。

新しい Ev5 コンピューティング ハードウェアを使用してワークロードのパフォーマンスを 30% 向上させる

新しい Ev5 コンピューティング ハードウェアを使用すると、コンカレンシーが高くなり、スループットが向上するため、ワークロードのパフォーマンスを 30% 向上させることができます。 Azure portal の [コンピューティングとストレージ] オプションに移動し、追加コストなしで Ev5 コンピューティングに切り替えます。 Ev5 コンピューティングは、QPS と待ち時間に関して、他の VM シリーズの中で最高のパフォーマンスを発揮します。

詳細については、「Azure Database for MySQL フレキシブル サーバー - OrcasMeruMySqlComputeSeriesUpgradeEv5 (新しい Ev5 コンピューティング ハードウェアを使用してワークロードのパフォーマンスを 30% 向上させる)」を参照してください。

Hyperscale (Citus) サーバー グループの記憶域の上限の引き上げ

システムは、サーバー グループ内の 1 つ以上のノードが、現在プロビジョニングされているストレージの値の上限に近づいているため、制限されている可能性があることを示しています。 これにより、パフォーマンスが低下したり、サーバーが読み取り専用モードに移行したりする可能性があります。 継続的なパフォーマンスを確保するために、プロビジョニングされたディスク領域を増やすことをお勧めします。

PostgreSQL サーバー - OrcasPostgreSqlCitusStorageLimitHyperscaleCitus (Hyperscale (Citus) サーバー グループの記憶域の上限を引き上げる) に関する詳細を確認してください。

PostgreSQL サーバーの仮想コアを増加させる

7 日間の CPU 使用率は、「2 時間以上で 90% 以上、50% の時間で 50% 以上、20% の時間で最大使用率」の少なくとも 1 つでした。 高い CPU 使用率は、クエリのパフォーマンスの低下につながる可能性があります。 パフォーマンスを向上させるには、より高いコンピューティング能力を備えたより大きな SKU にサーバーを移行することをお勧めします。 Azure Database for PostgreSQL フレキシブル サーバー - Azure Database 上の Upscale Server SKU for PostgreSQL に関する詳細を確認してください。

Azure Database で PostgreSQL の log_statement 設定を最適化します

システムは、log_statement が有効になっていることを示しています。パフォーマンス向上のためにそれを NONE に設定してください

Azure Database for PostgreSQL フレキシブル サーバー - Azure Database で PostgreSQL の log_statement 設定を最適化するに関する詳細を確認してください。

Azure Database で PostgreSQL の log_duration 設定を最適化します

ログ設定により、パフォーマンスが低下する可能性があります。 これらの設定を最適化するには、log_duration サーバー パラメーターを OFF に設定します。

Azure Database for PostgreSQL フレキシブル サーバー - Azure Database で PostgreSQL の log_duration 設定を最適化するに関する詳細を確認してください。

Azure Database で PostgreSQL の log_min_duration 設定を最適化します

og_min_duration サーバー パラメーターが 60,000 ミリ秒 (1 分) 未満に設定されているため、パフォーマンスが低下する可能性があります。 Log_min_duration_statement パラメーターを -1 に設定することで、ログ設定を最適化できます。

Azure Database for PostgreSQL フレキシブル サーバー - Azure Database で PostgreSQL の log_min_duration 設定を最適化するに関する詳細を確認してください。

Azure Database で PostgreSQL の log_error_verbosity 設定を最適化します

サーバーは詳細なエラー ログを出力するように構成されています。 これはデータベースのトラブルシューティングに役立ちますが、データベースのパフォーマンスが低下する場合もあります。 パフォーマンスを向上させるには、log_error_verbosity サーバー パラメーターを DEFAULT 設定に変更することをお勧めします。

Azure Database for PostgreSQL フレキシブル サーバー - Azure Database で PostgreSQL の log_error_verbosity 設定を最適化するに関する詳細を確認してください。

PostgreSQL - フレキシブル サーバーのパフォーマンスを向上させるために、チェックポイントが頻繁に発生しているかどうかを特定する

サーバーが頻繁にチェックポイントに遭遇しています。 この問題を解決するには、max_wal_size サーバー パラメーターを増やすことをお勧めします。

Azure Database for PostgreSQL フレキシブル サーバー - max_wal_size を増やすに関する詳細を確認してください。

PostgreSQL フレキシブル サーバーのパフォーマンスを向上させるために、非アクティブな論理レプリケーション スロットを特定する

サーバーに非アクティブな論理レプリケーション スロットがあると、サーバーのパフォーマンスと可用性が低下する可能性があります。 非アクティブなレプリケーション スロットを削除するか、スロットからの変更を消費して、ログ シーケンス番号 (LSN) をサーバーの現在の LSN に近づけることをお勧めします。

Azure Database for PostgreSQL フレキシブル サーバー - 未使用または非アクティブな論理レプリケーション スロットに関する詳細を確認してください。

PostgreSQL - フレキシブル サーバーのパフォーマンスを向上させるために実行時間の長いトランザクションを特定する

24 時間以上実行されているトランザクションがあります。 問題を特定して軽減するには、トラブルシューティング ガイドの CPU 使用率が高い -> 実行時間の長いトランザクションのセクションを確認してください。

Azure Database for PostgreSQL フレキシブル サーバー - トラブルシューティング ガイドを使用した実行時間の長いトランザクションに関する詳細を確認してください。

PostgreSQL - フレキシブル サーバーのパフォーマンスを向上させるために孤立した準備済みトランザクションを特定する

孤立した準備済みのトランザクションがあります。 準備済みのトランザクションをロールバック/コミットします。 推奨事項は、トラブルシューティング ガイドの自動バキューム ブロッカー -> 自動バキューム ブロッカーのセクションで共有されています。

Azure Database for PostgreSQL フレキシブル サーバー - トラブルシューティング ガイドを使用した孤立した準備済みトランザクションに関する詳細を確認してください。

PostgreSQL - フレキシブル サーバーのパフォーマンスを向上させるためにトランザクションのラップアラウンドを特定する

サーバーが 50% のラップアラウンド制限を超え、10 億トランザクションに達しました。 トラブルシューティング ガイドの自動バキューム ブロッカー -> 緊急自動バキュームとラップアラウンドのセクションで共有されている推奨事項を参照してください。

Azure Database for PostgreSQL フレキシブル サーバー - トラブルシューティング ガイドを使用したトランザクションのラップアラウンドに関する詳細を確認してください。

PostgreSQL - フレキシブル サーバーのパフォーマンスを向上させるために高い膨張率を特定する

サーバーの bloat_ratio (デッド タプル/ (ライブ タプル + デッド タプル)) が 80% を超えています。 トラブルシューティング ガイドの「自動バキューム監視」セクションで共有されている推奨事項を参照してください。

Azure Database for PostgreSQL フレキシブル サーバー - トラブルシューティング ガイドを使用した高い膨張率に関する詳細を確認してください。

Hyperscale (Citus) サーバー グループの記憶域の上限の引き上げ

システムは、サーバー グループ内の 1 つ以上のノードが、現在プロビジョニングされているストレージの値の上限に近づいているため、制限されている可能性があることを示しています。 これにより、パフォーマンスが低下したり、サーバーが読み取り専用モードに移行したりする可能性があります。 継続的なパフォーマンスを確保するために、プロビジョニングされたディスク領域を増やすことをお勧めします。

Hyperscale (Citus) サーバー グループ - MarlinStorageLimitRecommendation (Hyperscale (Citus) サーバー グループの記憶域の上限を引き上げる) に関する詳細を確認してください。

データベースを SSPG から FSPG に移行する

ゾーン回復性 HA、予測可能なパフォーマンス、最大限の制御、カスタム メンテナンス期間、コスト最適化コントロール、開発者エクスペリエンスの簡素化などの豊富な機能を備えている、新しい Azure Database for PostgreSQL フレキシブル サーバーを検討してください。

Azure Database for PostgreSQL フレキシブル サーバー - OrcasPostgreSqlMeruMigration (データベースを SSPG から FSPG に移行する) に関する詳細を確認してください。

高ネットワーク帯域幅の状態で実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する

キャッシュ インスタンスは、高ネットワーク帯域幅の状態で実行されていない場合に、パフォーマンスが最大化します。高ネットワーク帯域幅は応答がない、データが失われる、利用できない、などの原因となります。 ネットワーク帯域幅を減らしたり、別のサイズや SKU に拡大して容量を増やしたりするためのベスト プラクティスを適用しましょう。

Redis Cache Server - RedisCacheNetworkBandwidth (高ネットワーク帯域幅の状態で実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する) に関する詳細を確認してください。

多数のクライアントと接続して実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する

キャッシュ インスタンスは、高ネットワーク帯域幅の状態で実行されていない場合に、パフォーマンスが最大化します。高ネットワーク帯域幅は応答がない、データが失われる、利用できない、などの原因となります。 サーバーの負荷を減らしたり、別のサイズや SKU に拡大して容量を増やしたりするためのベスト プラクティスを適用しましょう。

Redis Cache Server - RedisCacheConnectedClients (多数のクライアントと接続して実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する) に関する詳細を確認してください。

多数のクライアントと接続して実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する

キャッシュ インスタンスは、高ネットワーク帯域幅の状態で実行されていない場合に、パフォーマンスが最大化します。高ネットワーク帯域幅は応答がない、データが失われる、利用できない、などの原因となります。 サーバーの負荷を減らしたり、別のサイズや SKU に拡大して容量を増やしたりするためのベスト プラクティスを適用しましょう。

Redis Cache Server - RedisCacheConnectedClientsHigh (多数のクライアントと接続して実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する) に関する詳細を確認してください。

サーバーの負荷が高い状態で実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する

キャッシュ インスタンスは、高ネットワーク帯域幅の状態で実行されていない場合に、パフォーマンスが最大化します。高ネットワーク帯域幅は応答がない、データが失われる、利用できない、などの原因となります。 サーバーの負荷を減らしたり、別のサイズや SKU に拡大して容量を増やしたりするためのベスト プラクティスを適用しましょう。

Redis Cache Server - RedisCacheServerLoad (サーバーの負荷が高い状態で実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する) に関する詳細を確認してください。

サーバーの負荷が高い状態で実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する

キャッシュ インスタンスは、高ネットワーク帯域幅の状態で実行されていない場合に、パフォーマンスが最大化します。高ネットワーク帯域幅は応答がない、データが失われる、利用できない、などの原因となります。 サーバーの負荷を減らしたり、別のサイズや SKU に拡大して容量を増やしたりするためのベスト プラクティスを適用しましょう。

Redis Cache Server - RedisCacheServerLoadHigh (サーバーの負荷が高い状態で実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する) に関する詳細を確認してください。

メモリ不足の状態で実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する

キャッシュ インスタンスは、高ネットワーク帯域幅の状態で実行されていない場合に、パフォーマンスが最大化します。高ネットワーク帯域幅は応答がない、データが失われる、利用できない、などの原因となります。 メモリの使用を減らしたり、別のサイズや SKU に拡大して容量を増やしたりするためのベスト プラクティスを適用しましょう。

Redis Cache Server - RedisCacheUsedMemory (メモリ不足の状態で実行している場合に、キャッシュとアプリケーションのパフォーマンスを向上する) に関する詳細を確認してください。

メモリ RSS の使用率が高い場合に、キャッシュとアプリケーションのパフォーマンスを向上させます。

キャッシュ インスタンスは、高ネットワーク帯域幅の状態で実行されていない場合に、パフォーマンスが最大化します。高ネットワーク帯域幅は応答がない、データが失われる、利用できない、などの原因となります。 メモリの使用を減らしたり、別のサイズや SKU に拡大して容量を増やしたりするためのベスト プラクティスを適用しましょう。

Redis Cache Server - RedisCacheUsedMemoryRSS (メモリ RSS の消費量が多い場合に、キャッシュとアプリケーションのパフォーマンスを向上させる) に関する詳細を確認してください。

キャッシュ インスタンスは、クライアント アプリケーションが実行されるホスト コンピューターがキャッシュからの応答に対応できる場合に最適に実行されます

キャッシュ インスタンスは、クライアント アプリケーションが実行されるホスト コンピューターがキャッシュからの応答に対応できる場合に最適に実行されます。 クライアント ホスト マシンでのメモリ、CPU、またはネットワーク帯域幅の使用率が高い場合、キャッシュ応答はアプリケーションに十分な速度で到達せず、待機時間が長くなる可能性があります。

Redis Cache Server - UnresponsiveClient (キャッシュ インスタンスは、クライアント アプリケーションが実行されるホスト コンピューターがキャッシュからの応答に対応できる場合に最適に実行される) に関する詳細を確認してください。

DevOps

AMS API の最新バージョンへの更新

推奨されない Azure Media Services (AMS) API バージョンの呼び出しを特定しました。 AMS API の最新バージョンに切り替えて、AMS、最新の機能、向上したパフォーマンスに継続的にアクセスできるようにすることをお勧めします。

詳細については、「モニター - UpdateToLatestAMSApiVersion (AMS API の最新バージョンへの更新)」を参照してください。

最新のワークロード SDK バージョンにアップグレードする

モデルの品質、パフォーマンス、サービスの可用性に関して最適な結果を得るために、最新のワークロード SDK バージョンにアップグレードします。

詳細については、「モニター - UpgradeToLatestAMSSdkVersion (最新のワークロード SDK バージョンにアップグレードする)」を参照してください。

統合

API Management リソースを別のバージョンにアップグレードする

サブスクリプションが、非推奨になる予定のバージョンで実行されています。 2021-08-01 より前の Azure API Management サービスの API バージョンは、2023 年 9 月 30 日をもってすべて廃止されたため、API 呼び出しは失敗します。 サービスの中断を防ぐために、新しいバージョンにアップグレードしてください。

詳細については、「API Management - apimgmtdeprecation (API Management リソースを別のバージョンにアップグレードする)」を参照してください。

Mobile

推奨バージョンの Chat SDK を使用する

Azure Communication Services Chat SDK を使用して、アプリケーションに高度なリアルタイム チャットを追加できます。 推奨されるバージョンの Chat SDK に更新し、最新の修正と機能にしてください。

Communication Services - UpgradeChatSdk (推奨バージョンの Chat SDK を使用する) に関する詳細を確認してください。

推奨されるバージョンの Resource Manager SDK を使用する

Resource Manager SDK を使用すると、Azure Communication Services のリソースを作成して管理できます。 推奨されるバージョンの Resource Manager SDK に更新し、最新の修正と機能にしてください。

Communication Services - UpgradeResourceManagerSdk (推奨されるバージョンの Resource Manager SDK を使用する) に関する詳細を確認してください。

推奨されるバージョンの Identity SDK を使用する

Azure Communication Services の Identity SDK を使用すると、ID、ユーザー、アクセス トークンを管理できます。 推奨されるバージョンの Identity SDK に更新し、最新の修正と機能にしてください。

Communication Services - UpgradeIdentitySdk (推奨されるバージョンの Identity SDK を使用する) に関する詳細を確認してください。

推奨されるバージョンの SMS SDK を使用する

Azure Communication Services SMS SDK を使用すると、SMS メッセージを送受信できます。 推奨されるバージョンの SMS SDK に更新し、最新の修正と機能にしてください。

Communication Services - UpgradeSmsSdk (推奨されるバージョンの SMS SDK を使用する) に関する詳細を確認してください。

推奨されるバージョンの Phone Numbers SDK を使用する

Azure Communication Services の Phone Numbers SDK を使用すると、電話番号を取得して管理できます。 推奨されるバージョンの Phone Numbers SDK に更新し、最新の修正と機能にしてください。

Communication Services - UpgradePhoneNumbersSdk (推奨されるバージョンの Phone Numbers SDK を使用する) に関する詳細を確認してください。

推奨されるバージョンの Calling SDK を使用する

Azure Communication Services の Calling SDK を使用すると、音声、ビデオ、画面共有、その他のリアルタイム通信を有効にすることができます。 推奨されるバージョンの Calling SDK に更新し、最新の修正と機能にしてください。

Communication Services - UpgradeCallingSdk (推奨されるバージョンの Calling SDK を使用する) に関する詳細を確認してください。

推奨されるバージョンの Call Automation SDK を使用する

Azure Communication Services の Call Automation SDK を使用すると、通話の実行と管理、オーディオの再生、録音の構成を行うことができます。 推奨されるバージョンの Call Automation SDK に更新し、最新の修正と機能にしてください。

Communication Services - UpgradeServerCallingSdk (推奨されるバージョンの Call Automation SDK を使用する) に関する詳細を確認してください。

推奨されるバージョンの Network Traversal SDK を使用する

Azure Communication Services の Network Traversal SDK を使用すると、低レベルのデータ転送のために TURN サーバーにアクセスできます。 推奨されるバージョンの Network Traversal SDK に更新し、最新の修正と機能にしてください。

Communication Services - UpgradeTurnSdk (推奨されるバージョンの Network Traversal SDK を使用する) に関する詳細を確認してください。

推奨されるバージョンの Rooms SDK を使用する

Azure Communication Services Rooms SDK を使用すると、通話に参加できるユーザー、会議のタイミング、共同作業方法を制御できます。 推奨されるバージョンの Rooms SDK に更新し、最新の修正プログラムと機能を確実に適用します。 過去 48 時間から 60 時間に推奨されていないバージョンが検出されました。

詳細については、「Communication Services - UpgradeRoomsSdk (推奨されるバージョンの Rooms SDK を使用する)」を参照してください。

ネットワーク

SDK のバージョンのアップグレードに関する推奨事項

Azure Front Door Standard および Premium クライアント ライブラリ/SDK の最新バージョンには、お客様から報告された問題に対する修正と、QA プロセスを通じて事前に明らかになった問題の修正が含まれています。 また、最新バージョンには、Azure Front Door Standard および Premium の使用に関する全体的なエクスペリエンスを向上させる新機能に加えて、信頼性とパフォーマンスの最適化も含まれています。

Front Door プロファイル - UpgradeCDNToLatestSDKLanguage (SDK のバージョンのアップグレードに関する推奨事項) に関する詳細を確認してください。

SDK のバージョンのアップグレードに関する推奨事項

最新バージョンの Azure Traffic Collector SDK には、QA プロセスを通じて事前に特定された問題に対する修正プログラムが含まれており、最新のリソース モデルをサポートし、ATC の使用に関する全体的なエクスペリエンスを向上させることができる信頼性とパフォーマンスの最適化を備えています。

詳細については、「Azure Traffic Collector - UpgradeATCToLatestSDKLanguage (SDK のバージョンのアップグレードに関する推奨事項)」を参照してください。

帯域幅のニーズに合わせて ExpressRoute 回線の帯域幅をアップグレードする

最近、購入した回線の帯域幅の 90% を使用しています。 割り当てられた帯域幅を超えると、ExpressRoute を介して送信されるパケットのドロップが増加します。 帯域幅のニーズが今後もこのような高さである場合は、パフォーマンスを維持するために回路の帯域幅をアップグレードしてください。

ExpressRoute 回線 - UpgradeERCircuitBandwidth (帯域幅のニーズに合わせて ExpressRoute 回線の帯域幅をアップグレードする) に関する詳細を確認してください。

Azureへのプライベート接続により、より予測可能で安定したレイテンシーを体験できます。

Azure ExpressRouteを使用してオンプレミスネットワークをAzureに拡張することにより、ビジネスクリティカルなアプリケーションのパフォーマンス、プライバシー、信頼性を向上させることができます。 WANから直接、クラウド交換設備、POPやIPVPN接続を経由して、ExpressRouteのプライベート接続を確立します。

サブスクリプション - AzureExpressRoute (Azure へのプライベート接続により、より予測可能で安定したレイテンシーを体験できる) に関する詳細を確認してください。

Workloads API を最新バージョンにアップグレードする (Azure Center for SAP solutions API)

このリソース グループのリソースに対して古いバージョンの Workloads API を呼び出していることがわかりました。 最新バージョンの Workloads API に切り替えて、Azure Center for SAP solutions の最新の機能と向上したパフォーマンスへのアクセスが妨げられないようにすることをお勧めします。 推奨事項で示されている複数の Virtual Instance for SAP solutions (VIS) がある場合は、すべての VIS リソースの API バージョンを必ず更新してください。

詳細については、「サブスクリプション - UpdateToLatestWaasApiVersionAtSub (ワークロード API を最新バージョンにアップグレードする (Azure Center for SAP solutions API))」を参照してください。

Workloads SDK を最新バージョンにアップグレードする (Azure Center for SAP solutions SDK)

このリソース グループのリソースから古いバージョンの Workloads SDK を呼び出していることがわかりました。 Azure Center for SAP solutions のモデルの品質、パフォーマンス、サービスの可用性に関して最新の機能と最適な結果を得るため、最新バージョンのワークロード SDK にアップグレードします。 推奨事項で示されている複数の Virtual Instance for SAP solutions (VIS) がある場合は、すべての VIS リソースの SDK バージョンを必ず更新してください。

詳細については、「サブスクリプション - UpgradeToLatestWaasSdkVersionAtSub (ワークロード SDK を最新バージョンにアップグレードする (Azure Center for SAP solutions SDK))」を参照してください。

DNS の有効時間を 60 秒に構成する

Time to Live (TTL) は、クライアントが Azure Traffic Manager に要求を送った場合に応答が返されるまでの早さに影響を与えます。 TTL 値を小さくすると、フェールオーバーの発生時に、機能しているエンドポイントにクライアントがルーティングされるまでの時間が早くなります。 できるだけ早くトラフィックを正常性エンドポイントにルーティングするには、TTL を 60 秒に設定します。

Traffic Manager プロファイル - ProfileTTL (DNS の有効時間を 60 秒に構成する) に関する詳細を確認してください。

DNS の有効時間を 20 秒に構成する

Time to Live (TTL) は、クライアントが Azure Traffic Manager に要求を送った場合に応答が返されるまでの早さに影響を与えます。 TTL 値を小さくすると、フェールオーバーの発生時に、機能しているエンドポイントにクライアントがルーティングされるまでの時間が早くなります。 できるだけ早くトラフィックを正常性エンドポイントにルーティングするには、TTL を 20 秒に設定します。

Traffic Manager プロファイル - FastFailOverTTL (DNS の有効時間を 20 秒に構成する) に関する詳細を確認してください。

DNS の有効時間を 60 秒に構成する

Time to Live (TTL) は、クライアントが Azure Traffic Manager に要求を送った場合に応答が返されるまでの早さに影響を与えます。 TTL 値を小さくすると、フェールオーバーの発生時に、機能しているエンドポイントにクライアントがルーティングされるまでの時間が早くなります。 できるだけ早くトラフィックを正常性エンドポイントにルーティングするには、TTL を 60 秒に設定します。

Traffic Manager プロファイル - ProfileTTL (DNS の有効時間を 60 秒に構成する) に関する詳細を確認してください。

一貫して高い CPU 使用率に対処するために仮想ネットワーク ゲートウェイの SKU のサイズを大きくすることを検討する

トラフィックの負荷が高い状況下では、CPU の使用率が高いと VPN ゲートウェイでパケットが破棄されることがあります。

詳細については、「仮想ネットワーク ゲートウェイ - HighCPUVNetGateway (一貫して高い CPU 使用率に対処するために仮想ネットワーク (VNet) ゲートウェイの SKU のサイズを大きくすることを検討する)」を参照してください。

高 P2S 使用率に対処するために仮想ネットワーク ゲートウェイ の SKU のサイズを大きくすることを検討する

各ゲートウェイ SKU は、指定された数の同時 P2S 接続にのみ対応します。 接続数がゲートウェイの上限に迫ると、これ以上の接続試行は失敗する可能性があります。

仮想ネットワーク ゲートウェイ - HighP2SConnectionsVNetGateway (高 P2S 使用率に対処するために VNet ゲートウェイの SKU のサイズを大きくすることを検討する) に関する詳細を確認してください。

トラフィックをサポートするために十分な数のインスタンスが Application Gateway にあることを確認する

Application Gateway が最近高使用率で実行されており、負荷が高い場合は、トラフィックの損失や待機時間の増加が発生する可能性があります。 それに応じて Application Gateway をスケーリングしてバッファーを追加することが重要です。それによって、トラフィックの急増やスパイクに備え、QoS に対する影響を最小限に抑えることができます。 Application Gateway v1 SKU (Standard/WAF) では、手動スケーリングがサポートされており、v2 SKU (Standard_v2/WAF_v2) では手動と自動スケーリングがサポートされています。 手動スケーリングでは、インスタンス数を増やします。 自動スケーリングが有効になっている場合は、トラフィックの増加に応じて Application Gateway でスケールアウトできるように、最大インスタンス数が高い値に設定されていることを確認してください。

アプリケーション ゲートウェイ - HotAppGateway (トラフィックをサポートするために十分な数のインスタンスが Application Gateway にあることを確認する) に関する詳細を確認してください。

HEAD 正常性プローブを使用する

正常性プローブでは、GET または HEAD HTTP のいずれかのメソッドを使用できます。 正常性プローブには HEAD メソッドを使用することをお勧めします。これにより、オリジンに対するトラフィックの負荷が軽減されます。

「Front Door - HEAD 正常性プローブの使用」で詳細を確認します。

Azure 用の SAP

Mellanox ドライバーでのソフト ロックアップを回避するには、SAP ワークロードのアプリ VM OS の can_queue 値を減らします

Mellanox ドライバーの散発的なソフト ロックアップを回避するには、OS の can_queue 値を減らします。 値を直接設定することはできません。 次のカーネル ブート ライン オプションを追加して同じ効果を実現します。'hv_storvsc.storvsc_ringbuffer_size=131072 hv_storvsc.storvsc_vcpus_per_sub_channel=1024'

詳細については、｢アプリ サーバー インスタンス - AppSoftLockup (Mellanox ドライバーでのソフト ロックアップを回避するには、SAP ワークロードのアプリ VM OS の can_queue 値を減らします)」を参照してください。

Mellanox ドライバーでのソフト ロックアップを回避するには、SAP ワークロードの ASCS VM OS の can_queue 値を減らします

Mellanox ドライバーの散発的なソフト ロックアップを回避するには、OS の can_queue 値を減らします。 値を直接設定することはできません。 次のカーネル ブート ライン オプションを追加して同じ効果を実現します。'hv_storvsc.storvsc_ringbuffer_size=131072 hv_storvsc.storvsc_vcpus_per_sub_channel=1024'

詳細については、｢セントラル サーバー インスタンス - AscsoftLockup (Mellanox ドライバーでのソフト ロックアップを回避するには、SAP ワークロードの ASCS VM OS の can_queue 値を減らします)」を参照してください。

Mellanox ドライバーでのソフト ロックアップを回避するには、SAP ワークロードの DB VM OS の can_queue 値を減らします

Mellanox ドライバーの散発的なソフト ロックアップを回避するには、OS の can_queue 値を減らします。 値を直接設定することはできません。 次のカーネル ブート ライン オプションを追加して同じ効果を実現します。'hv_storvsc.storvsc_ringbuffer_size=131072 hv_storvsc.storvsc_vcpus_per_sub_channel=1024'

詳細については、｢Database Instance - DBSoftLockup (Mellanox ドライバーでのソフト ロックアップを回避するには、SAP ワークロードの DB VM OS の can_queue 値を減らします)」を参照してください。

ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター tcp_wmem を最適化します

パラメーター net.ipv4.tcp_wmem は、TCP ソケットに使用される最小、既定、および最大の送信バッファー サイズを指定します。 SAP ノート: 302436 に従ってパラメーターを設定することで、HANA DB を ANF で実行することが認定され、ファイル システムのパフォーマンスが向上します。 最大値はパラメーター net.core.wmem_max を超えないようにする必要があります。

詳細については、Database Instance - WriteBuffersAllocated (「ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター tcp_wmem を最適化します」) の記事を参照してください。

ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター tcp_rmem を最適化します

パラメーター net.ipv4.tcp_rmem は、TCP ソケットに使用される最小、既定、および最大の受信バッファー サイズを指定します。 SAP ノート 3024346 に従ってパラメーターを設定することで、HANA DB を ANF で実行することが認定され、ファイル システムのパフォーマンスが向上します。 最大値はパラメーター net.core.rmem_max を超えないようにする必要があります。

詳細については、「Database Instance - OptimiseReadTcp (ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター tcp_rmem を最適化します)」を参照してください。

ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター wmem_max を最適化します

ANF ストレージタイプの HANA DB では、パラメーター net.core.wmem_max で定義される最大書き込みソケット バッファーを、送信ネットワーク パケットの処理に十分な大きさに設定する必要があります。 net.core.wmem_max の構成により、HANA DB を ANF で実行することが認定され、ファイル システムのパフォーマンスが向上します。 SAP ノート: 3024346 を参照してください。

詳細については、Database Instance - MaxWriteBuffer (「ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター wmem_max を最適化します」) の記事を参照してください。

ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター tcp_rmem を最適化します

パラメーター net.ipv4.tcp_rmem は、TCP ソケットに使用される最小、既定、および最大の受信バッファー サイズを指定します。 SAP ノート 3024346 に従ってパラメーターを設定することで、HANA DB を ANF で実行することが認定され、ファイル システムのパフォーマンスが向上します。 最大値はパラメーター net.core.rmem_max を超えないようにする必要があります。

詳細については、Database Instance - OptimizeReadTcp (「ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター tcp_rmem を最適化します」) の記事を参照してください。

ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター rmem_max を最適化します

ANF ストレージタイプの HANA DB では、パラメーター net.core.rmem_max で定義される最大読み取りソケット バッファーを、受信ネットワーク パケットの処理に十分な大きさに設定する必要があります。 net.core.rmem_max の構成により、HANA DB を ANF で実行することが認定され、ファイル システムのパフォーマンスが向上します。 SAP ノート: 3024346 を参照してください。

詳細については、Database Instance - MaxReadBuffer (「ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター rmem_max を最適化します」) の記事を参照してください。

ANF を使用して HANA DB のネットワーク パケット損失を向上するには、受信側のバックログ キュー サイズを 300000 に設定します

パラメーター net.core.netdev_max_backlog は、ネットワーク インターフェイスがカーネルで処理できるよりも高速にパケットを受信する場合に使用される、受信側バックログ キューのサイズを指定します。 SAP Note: 3024346 に従ってパラメーターを設定します。 net.core.netdev_max_backlog の構成により、HANA DB を ANF で実行することが認定され、ファイル システムのパフォーマンスが向上します。

詳細については、Database Instance - BacklogQueueSize (「ANF を使用して HANA DB のネットワーク パケット損失を向上するには、受信側のバックログ キュー サイズを 300000 に設定します」) の記事を参照してください。

ANF を使用して HANA DB のファイル システムパフォーマンスを改善するには、TCP ウィンドウスケーリング OS パラメーターを有効にします

SAP Note: 302436 に従って TCP ウィンドウ スケーリング パラメーターを有効にします。 TCP ウィンドウ スケーリングの構成により、HANA DB を ANF で実行することが認定され、SAP ワークロードの ANF を使用した HANA DB のファイル システム パフォーマンスが向上します。

詳細については、Database Instance - EnableTCPWindowScaling (「ANF を使用して HANA DB のファイル システムパフォーマンスを改善するには、TCP ウィンドウスケーリング OS パラメーターを有効にします」) の記事を参照してください。

ANF を使用して HANA DB のファイル システムパフォーマンスを向上させるには、OS で IPv6 プロトコルを無効にします

SAP on Azure for HANA DB with ANF のレコメンデーションに従って IPv6 を無効にして、ファイル システムのパフォーマンスを向上させます。

詳細については、Database Instance - DisableIPv6Protocol (「ANF を使用して HANA DB のファイル システムパフォーマンスを向上させるには、OS で IPv6 プロトコルを無効にします」) の記事を参照してください。

ANF を使用して HANA DB のファイル システムのパフォーマンスを向上させるには、アイドル状態の後にスロー スタートのパラメーターを無効にします

パラメーター net.ipv4.tcp_slow_start_after_idle を使用すると、しばらくアイドル状態だった TCP 接続の TCP ウィンドウ サイズを段階的にスケールアップする必要がなくなります。 SAP ノート: 302436 に従ってこのパラメーターを 0 に設定すると、以前にアイドル状態の TCP 接続に対して最大速度が最初から使用されます。

詳細については、Database Instance - ParameterSlowStart (「ANF を使用して HANA DB のファイル システムのパフォーマンスを向上させるには、アイドル状態の後にスロー スタートのパラメーターを無効にします」) の記事を参照してください。

ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター tcp_max_syn_backlog を最適化します

短時間で多数の接続要求が送信される状況でカーネルが SYN Cookie を使用するのを防ぎ、システム ログでの SYN フラッディング攻撃の可能性に関する警告を防ぐには、SYN バックログのサイズを合理的に高い値に設定する必要があります。 SAP ノート 2382421 を参照してください。

詳細については、Database Instance - TCPMaxSynBacklog (「ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、OS パラメーター tcp_max_syn_backlog を最適化します」) の記事を参照してください。

ANF を使用して HANA DB のファイル システムパフォーマンスを向上させるには、tcp_sack OS パラメーターを有効にします

sap note: 302436 に従って、tcp_sack パラメーターを有効にします。 tcp_sack の構成により、HANA DB を ANF で実行することが認定され、SAP ワークロードの ANF を使用した HANA DB のファイル システム パフォーマンスが向上します。

詳細については、Database Instance - TCPSackParameter (「ANF を使用して HANA DB のファイル システムパフォーマンスを向上させるには、tcp_sack OS パラメーターを有効にします」) の記事を参照してください。

ANF を使用した HANA DB の高可用性シナリオでは、tcp_timestamps OS パラメーターを無効にします

sap note: 302436 に従って、tcp_timestamps パラメーターを無効にします。 tcp_timestamps の構成により、HANA DB を ANF で実行することが認定され、SAP ワークロードの ANF を使用した HANA DB の高可用性シナリオでのファイル システムのパフォーマンスが向上します

詳細については、Database Instance - DisableTCPTimestamps (「ANF を使用した HANA DB の高可用性シナリオでは、tcp_timestamps OS パラメーターを無効にします」) の記事を参照してください。

ANF を使用して HANA DB のファイル システムパフォーマンスを向上させるには、tcp_timestamps OS パラメーターを有効にします

sap note: 302436 に従って、tcp_timestamps パラメーターを有効にします。 tcp_timestamps の構成により、HANA DB を ANF で実行することが認定され、SAP ワークロードの ANF を使用した HANA DB のファイル システム パフォーマンスが向上します。

詳細については、Database Instance - EnableTCPTimestamps (「ANF を使用して HANA DB のファイル システムパフォーマンスを向上させるには、tcp_timestamps OS パラメーターを有効にします」) の記事を参照してください。

ANF を使用して HANA DB のファイル システムのパフォーマンスを向上させるには、TCP 受信バッファー サイズの自動チューニングを有効にします

パラメーター net.ipv4.tcp_moderate_rcvbuf を使用すると、TCP は受信バッファーの自動チューニングを実行して、バッファーのサイズを自動的に設定できます (完全なスループットのためにパスに必要なサイズと一致するように、tcp_rmem を超える値は指定されません。 SAP ノート: 302436 に従ってこのパラメーターを有効にすると、ファイル システムのパフォーマンスが向上します。

詳細については、Database Instance - EnableAutoTuning (「ANF を使用して HANA DB のファイル システムのパフォーマンスを向上させるには、TCP 受信バッファー サイズの自動チューニングを有効にします」) の記事を参照してください。

ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、net.ipv4.ip_local_port_range を最適化します

HANA は内部通信にかなりの数の接続を使用するため、この目的でできるだけ多くのクライアント ポートを使用することが理にかなっています。 最適な内部 HANA 通信を確保するために、SAP Note 2382421に従って OS パラメーター net.ipv4.ip_local_port_rangeパラメーターを設定します。

詳細については、Database Instance - IPV4LocalPortRange (「ANF を使用した HANA DB のファイル システムのパフォーマンスを向上させるには、net.ipv4.ip_local_port_range を最適化します」) の記事を参照してください。

ANF を使用して HANA DB のファイル システムのパフォーマンスを向上させるには、sunrpc.tcp_slot_table_entries を最適化します

SAP ワークロードの ANF を使用した HANA DB のファイル システムのパフォーマンス向上に関する推奨事項に従って、パラメーター sunrpc.tcp_slot_table_entries を 128 に設定します。

詳細については、Database Instance - TCPSlotTableEntries (「ANF を使用して HANA DB のファイル システムのパフォーマンスを向上させるには、sunrpc.tcp_slot_table_entries を最適化します」) の記事を参照してください。

HANA DB でハイ パフォーマンスを確保するには、/hana/data ボリューム用の LVM 内のすべてのディスクの種類を同じにするようにします

/hana/データ ボリュームで複数のディスクの型が選択されている場合、SAP ワークロードでの HANA DB のパフォーマンスが制限される可能性があります。 すべての HANA Data ボリューム ディスクが同じ型であり、SAP on Azure の推奨事項に従って構成されていることを確認します。

詳細については、「Database Instance - HanaDataDiskTypeSame (HANA DB でハイ パフォーマンスを確保するには、/hana/data ボリューム用の LVM 内のすべてのディスクの種類を同じにするようにします)」を参照してください。

SAP ワークロードでの HANA DB のパフォーマンスを向上させるには、/hana/data のストライプ サイズを 256 kb にする必要があります

LVM または mdadm を使用して、複数の Azure Premium ディスクにまたがるストライプ セットを構築する場合は、ストライプ サイズを定義する必要があります。 Azure では、最近の Linux バージョンの経験に基づいて、HANA DB のパフォーマンスを向上させるために、/hana/data ファイルシステムに 256 kb のストライプ サイズを使用することをお勧めします。

詳細については、「Database Instance - HanaDataStripeSize (SAP ワークロードでの HANA DB のパフォーマンスを向上させるには、/hana/data のストライプ サイズを 256 kb にする必要があります)」を参照してください。

ANF を使用して HANA DB のファイル システムパフォーマンスを向上させるには、パラメーター vm.swappiness を最適化します

SAP ワークロードの ANF を使用した HANA DB でのファイル システムのパフォーマンス向上に関する推奨事項に従って、OS パラメーター vm.swappiness を 10 に設定します。

詳細については、Database Instance - VmSwappiness (「ANF を使用して HANA DB のファイル システムパフォーマンスを向上させるには、パラメーター vm.swappiness を最適化します」) の記事を参照してください。

ANF を使用して HANA DB のファイル システムパフォーマンスを向上させるには、 net.ipv4.conf.all.rp_filterを無効にします

SAP ワークロードの ANF を使用した HANA DB でのファイル システムのパフォーマンス向上に関する推奨事項に従って、リバース パス フィルター linux OS パラメーター net.ipv4.conf.all.rp_filter を無効にします。

詳細については、Database Instance - DisableIPV4Conf (「ANF を使用して HANA DB のファイル システム パフォーマンスを向上させるには、net.ipv4.conf.all.rp_filter を無効にします」) の記事を参照してください。

Ultradisk を使用している場合、HANA DB のパフォーマンスを向上させるために、/hana/data ボリュームの IOPS は >=7000 にする必要があります

Ultradisk を使用する場合、SAP ワークロードでは、/hana/データ ボリューム内の IOPS が 7000 以上することをお勧めします。 DB のハイ パフォーマンスを確保するには、この要件に従って /hana/data ボリュームのディスクの型を選択します。

詳細については、「Database Instance - HanaDataIOPS (Ultradisk を使用している場合、HANA DB のパフォーマンスを向上させるために、/hana/data データ ボリュームの IOPS は >=7000 にする必要があります)」を参照してください。

ANF を使用して HANA DB のファイルシステムパフォーマンスを向上させるには、パラメーター tcp_max_slot_table_entries を最適化します

SAP ワークロードの ANF を使用した HANA DB でのファイル転送パフォーマンスを向上させるには、SAP ノート: 302436 に従って OS パラメーター tcp_max_slot_table_entries を 128 に設定します。

詳細については、Database Instance - OptimizeTCPMaxSlotTableEntries (「ANF を使用して HANA DB のファイルシステムパフォーマンスを向上させるには、パラメーター tcp_max_slot_table_entries を最適化します」) の記事を参照してください。

HANA DB のパフォーマンスを向上させるために、/hana/data ボリュームの読み取りパフォーマンスが >=400 MB/秒であることを確認します

Azure 上の SAP ワークロードでは、16 MB および 64 MB の I/O サイズの /hana/data に対して少なくとも 400 MB/秒の読み取りアクティビティをお勧めします。 DB のハイ パフォーマンスを確保し、SAP HANA の最小ストレージ要件を満たすために、この要件に従って /hana/data のディスクの型を選択します。

詳細については、Database Instance - HanaDataVolumePerformance (「HANA DB のパフォーマンスを向上させるために、/hana/data ボリュームの読み取りパフォーマンスが >=400 MB/秒であることを確認します」) の記事を参照してください。

HANA DB のパフォーマンスを向上させるために、/hana/log ボリュームの読み取りと書き込みパフォーマンスは >=250 MB/秒にする必要があります

Azure 上の SAP ワークロードでは、1 MB I/O サイズの /hana/ログ に対して少なくとも 250 MB/秒の読み取り書き込みアクティビティをお勧めします。 DB のハイ パフォーマンスを確保し、SAP HANA の最小ストレージ要件を満たすために、この要件に従って /hana/log ボリュームのディスクの型を選択します。

詳細については、「Database Instance - HanaLogReadWriteVolume (HANA DB のパフォーマンスを向上させるために、/hana/log ボリュームの読み取りと書き込みパフォーマンスは >=250 MB/秒にする必要があります)」を参照してください。

Ultradisk を使用している場合、HANA DB のパフォーマンスを向上させるために、/hana/log ボリュームの IOPS は >=2000 にする必要があります

Ultradisk を使用する場合、SAP ワークロードでは、/hana/log ボリューム内の IOPS が 2000 以上することをお勧めします。 DB のハイ パフォーマンスを確保するには、この要件に従って /hana/log ボリュームのディスクの型を選択します。

詳細については、「Database Instance - HanaLogIOPS (Ultradisk を使用している場合、HANA DB のパフォーマンスを向上させるために、/hana/log ボリュームの IOPS は >=2000 にする必要があります)」を参照してください。

HANA DB でハイ パフォーマンスを確保するには、/hana/log ボリューム用の LVM 内のすべてのディスクの種類を同じにするようにします

/hana/log ボリュームで複数のディスクの型が選択されている場合、SAP ワークロードでの HANA DB のパフォーマンスが制限される可能性があります。 すべての HANA Data ボリューム ディスクが同じ型であり、SAP on Azure の推奨事項に従って構成されていることを確認します。

詳細については、「Database Instance - HanaDiskLogVolumeSameType (HANA DB でハイ パフォーマンスを確保するには、/hana/log ボリューム用の LVM 内のすべてのディスクの種類を同じにするようにします)」を参照してください。

Premium ディスクで /hana/log ボリュームで書き込みアクセラレータを有効にして、HANA DB の書き込み待機時間を短縮する

Azure 書き込みアクセラレータは、Azure M シリーズ VM に提供される機能です。 Azure Premium Storage に対する書き込みの I/O 待機時間が向上します。 SAP HANA の場合、書き込みアクセラレータは /hana/log ボリュームに対してのみ使用する必要があります。

詳細については、Database Instance - WriteAcceleratorEnabled (「Premium ディスクで /hana/log ボリュームで書き込みアクセラレータを有効にして、HANA DB の書き込み待機時間を短縮する」) の記事を参照してください。

SAP ワークロードでの HANA DB のパフォーマンスを向上させるには、/hana/log のストライプ サイズを 64 kb にする必要があります

LVM または mdadm を使用して、複数の Azure Premium ディスクにまたがるストライプ セットを構築する場合は、ストライプ サイズを定義する必要があります。 I/O サイズを大きくして十分なスループットを得るために、Azure では、/hana/log ファイルシステムに 64 kb のストライプ サイズを使用して HANA DB のパフォーマンスを向上させることをお勧めします。

詳細については、「Database Instance - HanaLogStripeSize (SAP ワークロードでの HANA DB のパフォーマンスを向上させるには、/hana/log のストライプ サイズを 64 kb にする必要があります)」を参照してください。

セキュリティ

Attestation API のバージョンを更新する

このサブスクリプションのリソースからの API 呼び出しに、古いバージョンの Attestation API が使用されていることがわかりました。 最新バージョンの Attestation API に切り替えることをお勧めします。 最新バージョンの API を使用するように、既存のコードを更新する必要があります。 最新の API バージョンを使用すると、最新の機能とパフォーマンスの向上を享受できます。

構成証明プロバイダー - UpgradeAttestationAPI (Attestation API のバージョンを更新する) に関する詳細を確認してください。

Key Vault SDK バージョンを更新する

新しい Key Vault クライアント ライブラリは、キー、シークレット、証明書の SDK に分割されています。これらは推奨される Azure Identity ライブラリと統合され、すべての言語と環境にまたがるシームレスな認証が Key Vault に提供されています。 また、お客様から報告され、QA プロセスを通じて事前に特定されたイシューに対するいくつかのパフォーマンスの修正も含まれています。 古い Key Vault SDK を使用している可能性のある Azure Storage、Disk、またはその他の Azure サービスと Key Vault が統合されている場合、および現在のすべてのカスタム アプリケーションに .NET SDK 4.0 以降が使用されている場合は、推奨事項を無視してください。

Key Vault - UpgradeKeyVaultSDK (Key Vault SDK バージョンを更新する) に関する詳細を確認してください。

Key Vault SDK バージョンを更新する

新しい Key Vault クライアント ライブラリは、キー、シークレット、証明書の SDK に分割されています。これらは推奨される Azure Identity ライブラリと統合され、すべての言語と環境にまたがるシームレスな認証が Key Vault に提供されています。 また、お客様から報告され、QA プロセスを通じて事前に特定されたイシューに対するいくつかのパフォーマンスの修正も含まれています。

マネージド HSM サービス - UpgradeKeyVaultMHSMSDK (Key Vault SDK バージョンを更新する) に関する詳細を確認してください。

記憶域

256 MB 未満の BLOB に "Put Blob" を使用する

256 MB 未満 (2016-05-31 以前の REST バージョンを使用する要求では 64 MB) のブロック BLOB を書き込むときには、"Put Blob" を使用して 1 回の書き込み操作で完全にアップロードすることができます。 集計されたメトリックによると、お使いのストレージ アカウントの書き込み操作は最適化が可能です。

ストレージ アカウント - StorageCallPutBlob (256 MB 未満の BLOB に ""Put Blob"" を使用する) に関する詳細を確認してください。

Premium ファイル共有のプロビジョニング サイズを増やして要求の調整を回避する

ファイル共有に対する 1 秒あたりの I/O 操作 (IOPS) またはスループット制限に達すると、Premium ファイル共有への要求は調整されます。 要求が調整されないようにするには、Premium ファイル共有のサイズを増やします。

詳細については、「ストレージ アカウント - AzureStorageAdvisorAvoidThrottlingPremiumFiles(Premium ファイル共有のプロビジョニング サイズを増やして要求の調整を回避する)」を参照してください。

テーブルの列の統計を作成する

クエリのパフォーマンスに影響する可能性があるテーブルの統計の不足を検出しました。 クエリ オプティマイザーは、統計を使用してクエリ結果のカーディナリティまたは行数を推定して、高品質のクエリ プランを作成できるようにします。

SQL データ ウェアハウス - CreateTableStatisticsSqlDW (テーブルの列の統計を作成する) に関する詳細を確認してください。

クエリのパフォーマンスを向上させるためにデータ スキューを削除する

分散データ スキューが 15% を超えていることが検出されました。これにより、高コストのパフォーマンス ボトルネックが発生する可能性があります。

SQL データ ウェアハウス - DataSkewSqlDW (クエリのパフォーマンスを向上させるためにデータ スキューを削除する) に関する詳細を確認してください。

テーブルの列の統計を更新する

クエリのパフォーマンスに影響する可能性がある最新のテーブルの統計の不足を検出しました。 クエリ オプティマイザーは、最新の統計を使用してクエリ結果のカーディナリティまたは行数を推定して、高品質のクエリ プランを作成できるようにします。

SQL データ ウェアハウス - UpdateTableStatisticsSqlDW (テーブルの列の統計を更新する) に関する詳細を確認してください。

SQL Data Warehouse でのキャッシュ使用率を最適化するためにスケールアップする

キャッシュ使用率が高く、ヒット率が低いことが検出されました。これは、ワークロードのパフォーマンスに影響を与える可能性のあるキャッシュ削除率が高いことを示しています。

SQL データ ウェアハウス - SqlDwIncreaseCacheCapacity (SQL Data Warehouse でのキャッシュ使用率を最適化するためにスケールアップする) に関する詳細を確認してください。

SQL Data Warehouse で tempdb 競合を削減するためにリソース クラスをスケールアップまたは更新する

ワークロードのパフォーマンスに影響を与える可能性がある、利用率の高い tempdb を検出しました。

SQL データ ウェアハウス - SqlDwReduceTempdbContention (SQL Data Warehouse で tempdb 競合を削減するためにリソース クラスをスケールアップまたは更新する) に関する詳細を確認してください。

SQL Data Warehouse でテーブルをレプリケートされたテーブルに変換する

レプリケートされたテーブルを使用することでメリットが得られることがわかりました。 レプリケートされたテーブルによって、コストのかかるデータ移動操作が回避され、ワークロードのパフォーマンスが大幅に向上します。

SQL データ ウェアハウス - SqlDwReplicateTable (SQL Data Warehouse でテーブルをレプリケートされたテーブルに変換する) に関する詳細を確認してください。

ストレージ アカウントにステージングされたファイルを分割して読み込みパフォーマンスを向上させる

ストレージ アカウントにステージングされた圧縮ファイルを分割することで、読み込みスループットを向上できることがわかりました。 読み込みの並列処理を最大化するには、一般的に、圧縮ファイルを 60 以上に分割するのが適切です。

SQL データ ウェアハウス - FileSplittingGuidance (ストレージ アカウントにステージングされたファイルを分割して読み込みパフォーマンスを向上させる) に関する詳細を確認してください。

読み込み時のバッチ サイズを増加して、読み込みスループット、データ圧縮、クエリ パフォーマンスを最大化する

データベースに読み込む際にバッチ サイズを増加することで、読み込みのパフォーマンスとスループットを向上できることがわかりました。 COPY ステートメントの使用を検討してください。 COPY ステートメントを使用できない場合は、SQLBulkCopy API や BCP などの読み込みユーティリティを使用する際にバッチ サイズを増加することを検討してください。一般的には、10 万行から 100 万行のバッチ サイズが適切です。

SQL データ ウェアハウス - LoadBatchSizeGuidance (読み込み時のバッチ サイズを増加して、読み込みスループット、データ圧縮、クエリ パフォーマンスを最大化する) に関する詳細を確認してください。

読み込み時の待機時間を最小限に抑えるために、ストレージ アカウントを同じリージョン内に配置します

SQL プールとは異なるリージョンから読み込んでいることが検出されました。 データを読み込むときの待機時間を最小限に抑えるには、SQL プールと同じリージョン内にあるストレージ アカウントから読み込むことを検討してください。

SQL データ ウェアハウス - ColocateStorageAccount (読み込み時の待機時間を最小限に抑えるために、ストレージ アカウントを同じリージョン内に配置します) に関する詳細を確認してください。

信頼性とパフォーマンスを向上させるために、ストレージ クライアント ライブラリを最新バージョンにアップグレードする

ストレージ クライアント ライブラリ/SDK の最新バージョンには、お客様から報告された問題に対する修正と、QA プロセスを通じて事前に明らかになった問題の修正が含まれています。 また、最新バージョンには、Azure Storage の使用に関する全体的なエクスペリエンスを向上させる新機能に加えて、信頼性とパフォーマンスの最適化も含まれています。

詳細については、「ストレージ アカウント - UpdateStorageSDK (信頼性とパフォーマンスを向上させるために、ストレージ クライアント ライブラリを最新バージョンにアップグレードする)」を参照してください。

信頼性とパフォーマンスを向上させるために、ストレージ クライアント ライブラリを最新バージョンにアップグレードする

ストレージ クライアント ライブラリ/SDK の最新バージョンには、お客様から報告された問題に対する修正と、QA プロセスを通じて事前に明らかになった問題の修正が含まれています。 また、最新バージョンには、Azure Storage の使用に関する全体的なエクスペリエンスを向上させる新機能に加えて、信頼性とパフォーマンスの最適化も含まれています。

ストレージ アカウント - UpdateStorageDataMovementSDK (信頼性とパフォーマンスを向上させるために、ストレージ クライアント ライブラリを最新バージョンにアップグレードする) に関する詳細を確認してください。

パフォーマンスの一貫性と向上を実現するために Standard SSD ディスクにアップグレードする

Standard HDD マネージド ディスク上で IaaS 仮想マシンのワークロードを実行しているため、すべての Azure VM の種類で Standard SSD ディスク オプションを使用できるようになりました。 Standard SSD ディスクは、一貫したパフォーマンスを必要とするエンタープライズ ワークロード向けに最適化された、コスト効果に優れたストレージ オプションです。 待機時間、信頼性、および可用性を向上させるために、ディスク構成を今すぐアップグレードしてください。 アップグレードには VM の再起動が必要です。これには 3 分から 5 分かかります。

ストレージ アカウント - StandardSSDForNonPremVM (パフォーマンスの一貫性と向上を実現するために Standard SSD ディスクにアップグレードする) に関する詳細を確認してください。

Premium パフォーマンス ブロック BLOB ストレージを使用する

1 つ以上のストレージ アカウントで、格納されているブロック BLOB データの GB あたりのトランザクション レートが高くなっています。 高速なストレージ応答時間や高いトランザクション レートを必要とするワークロードには、Standard パフォーマンス ストレージではなく、Premium パフォーマンス ブロック BLOB ストレージを使用します。これにより、ストレージ コストを節約できる可能性もあります。

ストレージ アカウント - PremiumBlobStorageAccount (Premium パフォーマンス ブロック BLOB ストレージを使用する) に関する詳細を確認してください。

パフォーマンスを向上させるために、アンマネージド ディスクを Standard HDD から Premium SSD に変換する

お使いのアンマネージド HDD ディスクがパフォーマンス目標に近づいていることがわかりました。 Azure Premium SSD は、IO 集中型ワークロードがある仮想マシン向けに、高パフォーマンスで待ち時間の少ないディスク サポートを提供します。 Standard HDD ディスクを Premium SSD ディスクにアップグレードして、ディスクのパフォーマンスを向上させてください。 アップグレードには VM の再起動が必要です。これには 3 分から 5 分かかります。

ストレージ アカウント - UMDHDDtoPremiumForPerformance (パフォーマンスを向上させるために、アンマネージド ディスクを Standard HDD から Premium SSD に変換する) に関する詳細を確認してください。

サーバー グループにデータを分散させてノード間でワークロードを分散させる

このサーバー グループにはデータが分散されていないようですが、コーディネーター上に残っています。 Hyperscale (Citus) の利点を最大限に活用するには、サーバー グループ内のワーカー ノードにデータを分散します。

Hyperscale (Citus) サーバー グループ - OrcasPostgreSqlCitusDistributeData (サーバー グループにデータを分散させてノード間でワークロードを分散させる) に関する詳細を確認してください。

Hyperscale (Citus) サーバー グループでデータのバランスを再調整し、ワーカー ノード間でより均等になるようにワークロードを分散させる

この Hyperscale (Citus) サーバー グループのデータは、ワーカー ノード間に適切に分散されていないようです。 Hyperscale (Citus) サーバー グループの各ワーカー ノードを効率的に使用するには、サーバー グループのデータのバランスを再調整してください。

Hyperscale (Citus) サーバー グループ - OrcasPostgreSqlCitusRebalanceData (Hyperscale (Citus) サーバー グループでデータのバランスを再調整し、ワーカー ノード間でより均等になるようにワークロードを分散させる) に関する詳細を確認してください。

仮想デスクトップ インフラストラクチャ

ユーザーの場所の近くに VM をデプロイすることにより、ユーザー エクスペリエンスと接続性を向上させます

お使いの VM は、ユーザーが Azure Virtual Desktop と接続している場所とは異なる、または離れたリージョンにあると判断しました。これによって、接続応答時間が長くなり、全体的なユーザー エクスペリエンスに影響を与える可能性があります。 ホスト プールの VM を作成するときは、ユーザーに近いリージョンを使用してみてください。 近接していることで、Azure Virtual Desktop サービスに対する満足度を維持し、エクスペリエンスの品質を全体的に向上させることができます。

ホスト プール - RegionProximityHostPools (ユーザーの場所の近くに VM をデプロイすることにより、ユーザー エクスペリエンスと接続性を向上させる) に関する詳細を確認してください。

VM のパフォーマンスを向上させるために深さ優先の負荷分散ホスト プールの最大セッション数を変更する

深さ優先の負荷分散では、最大セッション数を使用して、1 つのセッション ホストで同時セッションを持つことができるユーザーの最大数が決定されます。 最大セッション数が高すぎる場合、すべてのユーザー セッションは同じセッション ホストに送られ、これにより、パフォーマンスと信頼性の問題が発生する可能性があります。 そのため、ホスト プールを深さ優先で負荷分散するように設定する場合は、VM のデプロイと容量の構成に応じて、適切な最大セッション数も設定する必要があります。 これを解決するには、ホスト プールのプロパティを開き、[Max session limit](最大セッション数) 設定の横にある値を変更します。

ホスト プール - ChangeMaxSessionLimitForDepthFirstHostPool (VM のパフォーマンスを向上させるために深さ優先の負荷分散ホスト プールの最大セッション数を変更する) に関する詳細を確認してください。

Web

パフォーマンスを向上させるために App Service プランを PremiumV2 に移行する

お使いのアプリでは、過去 3 日間に 1 日あたり 1,000 を超える要求が処理されています。 アプリは、Premium V2 App Service レベルで使用できるハイ パフォーマンスのインフラストラクチャの恩恵を受けることができます。 Premium V2 レベルは、前のインスタンスと比較した場合に、より高速なプロセッサ、SSD ストレージ、および 2 倍のメモリ対コア比を備えた Dv2 シリーズの VM を特徴としています。 Premium V2 へのアップグレードの詳細については、Microsoft のドキュメントを参照してください。

App Service - AppServiceMoveToPremiumV2 (パフォーマンスを向上させるために App Service プランを PremiumV2 に移行する) に関する詳細を確認してください。

App Service リソースからの送信接続を確認する

アプリで開かれている TCP/IP ソケット接続が多すぎます。 一時的な TCP/IP ポート接続の制限を超えると、アプリで予期しない接続の問題が発生する可能性があります。

App Service - AppServiceOutboundConnections (App Service リソースからの送信接続を確認する) に関する詳細を確認してください。

次のステップ

パフォーマンス効率 - Microsoft Azure Well-Architected フレームワークに関する詳細を確認する