ApsaraDB RDS:ApsaraDB RDS for SQL Server インスタンスでの高 I/O 問題のトラブルシューティング

I/O スループットの制限

• プレミアムローカル SSD を使用する RDS インスタンス

  プレミアムローカル SSD を使用する RDS インスタンスは、これらのインスタンスがデプロイされている物理ホストのプレミアムローカル SSD を共有します。RDS インスタンスあたりの最大 IOPS は制限されていますが、RDS インスタンスあたりの I/O スループットは制限されていません。そのため、RDS インスタンスの最大 I/O スループットは 1 秒あたり 1 GB を超える可能性があります。ただし、これらの RDS インスタンスは I/O リソースを競合する可能性があります。I/O リソースの排他的な割り当てが必要な場合は、専用ホストインスタンスファミリーを選択することをお勧めします。詳細については、「プライマリインスタンスタイプ一覧」をご参照ください。

• クラウドディスクを使用する RDS インスタンス

  RDS インスタンスに接続されているクラウドディスクは、そのインスタンス専用です。そのため、各インスタンスには I/O リソースが排他的に割り当てられます。クラウドディスクを使用する RDS インスタンスの最大 I/O スループットは、次の要因によって異なります。

  • インスタンスの計算リソース: クラウドディスクを使用する RDS for SQL Server インスタンスの計算リソースは、Elastic Compute Service（ECS）g6 インスタンスファミリーの仕様に基づいて定義されます。

  • インスタンスのストレージタイプとストレージ容量: RDS インスタンスは、標準 SSD と ESSDをサポートしています。I/O スループットは、ストレージタイプとストレージ容量によって異なります。

RDS インスタンスの I/O スループットを表示する

1. [インスタンス] ページに移動します。上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。次に、RDS インスタンスを見つけて、インスタンスの ID をクリックします。

2. 左側のナビゲーションウィンドウで、自律型サービス (CloudDBA) > 性能を最適化する を選択します。表示されるページで、パフォーマンスインサイト タブをクリックします。

3. タブの右上隅にある [カスタムメトリック] をクリックします。表示されるダイアログボックスで、[I/O スループット] を選択し、[OK] をクリックします。

   説明

   [I/O スループット] を選択すると、次のメトリックが選択されます。

   • IO_Throughput_Read_Kb: ディスクの読み取り操作の 1 秒あたりの I/O スループット

   • IO_Throughput_Write_kb: ディスクの書き込み操作の 1 秒あたりの I/O スループット

   • IO_Throughput_Total_Kb: ディスクの読み取りおよび書き込み操作の 1 秒あたりの合計 I/O スループット

   

RDS インスタンスの I/O スループットを分析および最適化する

RDS インスタンスの I/O 負荷には、データファイルの読み取り操作と、トランザクションログファイルの読み取りおよび書き込み操作という 2 つの主要な部分があります。データファイルの読み取り操作には、クエリとバックアップ中のデータページの読み取り操作が含まれます。トランザクションログファイルの場合、読み取り操作の大部分はバックアップから派生し、書き込み操作はバックアップ以外の関連シナリオから派生します。

RDS インスタンスの I/O スループットが高い場合は、[カスタムメトリック] をクリックします。表示されるダイアログボックスで、次のメトリックを選択して、I/O スループットの増加の原因となっている負荷のタイプを特定できます。

データページの読み取り操作によって発生する高 I/O スループットのトラブルシューティング

データページの読み取り操作によって発生する高 I/O スループットの問題は、ApsaraDB RDS for SQL Server で最も一般的な高 I/O スループットの問題の 1 つです。ほとんどの場合、この問題はキャッシュサイズが不十分な場合に発生します。RDS インスタンスのキャッシュサイズが不十分な場合、クエリによって要求される多数のデータページがキャッシュにヒットしません。その結果、ApsaraDB RDS はこれらのデータページをディスクから読み取る必要があります。

Page Life Expectancy（PLE）は、キャッシュのパフォーマンスを診断するために使用される一般的なメトリックです。このメトリックは、キャッシュされた各データページがメモリに保持される平均時間を示します。時間は秒単位で測定されます。時間が短いほど、キャッシュへの負荷が高いことを示します。

通常の場合、PLE メトリックのしきい値を 300 秒以上の値に設定することをお勧めします。メモリ仕様が高いほど、推奨されるしきい値が高くなります。次の式を使用して、推奨されるしきい値を計算できます。

推奨しきい値 = (バッファープールのメモリサイズ/4) × 300

たとえば、RDS インスタンスが 16 GB のメモリを提供する場合、バッファープールに割り当てることができるメモリの量は 12 GB を超えることはできません。この場合、次の計算に基づいてしきい値を 900 秒に設定することをお勧めします: (12/4) × 300 = 900

高 I/O スループットの問題がデータページの読み取り操作によって発生している場合は、RDS インスタンスのメモリ仕様をアップグレードすることをお勧めします。ディスクのパフォーマンスレベル（PL）をアップグレードすることはお勧めしません。

また、RDS インスタンスの読み取り負荷を軽減するために、データページの総数を減らすこともできます。たとえば、履歴データファイルをアーカイブまたは削除したり、テーブルのデータ圧縮機能を有効にしたり、価値の低いインデックスを削除したり、インデックスをデフラグしたりできます。

データページとトランザクションログファイルの書き込み操作によって発生する高 I/O スループットのトラブルシューティング

自律型サービスを使用して、高 I/O スループットを示す期間中にデータ操作言語（DML）またはデータ定義言語（DDL）操作が頻繁に実行されているかどうかを確認できます。サポートされている DML 操作には、INSERT、DELETE、UPDATE、MERGE が含まれます。サポートされている DDL 操作には、CREATE INDEX と ALTER INDEX が含まれます。

• DML 操作によって発生する高 I/O スループット

  これらの DML 操作がルーチンワークロードであるかどうかを確認します。これらの DML 操作がルーチンワークロードでない場合は、オフピーク時にこれらの DML 操作を実行することをお勧めします。たとえば、一時的なデータ処理操作やアーカイブ操作をオフピーク時に実行できます。これらの DML 操作がルーチンワークロードである場合は、ディスクの PL をアップグレードすることをお勧めします。たとえば、ESSD の PL を PL1 から PL2 にアップグレードできます。

  また、インデックス構造を最適化し、不要になった非クラスター化インデックスを削除することもお勧めします。

• DDL 操作によって発生する高 I/O スループット

  ほとんどの場合、DDL 操作はメンテナンスワークロードまたは一時的なワークロードです。 DDL 操作はオフピーク時に実行することをお勧めします。

  また、インデックスの作成や再構築などの操作を実行する場合は、使用する SQL 文で最大並列度（MAXDOP）を指定することをお勧めします。これにより、SQL 文の実行中のピーク I/O スループットが軽減されます。ただし、これにより、DDL 操作に必要な時間が長くなります。

バックアップによって発生する高 I/O スループットのトラブルシューティング

ApsaraDB RDS for SQL Server は、プライマリ RDS インスタンスでのみバックアップをサポートしています。これにより、プライマリ RDS インスタンスの I/O スループットが増加します。すべてのタイプのバックアップの中で、完全バックアップは I/O スループットへの影響が最も大きく、ログバックアップは I/O スループットへの影響が最も小さくなります。

バックアップは、データのセキュリティと信頼性を確保するために重要です。ワークロードへのバックアップの影響を軽減するために、適切なバックアップ設定を指定することをお勧めします。詳細については、「ApsaraDB RDS for SQL Server インスタンスをバックアップする」をご参照ください。

ApsaraDB RDS コンソールにログインし、[バックアップと復元] ページに移動できます。このページでは、各データバックアップに必要な時間を表示できます。次に、バックアップ時間をオフピーク時に設定し、適切なバックアップサイクルを指定できます。

• たとえば、完全バックアップに約 6 時間かかり、ビジネスのピーク時間は毎日 9:00 から 21:00 までです。また、バックグラウンドシステムは、当日 22:00 から翌日 1:00 までデータ処理タスクを実行します。この場合、バックアップ時間を 1:00 から 2:00 に設定できます。こうすることで、各完全バックアップは 8:00 までに完了できます。また、バックアップサイクルを毎週に設定することもできます。これにより、復元プロセスが迅速になります。

• たとえば、完全バックアップに約 15 時間かかり、平日のすべてのバックアップによってワークロードが中断されます。バックアップサイクルを土曜日と日曜日に設定することをお勧めします。ただし、特定の時点にデータを復元する場合、復元プロセスに時間がかかる場合があります。

バックアップ設定を調整することでワークロードと完全バックアップの競合を防ぐことができない場合は、ディスクの PL をアップグレードするか、データを分割することをお勧めします。データ分割により、個々の RDS インスタンスのデータ量が削減されます。また、データ分割により、各完全バックアップに必要な時間も短縮されます。