このトピックでは、ApsaraDB RDS for SQL Serverインスタンスの高I/O問題のトラブルシューティング方法について説明します。 高いI/Oはクエリのパフォーマンスに影響します。
背景情報
I/Oパフォーマンスは、IOPSとI/Oスループットの2つの主な要因によって異なります。 ほとんどの場合、IOPSはパフォーマンスのボトルネックの原因になる可能性は低いです。 ただし、指定された上限に達すると、I/Oスループットがパフォーマンスのボトルネックになる可能性があります。
I/Oスループットの制限
ローカルディスク搭載RDSインスタンス
ローカルディスクを搭載したRDSインスタンスは、これらのインスタンスがデプロイされている物理ホストのローカルディスクを共有します。 RDSインスタンスあたりの最大IOPSは制限されますが、RDSインスタンスあたりのI/Oスループットは制限されません。 したがって、RDSインスタンスの最大I/Oスループットは1秒あたり1 GBを超える可能性があります。 ただし、これらのRDSインスタンスはI/Oリソースを競合する可能性があります。 I/Oリソースの排他的な割り当てが必要な場合は、専用ホストインスタンスファミリーを選択することを推奨します。 詳細については、「プライマリApsaraDB RDSインスタンスタイプ」をご参照ください。
クラウドディスクを搭載したRDSインスタンス
クラウドディスクを搭載した各RDSインスタンスには、専用の標準SSDまたは拡張SSD (ESSD) が搭載されています。 したがって、クラウドディスクを搭載した各RDSインスタンスには、I/Oリソースが排他的に割り当てられます。 クラウドディスクを搭載したRDSインスタンスの最大I/Oスループットは、次の要因によって異なります。
RDSインスタンスのコンピューティング仕様。 コンピューティング仕様は、Elastic Compute Service (ECS) g6インスタンスファミリーの仕様に基づいています。 詳細については、「インスタンスファミリーの概要」をご参照ください。
RDSインスタンスのストレージタイプとストレージ容量。 詳細については、「EBSパフォーマンス」をご参照ください。
RDSインスタンスのI/Oスループットの表示
前提条件
RDSインスタンスは、クラウドディスクでSQL Server 2008 R2を実行しません。
- [インスタンス] ページに移動します。 上部のナビゲーションバーで、RDSインスタンスが存在するリージョンを選択します。 次に、RDSインスタンスを見つけ、インスタンスのIDをクリックします。
左側のナビゲーションウィンドウで、自律型サービス (CloudDBA) > 性能を最適化する を選択します。 表示されるページで、パフォーマンスインサイト タブをクリックします。
タブの右上隅にある [カスタムメトリック] をクリックします。 表示されるダイアログボックスで、[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タイプ | 説明 |
ページ_読み取り | 読み取り権限 | 1秒あたりにデータファイルから読み取られるデータページの数。 これらのデータページはキャッシュでヒットできません。 |
ページ_書き込み | Write | 1秒あたりにデータファイルに書き込まれるデータページの数。 |
Log_Bytes_Flushed /秒 | Write | トランザクションログファイルに書き込まれる1秒あたりのバイト数。 |
Backup_Restore_Throughput/sec | 読み取り権限 | 1秒あたりにデータファイルとトランザクションログファイルから読み書きされるバイト数。 このメトリックは、バックアップおよび復元操作に有効です。 |
データページあたりのサイズは8 KBです。
次の図は分析ケースを示しています。
全体的なI/Oスループット統計は、読み取り負荷が書き込み負荷よりも高いことを示しています。 08:00から22:00まで、I/Oスループットは比較的安定しています。 01:00から03:00まで、および22:00から24:00まで、I/Oスループットはピーク値を示します。 これらのピーク時のI/Oスループット統計をさらに分析するには、より多くのパフォーマンスデータを取得する必要があります。
データページのI/Oスループット統計は、I/Oスループットが、データページ上の読み取り操作のために約01:00に突然増加することを示す。 ピーク読み出し速度は、毎秒約50,000データページに達し、これは毎秒約400 MBに等しい。
データページ、ログ、およびバックアップのI/Oスループット統計では、02:00から03:00までの期間のI/Oスループットピークが4つのソースから得られていることが示されています。 これらのソースは、データページに対する読み取り操作、データページに対する書き込み操作、トランザクションログファイルに対する書き込み操作、およびログバックアップです。 I/Oスループットのピークは、データページの読み取り操作と書き込み操作の両方で毎秒約40 MB、トランザクションログファイルの書き込み操作で毎秒約30 MB、ログバックアップで毎秒約50 MBです。 累積I/Oスループットは、毎秒約150 MBでピークに達する。
データページとログのI/Oスループット統計では、08:00から22:00までの期間中のI/O負荷は、3つのソースからそれらの比率に基づいて降順に導出されることが示されます。 これらのソースは、データページに対する読み取り操作、データページに対する書き込み操作、およびトランザクションログファイルに対する書き込み操作です。 I/Oスループットは、データページの読み取り操作で80 MB〜100 MB /秒、データページの書き込み操作で約30 MB /秒、トランザクションログファイルの書き込み操作で約5 MB /秒に達します。
バックアップのI/Oスループット統計によると、22:00から24:00までの期間のI/Oスループットピークは、バックアップのみから得られます。 バックアップのI/Oスループットは、220 MB /秒を超えるままです。
データページの読み取り操作による高いI/Oスループットのトラブルシューティング
データページの読み取り操作によって発生する高I/Oスループットの問題は、ApsaraDB RDS for SQL Serverで最も一般的な高I/Oスループットの問題の1つです。 ほとんどの場合、この問題はキャッシュサイズが不十分な場合に発生します。 RDSインスタンスのキャッシュサイズが不十分な場合、クエリによって要求された多数のデータページをキャッシュでヒットすることはできません。 その結果、ApsaraDB RDSはこれらのデータページをディスクから読み取る必要があります。
ページ有効期限 (PLE) は、キャッシュのパフォーマンスを診断するために使用される一般的なメトリックです。 このメトリックは、キャッシュされた各データページがメモリに保持される平均時間を示します。 時間は秒で測定される。 より短い期間は、キャッシュに対するより高い圧力を示す。
通常、PLEメトリックのしきい値を300秒以上に設定することを推奨します。 より高いメモリ仕様は、より大きな推奨閾値を示す。 次の式を使用して、推奨しきい値を計算できます。
推奨しきい値=(バッファプールのメモリサイズ /4) × 300
たとえば、RDSインスタンスが16 GBのメモリを提供している場合、バッファプールに割り当てることができるメモリの量は12 GBを超えることはできません。 この場合、次の計算に基づいてしきい値を900秒に設定することを推奨します。(12/4) × 300 = 900。
詳細については、「SQL Serverのページ有効期限 (PLE) 」をご参照ください。
データページの読み取り操作が原因で高い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時間かかり、ビジネスのピーク時間は毎日09:00から21:00に始まります。 さらに、バックグラウンドシステムは、当日の22:00から翌日の01:00までデータ処理タスクを実行します。 この場合、バックアップ時間を01:00〜02:00に設定できます。 このようにして、各完全バックアップは08:00までに完了できます。 バックアップサイクルを曜日ごとに設定することもできます。 これにより、復元プロセスが促進されます。
たとえば、完全バックアップには約15時間かかり、平日のバックアップごとにワークロードが中断されます。 バックアップサイクルを土曜日と日曜日に設定することを推奨します。 ただし、特定の時点にデータを復元する場合は、復元プロセスに時間がかかることがあります。
バックアップ設定を調整してワークロードと完全バックアップの競合を防ぐことができない場合は、ディスクのPLをアップグレードするか、データを分割することを推奨します。 データ分割により、個々のRDSインスタンスのデータ量が削減されます。 データ分割により、各完全バックアップに必要な時間も短縮されます。