RDS for SQL Server インスタンスの空きメモリ不足のトラブルシューティング方法を教えてください。

簡単な説明

空きメモリが非常に少ないと、インスタンスで予期しないダウンタイムが発生します。そのため、インスタンスのメモリ使用量を監視し、是正措置を講じることが重要です。

解放可能なメモリとは、RDS インスタンスで使用可能なメモリ (RAM) の量です。Amazon RDS インスタンスで使用可能なメモリの合計量は、インスタンスクラスによって異なります。た例えば、インスタンスクラス db.r5.8xlarge は 32 個の vCPU と 256 GiB のメモリを提供します。db.r5.8xlarge インスタンスクラスを使用して RDS インスタンスをプロビジョニングすると、インスタンスクラスの合計メモリ (256 GiB) は以下によって共有されます。

• オペレーティングシステム
• Amazon RDS プロセス
• データベースエンジン
• ワーカースレッド
• ビジネスインテリジェンススイート (SSIS、SSAS、SSRS) アプリケーションなど。

SQL Server がメモリを使用する方法の詳細については、Microsoft ドキュメントウェブサイトの「メモリ管理アーキテクチャガイド」を参照してください。

解決方法

インスタンスにおけるメモリ使用量のモニタリング

Amazon CloudWatch メトリクス

FreeableMemory の Amazon CloudWatch メトリクスをモニタリングして、メモリ不足の発生を特定します。FreeableMemory とともに、以下を監視して、使用可能なメモリが不足しているときにワークロードが増加しているかどうかを確認できます。

• DatabaseConnections
• CPUUtilization
• ReadIOPS
• ReadThroughput
• WriteIOPS
• WriteThroughput

拡張モニタリング

拡張モニタリングは、Microsoft SQL ServerのOSメトリクスを監視するために、1、5、10、15、30、 60 秒などのさまざまな粒度で有効にできます。粒度は 1 秒または 5 秒 (デフォルトは 60 秒) に設定するのがベストプラクティスです。CloudWatch アラームを作成し、拡張モニタリングを使用して Amazon RDS for SQL Server インスタンスのメモリ消費をモニタリングするにはどうすればよいですか?

空きメモリの容量が少ない場合のトラブルシューティング

空きメモリ不足の問題を解決するには、次の操作を行います。

RDS インスタンスが使用するメモリを制限する

最大サーバーメモリをシステム全体のメモリ不足を引き起こさない値に設定して、RDS インスタンスが使用するメモリを制限します。インスタンスの最大サーバーメモリ値は、次の式を使用して決定できます。

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 の間である場合は、4 GB の RAM につき 1 GB のままにしておきます。例えば、16 GB のサーバーの場合は、4 GB のままにします。
• サーバー上の RAM が 16 GB を超える場合: 4 GB の RAM につき 1 GB を 16 GB とし、RAM 8 GB あたり 1 GB を 16 GB 以上にします。

例えば、サーバーに 64 GB の RAM が搭載されている場合、計算は次のようになります。

• OS 用に 1 GB
• 最大 16 GB の RAM: 16/4 = 4 GB
• 16 GB を超える残りの RAM: (64-16) /8 = 6
• 残す RAM の総容量: 1 + 4 + 6 = 11 GB
• max_server_memory: 64 – 11 = 53 GB

注:

• インスタンスで SSIS、SSAS、または SSRS を使用している場合は、これらのコンポーネントに対応できるように max_server_memory を調整する必要があります。
  例: RDS インスタンスで SSRS を使用したいとします。SSRS の最大メモリ値を 10% (DB インスタンスの合計メモリに対するパーセンテージ) に設定します。これは、64 GiB のメモリを搭載したインスタンスでは約 6.4 GiB です。max_server_memory の値は約 46 GiB (64-11-6.4) でなければなりません。
• max_server_memory の初期設定後は、 FreeableMemory を常に監視して、割り当てられたメモリを増やすか減らすかを決定する必要があります。

max_server_memory を変更するには、カスタムパラメータグループを使用して値を設定します。max_server_memory の値を MB 単位で指定する必要があります。

**注注意:**パラメータ max_server_memory は動的パラメータです。そのため、変更を有効にするために再起動する必要はありません。

データベース接続を確認する

インスタンスへの各データベース接続には、ワーカースレッド用のバッファープールの外部にある程度のメモリ割り当てが必要です。したがって、データベース接続の急増により、確保できるメモリが低下する可能性があります。

SSIS、SSAS、または SSRS コンポーネントが DB インスタンスで使用されているかどうかを確認する

Amazon RDS for SQL Server オプショングループを使用して、DB インスタンスで SSIS、SSAS、または SSRS コンポーネントが使用されているかどうかを確認します。これらのコンポーネントが使用するメモリは、 max_server_memory 設定の範囲外にあります。これらの機能を使用しない場合は、オプショングループを変更して削除してください。これらの機能を削除すると、インスタンスのメモリ使用量が減少します。

パフォーマンスインサイトを使用して DB インスタンスを監視する

Performance Insights を使用すると、DB インスタンスをモニタリングしてデータベースのパフォーマンス分析を行うことができます。Performance Insights ダッシュボードを使用して、データベースの負荷、待機時間、クエリ、ホスト、ユーザーなどをモニタリングできます。これらを監視することで、インスタンスの速度を低下させる潜在的なボトルネックを特定するのに役立ちます。

DB インスタンスの定期メンテナンスを実行する

定期的なインデックスメンテナンスを行い、統計を最新の状態に保ちます。インデックスの断片化が進んでいると、入出力アクティビティが増加し、メモリ消費量が増える可能性があります。同様に、統計が古くなっていると、カーディナリティの推定が不正確になり、最適ではないクエリプランが選択される可能性があります。

**注意:**インデックスと統計のメンテナンスは、ピーク時以外またはメンテナンス時間帯に行うのがベストプラクティスです。

ページ寿命とバッファキャッシュヒット率を監視

Page Life Expectancy (PLE) は、ページが参照なしでバッファプールに留まる秒数を示します。

Buffer Cache Hit Ratio (BCHR) は、バッファプールからのデータページが満たしたページリクエストの割合 (%) です。

PLEとBCHRを監視すると、メモリープレッシャーを特定できます。Performance Insights を使用してこれらのメトリクスを監視するには、次の操作を行います。

1. Amazon RDS コンソールを開きます。
2. [Performance Insights] を選択します。
3. 監視する RDS for SQL Server インスタンスを選択します。
4. メトリクスを確認する時間範囲を設定し、[メトリクスの管理] を選択します。
5. [データベースメトリクス]、[ページ寿命]、[バッファキャッシュヒット率] を選択します。

最適なパフォーマンスを得るには、これらのメトリクスの値をできるだけ高くする必要があります。パフォーマンスインサイトを使用してこれらのメトリクスを監視できます。これらのメトリクスの値は、一定期間にわたって一貫して低いことがわかるかもしれません。このような場合は、データにアクセスするクエリを調整するか、インスタンスクラスを増やしてメモリを増やしてください。

インスタンスにメモリ負荷がかかり、PLE と BCHR が低くなると、PAGEIOLATCH の待機時間が長くなります。つまり、SQL Server はページがディスクから取得されてメモリに読み込まれるのを待っているということです。また、RESOURCE_SEMAPHORE wait は、メモリ不足が原因でクエリによるメモリ要求を受け付けられない場合に気付くことがあります。これにより、データページがメモリに十分な時間キャッシュされないため、CPU 使用率が増加します。これが発生すると、SQL Serverはデータにアクセスするためにディスクに繰り返しアクセスしなければならず、パフォーマンスの問題が発生します。

最も多くのリソースを使用しているクエリを識別

Performance Insights を使用して、最も多くのリソースを使用しているクエリをキャプチャし、パフォーマンスを向上させるように調整します。

ワークロードに適したインスタンスサイズを選択する

インスタンスのメモリ容量は、インスタンスタイプによって異なります。DB インスタンスにワークロード用の十分なリソースがあるように、十分なリソースを持つインスタンスクラスを選択することが重要です。リソースの少ないインスタンスではパフォーマンスの問題が発生し、大きすぎるインスタンスはリソースを浪費します。

リソース使用量のベースライン

FreeableMemory、ページ寿命、バッファキャッシュヒット率などのメトリクスを監視して、インスタンスのリソース使用量をベースライン化します。インスタンスのデータ量が大幅に増加した場合は、 max_server_memory の値を増やしてください。インスタンスで同じレベルのパフォーマンスを維持するために、データ量の変化に比例して max_server_memory 値を増やすようにしてください。

注意:レポートや DMV などの SQL Server ネイティブツールを使用して、SQL Server 内部のメモリを使用するコンポーネントを識別できます。SQL Server Management Studio (SSMS) を使用すると、SQL Server のメモリ使用量を確認できます。

1. SQL Server 管理スタジオ (SSMS) を開き、RDS for SQL Server インスタンスに接続します。
2. オブジェクトエクスプローラーで、RDS インスタンスのエンドポイント名を右クリックします。
3. レポート、標準レポート、メモリ消費量を選択します。

また、sys.dm_os_memory_clerks DMV にクエリを実行すると、SQL Server 内で最大メモリを使用するコンポーネントを特定できます。

---