RDS for SQL Server インスタンスの空きメモリが少ない場合のトラブルシューティング方法を教えてください。
Amazon Relational Database (Amazon RDS) for SQL Server インスタンスで空きメモリが不足しているため、トラブルシューティングしたいです。
解決策
インスタンスのメモリ使用量を監視する
Amazon CloudWatch メトリクスまたは拡張モニタリングを使用すると、メモリ使用量を監視できます。
CloudWatch メトリクスを使用する
メモリ不足を識別するには、Amazon Aurora と RDS コンソールを使用して CloudWatch メトリクス FreeableMemory を監視します。
使用可能なメモリが少ないときに、ワークロードの増加を識別するには、次のメトリクスを監視します。
- DatabaseConnections
- CPUUtilization
- ReadIOPS
- ReadThroughput
- WriteIOPS
- WriteThroughput
上記のメトリクスに関する詳細は、「Amazon RDS の Amazon CloudWatch インスタンスレベルのメトリクス」を参照してください。
拡張モニタリングを有効化する
Microsoft SQL Server のオペレーティングシステム (OS) メトリクスを監視するには、拡張モニタリングを使用します。拡張モニタリングを有効にすると、メトリクスの収集間隔を 1 秒、5 秒、10 秒、15 秒、30 秒、または 60 秒に設定できます。デフォルトは 60 秒の精度ですが、1 秒または 5 秒に設定することをお勧めします。
拡張モニタリングを使用して CloudWatch アラームを作成し、Amazon RDS for SQL Server DB インスタンスのメモリ使用量を監視することもできます。
Amazon RDS インスタンスが使用するメモリを制限する
インスタンスの max_server_memory 値を判断し、max_server_memory 値をシステム全体のメモリ圧迫が起こらない値に設定します。
max_server_memory 値を判断する
次の計算式でインスタンス用の max_server_memory 値を判断します。
max_server_memory = total_RAM - (OS 用の 1 GB + memory_basis_amount_of_RAM_on_the_server)
total_RAM は、インスタンスタイプのメモリの合計と同じです。
memory_basis_amount_of_RAM_on_the_server は、次の方法で判断します。
-
サーバーの RAM が 4 GB から 16 GB の間である場合は、RAM の 4 GB あたり 1 GB を確保します。例えば、16 GB の RAM を搭載したサーバーの場合は、4 GB のままにしておきます。
-
サーバーの RAM が 16 GB を超える場合は、16 GB までは、4 GB の RAM につき 1 GB を確保します。RAM の 16 GB を超えた分については、8 GB あたり 1 GB を確保します。
例えば、サーバーに 64 GB の RAM が搭載されている場合、max_server_memory の計算は次のようになります。
- OS 用の 1 GB
- 16 GB までの RAM: 16/4 = 4 GB
- メモリの 16 GB を超えた分: (64-16)/8 = 6 GB
- (OS 用の 1 GB + memory_basis_amount_of_RAM_on_the_server) = 1 + 4 + 6 = 11 GB
- max_server_memory: 64 - 11 = 53 GB
max_server_memory を設定する
max_server_memory を変更するには、カスタムパラメータグループを使用して値を設定します。[最大サーバーメモリ (MB)] に max_server_memory で取得した値を入力します。max_server_memory は動的パラメータなので、変更を有効にするために再起動する必要はありません。
注: max_server_memory を設定した後は、FreeableMemory を継続的に監視して、割り当てられたメモリを増やすか減らすかを判断する必要があります。
DB インスタンスで SSIS、SSAS、または SSRS オプションを使用しているかどうかを確認する
RDS オプショングループを確認し、DB インスタンスで SQL Server 統合サービス (SSIS)、SQL Server 分析サービス (SSAS)、または SQL Server レポートサービス (SSRS) のオプションを使用しているかを判断します。これらのオプションが使用するメモリは max_server_memory 設定の範囲外にあるため、インスタンスのメモリ負荷が増加します。これらのオプションを使用しない場合は、オプショングループを変更して削除してください。
注: インスタンスで SSIS、SSAS、または SSRS を使用している場合は、max_server_memory を調整し、そのオプションに対応する必要があります。
例えば、SSRS を使用している場合は、SSRS の [最大メモリ] 値を DB インスタンスの合計メモリの 10% に設定します。例えば、64 GiB のメモリを搭載したインスタンスの 10% は約 6.4 GiB です。したがって、max_server_memory 値を約 46 GiB (64 - 11 - 6.4 = 46 GiB) に調整します。
データベース接続数を確認する
インスタンスへの各データベース接続では、ワーカースレッド用のバッファープールの外部にある程度のメモリを割り当てる必要があります。その結果、DatabaseConnections の急増により、解放できるメモリが減少する可能性があります。
Performance Insights で DB インスタンスを監視する
Performance Insights を使用すると、データベースのパフォーマンスを分析し、インスタンスの速度を低下させる可能性があるボトルネックを特定できます。Performance Insights ダッシュボードを使用して、データベースの負荷、待機、クエリ、ホスト、およびユーザーを監視します。
DB インスタンスの定期的なメンテナンスを実施する
定期的にインデックスをメンテナンスし、統計情報を最新の状態に保ちます。インデックスの断片化が進むと、I/O アクティビティが増加し、メモリ使用量が増える可能性があります。また、統計情報が古くなっていると、カーディナリティの推定が不正確になり、データベースが最適なクエリプランを選択できなくなる可能性があります。詳細については、Microsoft のウェブサイトで「Optimize index maintenance to improve query performance and reduce resource consumption」(インデックスのメンテナンスを最適化してクエリのパフォーマンスを向上させ、リソース消費を削減する) を参照してください。さらに、Microsoft のウェブサイトで「UPDATE STATISTICS (Transact-SQL)」を参照してください。
注: インデックスと統計のメンテナンスは、ピーク時以外またはメンテナンス時間帯に実施することをお勧めします。
PLE と BCHR を監視する
メモリ負荷を特定するには、Page Life Expectancy (PLE) および Buffer Cache Hit Ratio (BCHR) を監視します。パフォーマンスを最適化するには、PLE と BCHR の値が可能な限り高くなっていることを確認してください。PLE と BCHR の値が一定期間にわたり、一貫して低い場合は、データにアクセスするクエリを調整するか、インスタンスクラスを増やしてメモリを増やしてください。
Performance Insights を使用してメトリクスを監視するには、次の手順を実行します。
- Aurora と RDS コンソールを開きます。
- ナビゲーションペインで [Performance Insights] をクリックします。
- [DB インスタンスの絞り込み] 検索フィールドを使用して、監視するインスタンスを選択します。
- メトリクスを確認する時間範囲を設定します。
- メトリクスダッシュボードで [カスタムダッシュボード - SQL Server データベース] をクリックし、[最初のウィジェットを追加] を選択します。
- [名前、カテゴリ、または ID でメトリクスをフィルタリングする] 検索フィールドで Page Life Expectancy を検索して選択します。
- [ウィジェットを追加] をクリックします。
- 手順 6 と 7 を繰り返して、カスタムダッシュボードの Buffer Cache Hit Ratio を選択します。
PLE と BCHR の詳細については、Microsoft のウェブサイトで「Buffer Manager パフォーマンスオブジェクト」を参照してください。
インスタンスにメモリ負荷がかかり、PLE と BCHR が低下すると、PAGEIOLATCH の待機時間が長くなります。Microsoft SQL Server は、ページがディスクからメモリに読み込まれるのを待っています。メモリ不足が原因でクエリのメモリ要求が失敗すると、RESOURCE_SEMAPHORE の待機が発生することもあります。データページがメモリにキャッシュされる期間が不十分なため、CPU 使用率が増加します。この場合、Microsoft SQL Server はディスク上のデータに繰り返しアクセスする必要があります。
ワークロードに適したインスタンスサイズを選択する
インスタンスのメモリ量は、インスタンスタイプによって異なります。DB インスタンスにワークロードに十分なリソースを持たせるには、十分なリソースを持つインスタンスクラスを選択してください。インスタンスのリソースが不足していると、パフォーマンスの問題が発生します。インスタンスが過度に大きい場合は、リソースの浪費につながります。
例えば、db.r5.8xlarge インスタンスクラスでは 32 個の仮想 CPU と 256 GiB のメモリを使用できます。db.r5.8xlarge を使用して Amazon RDS インスタンスをプロビジョニングすると、次のリソースがインスタンスクラスの 256 GIB のメモリをすべて共有します。
- オペレーティングシステム
- Amazon RDS プロセス
- データベースエンジン
- ワーカースレッド
- SSIS、SSAS、SSRS などの Business Intelligence スイートアプリケーション。
Microsoft SQL Server がどのようにメモリを使用するかについては、Microsoft のウェブサイトで「メモリ管理アーキテクチャガイド」を参照してください。
リソース使用量のベースラインを策定する
インスタンスのリソース使用量のベースラインを策定するには、FreeableMemory、Page Life Expectancy、Buffer Cache Hit Ratio などのメトリクスを監視します。インスタンスのデータ量が大幅に増加した場合は、max_server_memory 値を増やしてください。インスタンスで同じレベルのパフォーマンスを維持するには、データ量の変化に比例して max_server_memory 値を増やしてください。
注: レポート、DMV などの SQL Server ツールを使用すると、SQL Server 内でメモリを使用しているコンポーネントを特定できます。
SQL Server Management Studio (SSMS) を使用して SQL Server のメモリ使用量を確認するには、次の手順を実行します。
- SSMS を開き、Amazon RDS for SQL Server インスタンスに接続します。
- Object Explorer でAmazon RDS インスタンスのエンドポイント名を右クリックします。
- [レポート]、[標準レポート]、[メモリ消費量] を選択します。
SSMS をダウンロードする方法については、Microsoft のウェブサイトで「Download SQL Server Management Studio (SSMS)」(SQL Server Management Studio (SSMS) のダウンロード) を参照してください。
sys.dm_os_memory_clerks をクエリしても、SQL Server 内でメモリを最も多く使用するコンポーネントを特定できます。詳細については、Microsoft のウェブサイトで「sys.dm_os_memory_clerks (Transact-SQL)」および「Internal memory usage by SQL Server engine」(SQL Server エンジンによる内部メモリ使用量) を参照してください。
