ApsaraDB RDS:RDS SQL Server におけるメモリプレッシャーの診断と最適化

モニタリングとアラートでの主要メトリックの確認

1. RDS インスタンスリストに移動し、リージョンを選択して、対象のインスタンス ID をクリックします。

2. 左側のメニューで、[モニタリングとアラート] をクリックします。

3. 以下のメトリックを確認します。

インスタンス固有の mem_usage のしきい値：

リンクサーバー、CLR、インメモリ OLTP、または多数の拡張イベント (XEvents) やトレースなど、メモリオーバーヘッドの高い機能が有効になっている場合、実際のメモリ消費量は設定された max server memory の値を大幅に超えることがあります。その場合は、max server memory を低く設定して、OS と管理サービスのためのヘッドルームを確保してください。

インスタンスの健全な PLE しきい値の計算：

従来の 300 秒というしきい値は、大容量メモリのインスタンスには適用できません。代わりに次の式を使用してください。

PLE しきい値 = (バッファープールのメモリ (GB) / 4) × 300

例：

• 16 GB インスタンス (バッファープールは約 12 GB)：健全な PLE > [900秒]

• 128 GB インスタンス (バッファープールは約 110 GB)：健全な PLE > [8,250秒]

Performance Insight でのメモリ構成の分析

モニタリングとアラートで潜在的な問題が示された場合は、Performance Insight を使用して、メモリが何に使用されているかの内訳を取得します。

1. 左側のメニューで、[自律サービス] > [パフォーマンス最適化] を選択し、[Performance Insight] タブを開きます。

2. 右上隅の [カスタムメトリック] をクリックします。[メモリ使用量の分類] と [高度なメモリ使用量] のグループからメトリックを追加します。

[メモリ使用量の分類メトリック]

これらのメトリックは、SQL Server Memory Manager パフォーマンスオブジェクトカウンターに対応しています。

単一のメトリックだけで全体像を把握することはできません。これらを総合的に、かつワークロードの文脈で解釈してください。

高度なメモリ使用量メトリック (盗用メモリの内訳)

これらのメトリックは、盗用メモリを内部の割り当てカテゴリ別に分類し、どのコンポーネントがメモリを消費しているかを正確に可視化します。

ステージ1：プレッシャータイプの確認

まず PLE と待機統計を確認します。これにより、どのシナリオが適用されるか、次にどのセクションを読むべきかが決まります。

ステージ2：メモリ構成の分析

バッファープールのプレッシャーが確認されたら、Database_Cache_Memory_Kb と Stolen_Server_Memory_Kb を比較します。

• 盗用メモリが高い (全体の 20% 以上)：メモリの大部分がデータページ以外の用途 (プランキャッシュ、接続、CLR、その他のコンポーネント) に使われています。これは割り当ての問題です。スケールアップを検討する前に、誤用されているメモリを解放してください。

• データベースキャッシュが優勢で、空きメモリが 0 に近い：バッファープールはすでに利用可能なメモリのほとんどを使用していますが、それでもホットデータセットを保持できていません。これは容量の問題です。ホットデータ量を最適化するか、スケールアップしてください。

ステージ3：診断に基づくアクション

プレッシャーのタイプとその原因がわかったら、以下の関連するシナリオの最適化を適用します。その後、同じメトリックを使用して修正が機能したことを確認します。

症状

• Performance Insight で PLE の低下とともに Page_Reads が大幅に上昇する

• クエリのデータ量が変わっていないのに、ディスク I/O スループットが増加する

• PLE がインスタンス固有のしきい値を一貫して下回り続ける

最適化オプション

症状

• Stolen_Server_Memory_Kb が継続的に増加し、プランキャッシュの内部クォータ制限に近い高い値を維持する

• 盗用メモリが増加するにつれて、Database_Cache_Memory_Kb が下方に圧迫される

• 頻繁なキャッシュの削除とプランの再コンパイルにより CPU 使用率が上昇する

• バッファープールが縮小するため、ディスク I/O が上昇する

• アプリケーションが、リテラル値が異なるが構造的に同一の SQL ステートメントを多数送信する (例：WHERE id = 123、WHERE id = 456)

診断手順

ステップ 1：単一使用プランの割合を確認する。

一度しか実行されないプランの割合が高い場合、キャッシュが再利用不可能なプランで埋め尽くされていることを示します。

WITH PlanStats AS
(
    SELECT
        cp.usecounts,
        cp.size_in_bytes / 1024.0 / 1024.0 AS size_mb
    FROM sys.dm_exec_cached_plans AS cp
    WHERE cp.cacheobjtype = 'Compiled Plan'
)
SELECT
    total_plans           = COUNT(*),
    single_use_plans      = SUM(CASE WHEN usecounts = 1 THEN 1 ELSE 0 END),
    single_use_ratio_pct  =
        CAST(
            100.0 * SUM(CASE WHEN usecounts = 1 THEN 1 ELSE 0 END) / NULLIF(COUNT(*), 0)
            AS DECIMAL(5,2)
        ),
    total_plan_mb         = CAST(SUM(size_mb) AS DECIMAL(18,2)),
    single_use_plan_mb    = CAST(SUM(CASE WHEN usecounts = 1 THEN size_mb ELSE 0 END) AS DECIMAL(18,2)),
    single_use_mem_pct    =
        CAST(
            100.0 * SUM(CASE WHEN usecounts = 1 THEN size_mb ELSE 0 END)
            / NULLIF(SUM(size_mb), 0)
            AS DECIMAL(5,2)
        )
FROM PlanStats;

単一使用プランがプランキャッシュメモリの 50% 以上を占める場合、キャッシュは再利用不可能なプランに浪費されています。

ステップ 2：単一使用プランを生成している SQL ステートメントを特定する。

-- プランキャッシュメモリを最も多く消費している上位20のアドホッククエリ
SELECT TOP 20
    cp.usecounts AS [execution_count],
    cp.size_in_bytes / 1024 AS [plan_size_kb],
    cp.objtype AS [object_type],
    st.text AS [sql_text]
FROM sys.dm_exec_cached_plans AS cp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) AS st
WHERE cp.objtype = 'Adhoc'
  AND cp.usecounts = 1
ORDER BY cp.size_in_bytes DESC;

結果が、同じ構造でリテラル値が異なる多くのステートメントを示している場合、根本原因はパラメーター化されていないクエリです。

最適化オプション

オプション 1：optimize for ad hoc workloads を有効にする (推奨)

このパラメーターは、アドホッククエリの初回実行時に軽量なスタブのみをキャッシュします。完全なプランは、クエリが再度実行された場合にのみ保存されます。これにより、CPU のコンパイルオーバーヘッドに影響を与えることなく、単一使用プランによる盗用メモリを削減できます。

1. RDS インスタンスリストに移動し、インスタンス詳細ページを開きます。

2. 左側のメニューで、[パラメータ設定] をクリックします。

3. optimize for ad hoc workloads を検索して有効にします。

オプション 2：アプリケーションでクエリをパラメーター化する

文字列連結の代わりにパラメーター化クエリを使用するようにアプリケーションコードを変更します。アプリケーションがオブジェクトリレーショナルマッピング (ORM) フレームワークを使用している場合は、自動パラメーター化または第 2 レベルキャッシュが利用可能かどうかを確認してください。

オプション 3：データベースレベルで強制パラメーター化を有効にする

アプリケーションの変更が不可能な場合は、影響を受けるデータベースで強制パラメーター化を有効にします。

1. RDS インスタンスリストに移動し、インスタンス詳細ページを開きます。

2. 左側のメニューで、[データベース管理] をクリックします。

3. 対象のデータベースの [詳細の表示] をクリックします。

4. [基本情報] セクションで、parameterization を FORCED に設定し、[送信] をクリックします。

症状

ORDER BY、GROUP BY、DISTINCT、またはハッシュ結合など、ソートやハッシュ処理を伴うクエリは、メモリ許可と呼ばれるメモリのブロックを要求します。この許可が満たされない場合、2 つの障害モードが発生します。

このプレッシャータイプは PLE を低下させません。PLE が正常に見えるにもかかわらず上記の症状が見られる場合、問題はバッファープールではなくクエリワークスペースにあります。

診断手順

現在待機中または大量のメモリ許可を消費しているクエリを見つける：

-- リアルタイムのメモリ許可
SELECT
    mg.session_id,
    mg.request_time,
    mg.grant_time, -- NULLはクエリが許可を待機している (RESOURCE_SEMAPHORE) ことを意味します
    (mg.requested_memory_kb / 1024.0) AS requested_mb,
    (mg.granted_memory_kb / 1024.0)   AS granted_mb,
    (mg.required_memory_kb / 1024.0)  AS required_mb,
    mg.queue_id,
    mg.wait_order,
    st.text AS sql_text,
    qp.query_plan
FROM sys.dm_exec_query_memory_grants AS mg
CROSS APPLY sys.dm_exec_sql_text(mg.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(mg.plan_handle) AS qp
ORDER BY mg.granted_memory_kb DESC;

過去に最大の許可を要求したクエリを見つける：

SELECT TOP 20
    qs.execution_count,
    (qs.max_grant_kb / 1024.0)                             AS max_grant_mb,
    (qs.total_grant_kb / qs.execution_count / 1024.0)      AS avg_grant_mb,
    (qs.total_worker_time / qs.execution_count / 1000.0)   AS avg_cpu_ms,
    qs.last_execution_time,
    SUBSTRING(st.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(st.text)
          ELSE qs.statement_end_offset
          END - qs.statement_start_offset)/2) + 1) AS query_text,
    qp.query_plan
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
ORDER BY qs.max_grant_kb DESC;

query_plan 列で、Spill キーワードを検索するか、Sort または Hash Match 演算子の警告アイコンを探します。

根本原因と修正