ApsaraDB RDS:パフォーマンスインサイト

ステップ 1: パフォーマンスインサイトを有効にする

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

2. 左側のナビゲーションウィンドウで、[モニタリングとアラート] を選択します。パフォーマンスインサイト タブをクリックします。

3. [パフォーマンスインサイトを有効にする] ボタンをクリックします。表示されるダイアログボックスで、[OK] をクリックしてこの機能を有効にします。

   

   説明

   パフォーマンスインサイト機能が不要になった場合は、パフォーマンスインサイト ページの Performance Insight の無効化 をクリックして無効にします。

4. この機能を有効にした後、しばらく待ちます。その後、パフォーマンスインサイトページにデータが表示され始めます。

ステップ 2: パフォーマンスインサイトを使用して分析する

この機能を有効にすると、[パフォーマンスインサイト] ページで包括的なパフォーマンス分析を実行できます。

症状

モニタリングデータによると、ある時点で低速 SQL 文の数が急激に増加し、アプリケーションの応答時間が大幅に悪化したことが示されています。

診断分析

ステップ 1: パフォーマンスメトリックのトレンドを分析する

主要なパフォーマンスメトリックのトレンドチャートを確認します。アクティブセッション数は、通常の十数レベルから 00:34 には 1,100 以上に急増しました。これは、PostgreSQL インスタンスの妥当な同時処理能力を超えています。

ステップ 2: 待機イベントを分析する

平均アクティブセッション (AAS) チャートの待機イベント分布は、主なボトルネックが次のイベントによって引き起こされていることを示しています:

• Lock/transactionid: トランザクション ID のロック待ち。これは通常、長時間トランザクションまたはデッドロックによって引き起こされます。

• Lock/tuple: 行レベルのロック待ち。これは、深刻な同時書き込み競合を示します。

アクティブセッション数は、16 コア CPU の理論上の処理限界を超えています。これにより、システムが深刻なロック競合を経験していることが確認されます。

ステップ 3: SQL 文を分析する

Top SQL リストは、上位 2 つのクエリに対して、220 と 119 のセッションがロックリソースの解放を待っていることを示しています。これらの SQL 文がロック待ちチェーンの原因です。

ステップ 4: ソースを追跡する

Top Hosts と Top Databases のデータを使用して、問題の原因を特定します:

• ソースクライアント: 140.205.XXX.XXX

• ターゲットデータベース: perf_test

根本原因の分析

障害タイプ: ロック競合のアバランシェ

技術的原理:

• トリガー: クライアントが perf_test データベースに対して高同時実行のデータ操作言語 (DML) 操作を開始します。これらの操作には、ホット行の更新や大規模なトランザクション処理が含まれる場合があります。

• エスカレーションメカニズム: PostgreSQL のロック管理メカニズムでは、複数のトランザクションが同じリソースを競合すると、後続のトランザクションは待機キューに入ります。接続制限やロック待ちタイムアウトの制御がないため、新しい接続が継続的に殺到し、ロック待ちの悪循環が生まれます。

解決策

即時措置:

1. 問題のあるクライアント IP アドレスからの接続数を制限する:

   ALTER ROLE target_user CONNECTION LIMIT 10;   -- target_user: データベースのユーザー名

2. 長時間待機しているセッションを終了させる:

   -- まず、終了するセッションの詳細を表示します
   SELECT 
       pid,                                    -- プロセス ID (セッション識別子)
       usename,                                -- データベースのユーザー名
       state,                                  -- セッションの状態 (active や idle など)
       wait_event,                             -- 特定の待機イベントのタイプ
       now() - query_start AS query_duration,  -- 現在のクエリの実行時間
       left(query, 50) AS query_preview        -- SQL 文のプレビュー (最初の 50 文字)
   FROM pg_stat_activity 
   WHERE datname = 'perf_test'                 -- データベース名を指定します
     AND client_addr = '140.205.XXX.XXX'       -- クライアント IP アドレスを指定します
     AND state = 'active'                      -- アクティブなセッションのみをクエリします
     AND wait_event_type = 'Lock'              -- ロックを待機しているセッションのみをクエリします
     AND pid <> pg_backend_pid()               -- 自己終了を防ぐために、このクエリを実行している現在のセッションを除外します
     AND now() - query_start > interval '5 minutes';  -- クエリが 5 分以上実行されています
     
   -- 詳細を確認した後、セッションを終了します
   SELECT pg_terminate_backend(pid) 
   FROM pg_stat_activity 
   WHERE datname = 'perf_test'
     AND client_addr = '140.205.XXX.XXX'
     AND state = 'active' 
     AND wait_event_type = 'Lock'
     AND pid <> pg_backend_pid()
     AND now() - query_start > interval '5 minutes';
   
   -- ターゲットセッションが終了したかどうかを確認します
   SELECT pid, usename, state, query 
   FROM pg_stat_activity 
   WHERE datname = 'perf_test'
     AND client_addr = '140.205.XXX.XXX';    

長期的な最適化:

1. 接続プールを設定する: PgBouncer などの接続プールをデプロイして、最大同時接続数を制御します。

2. タイムアウトパラメーターを調整する:

   -- ロック待ちタイムアウトを設定します
   ALTER DATABASE perf_test SET lock_timeout = '30s';
   -- 文の実行タイムアウトを設定します
   ALTER DATABASE perf_test SET statement_timeout = '60s';

3. アプリケーション層を最適化する:

   • トランザクションの粒度を減らして、長時間トランザクションを回避します。

   • オプティミスティックロックまたは分散ロックメカニズムを使用して、ホットスポットデータを処理します。

   • 読み書き分離を実装して、読み取り専用クエリを読み取り専用インスタンスに転送します。

4. モニタリングとアラートを設定する: アクティブな接続数とロック待ち時間のモニタリングしきい値を設定して、潜在的な障害の早期警告を受け取ります。