ApsaraDB RDS:Performance Insight

Grafik metrik kinerja utama

Di bagian atas halaman, grafik tren melacak metrik berikut selama rentang waktu yang dipilih:

Rincian beban multidimensi

Di bawah grafik AAS, beralihlah antar tab dimensi untuk mengidentifikasi sumber beban tinggi:

Gejala

Data pemantauan menunjukkan lonjakan tiba-tiba pada pernyataan SQL lambat dan peningkatan signifikan pada waktu respons aplikasi.

Langkah 1: Periksa tren metrik kinerja

Pada grafik metrik kinerja utama, cari lonjakan tajam pada jumlah sesi aktif. Dalam contoh ini, jumlah sesi melonjak dari level normal sekitar belasan menjadi lebih dari 1.100 pada pukul 00:34 — jauh melebihi kapasitas pemrosesan bersamaan dari instans PostgreSQL 16-core.

Langkah 2: Identifikasi event tunggu

Grafik AAS menunjukkan distribusi event tunggu. Dalam kasus ini, dua event mendominasi:

• Lock/transactionid: Tunggu kunci ID transaksi, biasanya disebabkan oleh transaksi jangka panjang atau deadlock.

• Lock/tuple: Tunggu kunci tingkat baris, menandakan adanya konflik penulisan konkuren yang parah.

Jumlah sesi aktif melebihi batas pemrosesan teoretis CPU 16-core, yang mengonfirmasi adanya kontensi kunci yang parah.

Langkah 3: Temukan pernyataan SQL penyebab

Beralih ke tab SQL. Dua kueri teratas menunjukkan 220 dan 119 sesi sedang menunggu sumber daya kunci — pernyataan-pernyataan ini merupakan akar dari rantai tunggu kunci tersebut.

Langkah 4: Lacak sumbernya

Periksa tab Hosts dan Databases untuk mengidentifikasi asal beban:

• Klien sumber: 140.205.XXX.XXX

• Database target: perf_test

Akar masalah

Jenis gangguan: Avalanche kontensi kunci

Klien di 140.205.XXX.XXX memulai operasi Data Manipulation Language (DML) dengan konkurensi tinggi pada database perf_test — kemungkinan besar melibatkan pembaruan data hot spot atau pemrosesan transaksi skala besar. Tanpa batasan koneksi atau kontrol timeout tunggu kunci, koneksi baru terus berdatangan karena setiap koneksi masuk ke antrian tunggu kunci, sehingga menciptakan siklus kontensi kunci yang tak terkendali.

Solusi

Tindakan segera:

1. Batasi koneksi dari klien bermasalah:

   ALTER ROLE target_user CONNECTION LIMIT 10;   -- target_user: username database

2. Hentikan sesi yang menunggu terlalu lama:

   -- Tinjau sesi sebelum menghentikannya
   SELECT
       pid,                                    -- Process ID (identifier sesi)
       usename,                                -- Username database
       state,                                  -- Status sesi (active atau idle)
       wait_event,                             -- Jenis event tunggu spesifik
       now() - query_start AS query_duration,  -- Durasi kueri saat ini
       left(query, 50) AS query_preview        -- Pratinjau pernyataan SQL (50 karakter pertama)
   FROM pg_stat_activity
   WHERE datname = 'perf_test'                 -- Database target
     AND client_addr = '140.205.XXX.XXX'       -- Alamat IP klien sumber
     AND state = 'active'
     AND wait_event_type = 'Lock'
     AND pid <> pg_backend_pid()               -- Kecualikan sesi saat ini
     AND now() - query_start > interval '5 minutes';
   
   -- Setelah memastikan daftarnya, hentikan sesi tersebut
   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';
   
   -- Verifikasi bahwa sesi target telah dihentikan
   SELECT pid, usename, state, query
   FROM pg_stat_activity
   WHERE datname = 'perf_test'
     AND client_addr = '140.205.XXX.XXX';

Optimasi jangka panjang:

1. Terapkan kolam koneksi: Gunakan connection pooler seperti PgBouncer untuk membatasi jumlah maksimum koneksi bersamaan.

2. Konfigurasikan parameter timeout:

   -- Atur timeout tunggu kunci
   ALTER DATABASE perf_test SET lock_timeout = '30s';
   -- Atur timeout eksekusi pernyataan
   ALTER DATABASE perf_test SET statement_timeout = '60s';

3. Optimalkan logika aplikasi:

   • Kurangi granularitas transaksi untuk menghindari transaksi jangka panjang.

   • Gunakan kunci optimis atau mekanisme kunci terdistribusi untuk data hot spot.

   • Terapkan pemisahan baca/tulis untuk mengarahkan kueri read-only ke instansi read-only.

4. Tetapkan ambang batas pemantauan: Konfigurasikan alert untuk jumlah koneksi aktif dan waktu tunggu kunci agar masalah dapat terdeteksi sebelum memburuk.