All Products
Search
Document Center

PolarDB:Pembatasan SQL

Last Updated:Jun 22, 2026

dan menyediakan fitur Pembatasan SQL yang memungkinkan Anda mengonfigurasi aturan pembatasan untuk titik akhir tertentu guna mencegah lalu lintas abnormal memengaruhi layanan Anda. Topik ini menjelaskan cara menggunakan fitur tersebut.

Pendahuluan

Fitur Pembatasan SQL memungkinkan Anda mengonfigurasi aturan pembatasan untuk titik akhir tertentu dengan menggunakan templat SQL untuk mencocokkan pernyataan SQL yang dieksekusi pada titik akhir tersebut, serta membatasi konkurensi maksimum atau permintaan per detik (QPS). Fitur ini berguna dalam skenario berikut:

  • Kluster PolarDB mengalami beban database tinggi akibat kueri SQL lambat yang memengaruhi operasi bisnis normal.

  • Anda ingin membatasi sumber daya yang tersedia untuk jenis kueri SQL berisiko tertentu atau sepenuhnya memblokir eksekusinya.

Prosedur

Catatan

Untuk mengaktifkan fitur Pembatasan SQL, hubungi kami.

  1. Masuk ke PolarDB console. Di panel navigasi kiri, klik Clusters. Pilih region tempat kluster berada, lalu klik ID kluster untuk membuka halaman detail kluster.

  2. Di panel navigasi kiri, klik Configuration and Management > Security Management.

  3. Pada tab SQL throttling, klik Add untuk membuat aturan pembatasan SQL baru.

  4. Pada kotak dialog Create SQL Throttling Rule, atur parameter berikut lalu klik OK.

    Category

    Parameter

    Description

    Basic Information

    Rule Name

    Nama aturan pembatasan. Nama harus memenuhi persyaratan berikut:

    • Maksimal 30 karakter.

    • Hanya boleh berisi huruf kapital, huruf kecil, dan angka.

    Description

    Opsional. Deskripsi untuk aturan pembatasan agar lebih mudah dikelola. Maksimal 64 karakter.

    EndpointId

    Pilih titik akhir tempat aturan pembatasan diterapkan.

    Catatan
    • Anda hanya dapat mengonfigurasi aturan pembatasan untuk titik akhir kluster atau titik akhir kustom (read/write atau read-only) yang menggunakan load balancing berbasis active-request. Pembatasan SQL tidak didukung untuk titik akhir utama atau titik akhir read-only yang menggunakan load balancing berbasis koneksi.

    • Aturan bersifat spesifik per titik akhir. Aturan yang dikonfigurasi untuk satu titik akhir hanya memengaruhi koneksi yang dibuat ke titik akhir tersebut.

    Configurations

    Rule Type

    Pilih jenis aturan. Didukung Throttle Active Concurrent Statements dan Throttle QPS per Connection.

    Catatan

    Throttle QPS per Connection membatasi jumlah permintaan per detik untuk satu koneksi. Jenis ini cocok untuk skenario yang menggunakan connection pool atau koneksi persisten. Untuk koneksi singkat, gunakan Throttle Active Concurrent Statements.

    Current Mode

    Pilih mode pencocokan untuk templat SQL. Didukung Template Match dan Full-text Match. Untuk informasi selengkapnya tentang perbedaan kedua mode tersebut, lihat Template match vs. full-text match.

    Database Account Name

    Menentukan akun tempat aturan diterapkan. Anda dapat menentukan hingga 10 akun, dipisahkan koma. Jika dikosongkan, aturan berlaku untuk semua akun.

    Database Name

    Menentukan database tempat aturan diterapkan. Anda dapat menentukan hingga 10 database, dipisahkan koma. Jika dikosongkan, aturan berlaku untuk semua database.

    SQL Template

    Konfigurasikan templat SQL. Untuk informasi selengkapnya, lihat SQL templates and matching modes.

    Maximum Waiting Queue Length

    Panjang maksimum antrian tunggu. Nilainya berkisar antara 0 hingga 1024. Ketika konkurensi atau QPS dari kueri SQL yang cocok mencapai batas aturan, proksi menambahkan kueri ke antrian tunggu untuk dicoba ulang. Jika jumlah kueri dalam antrian melebihi batas ini, permintaan baru gagal dan error dikembalikan. Mengatur parameter ini dengan benar mencegah antrian tunggu terus bertambah hingga menyebabkan error out of memory (OOM) pada database proxy saat banyak kueri SQL dibatasi.

    Maximum Active Concurrent Statements

    Jumlah maksimum pernyataan konkuren aktif.

    Catatan

    Parameter ini wajib diisi hanya jika Throttle Active Concurrent Statements diatur ke Throttle Active Concurrent Statements.

    Maximum QPS per Connection

    QPS maksimum untuk setiap koneksi.

    Catatan

    Parameter ini wajib diisi hanya jika Throttle QPS per Connection diatur ke Throttle QPS per Connection.

Cara kerja

Pembatasan SQL diimplementasikan di tingkat database proxy. Anda mengonfigurasi aturan pembatasan pada database proxy untuk mengontrol konkurensi atau QPS dari pernyataan SQL tertentu yang diteruskan. Proses ini tidak menambahkan overhead pada node read/write atau read-only kluster database. Akibatnya, Anda hanya dapat mengonfigurasi aturan untuk titik akhir kluster dan titik akhir kustom yang meneruskan lalu lintas melalui proxy.

Templat SQL dan mode pencocokan

Template match vs. full-text match

Templat SQL dapat berupa pernyataan SQL apa pun yang mengikuti sintaks standar kluster atau . Database proxy memproses templat secara berbeda tergantung pada mode pencocokan yang dipilih.

  • Misalnya, Anda mengonfigurasi aturan pembatasan dengan templat SQL berikut:

    SELECT * FROM tbl WHERE id < 1;
    • Jika Anda memilih Template Match, templat SQL dinormalisasi: spasi tambahan dan komentar dihapus, serta konstanta seperti string dalam tanda kutip tunggal dan angka diganti dengan wildcard. Hasilnya:

      -- Templated result
      SELECT * FROM tbl WHERE id < ?
    • Jika Anda memilih Full-text Match, templat SQL juga dinormalisasi, tetapi konstanta tidak diganti. Hasilnya:

      -- Normalized result only
      SELECT * FROM tbl WHERE id < 1

    Database proxy kemudian menghasilkan pengenal unik untuk SQL yang telah diproses guna pencocokan selanjutnya.

  • Setelah aturan pembatasan diaktifkan, database proxy memproses setiap pernyataan SQL masuk dengan cara yang sama. Misalnya, pertimbangkan pernyataan SQL masuk berikut:

    SELECT * FROM tbl WHERE id < 100;

    Dua jenis SQL yang dinormalisasi dihasilkan, dan pengenal uniknya dihitung untuk dicocokkan dengan aturan pembatasan:

    -- Templated result
    SELECT * FROM tbl WHERE id < ?
    -- Normalized result only
    SELECT * FROM tbl WHERE id < 100

Setelah aturan Pembatasan SQL diaktifkan, database proxy mengevaluasi pernyataan terhadap aturan yang dikonfigurasi sebelum meneruskan pernyataan SQL. Jika aturan dikonfigurasi untuk Template Match, hasil templated digunakan untuk pencocokan. Jika aturan dikonfigurasi untuk Full-text Match, hasil normalized-only yang digunakan. Setelah ditemukan kecocokan, konkurensi atau QPS-nya dihitung, dan proxy melakukan aksi pembatasan yang sesuai.

Oleh karena itu, untuk pernyataan SQL dan templat SQL pada contoh sebelumnya, kecocokan hanya ditemukan jika aturan dikonfigurasi untuk Template Match.

Kueri terparameterisasi

Templat SQL mendukung kueri terparameterisasi yang menggunakan sintaks binding parameter PostgreSQL standar:

SELECT * FROM tbl WHERE id < $1 AND name = $2 LIMIT 1;

Baik pada mode Template Match maupun Full-text Match, bagian terparameterisasi diformat sebagai wildcard:

-- Templated result
SELECT * FROM tbl WHERE id < ? AND name = ? limit ?
-- Normalized result only
SELECT * FROM tbl WHERE id < ? AND name = ? limit 1

Oleh karena itu, untuk pernyataan SQL berikut:

SELECT * FROM tbl WHERE id < $1 AND name = 2 LIMIT 100;

Kecocokan ditemukan jika Current Mode diatur ke Template Match, tetapi tidak ditemukan jika Current Mode diatur ke Full-text Match.

Catatan

Anda tidak dapat menggunakan karakter ? sebagai penanda parameter dalam templat SQL:

-- Invalid SQL template. This does not conform to standard PostgreSQL syntax and will not match any SQL.
SELECT ?, ?, ?;
-- Valid SQL template
SELECT $1, $2, $3;

Prepared statements

Saat aplikasi Anda menggunakan pernyataan prepared, pernyataan PREPARE itu sendiri tidak memicu pembatasan. Hanya pernyataan EXECUTE yang memicu pembatasan. Untuk pernyataan EXECUTE, bagian SQL dari pernyataan PREPARE yang sesuai diformat atau ditemplatkan untuk mencocokkan aturan.

Catatan

Untuk informasi selengkapnya tentang pernyataan prepared, lihat PREPARE.

Contoh

Konfigurasikan aturan pembatasan dengan templat SQL berikut dan pilih Template Match sebagai mode pencocokan:

SELECT * FROM tbl WHERE id < $1 AND name > $2;

Untuk pernyataan SQL berikut:

-- The PREPARE statement does not trigger throttling.
PREPARE s1 AS SELECT * FROM tbl WHERE id < $1 AND name > 100;
-- The EXECUTE statement uses the SQL part from its corresponding PREPARE statement to match the throttling rule.
EXECUTE s1;
EXECUTE s1;
EXECUTE s1;

Tiga pernyataan EXECUTE tersebut akan mencocokkan aturan pembatasan dan dibatasi.

Demikian pula, jika Anda menggunakan pernyataan PREPARE dalam templat SQL aturan pembatasan, hanya bagian SQL dari pernyataan PREPARE yang diformat atau ditemplatkan untuk pembatasan. Oleh karena itu, dua templat SQL berikut setara saat membuat aturan:

-- Template 1
PREPARE s1 AS SELECT * FROM tbl WHERE id < $1 AND name > $2;
-- Template 2
SELECT * FROM tbl WHERE id < $1 AND name > $2;

Dukungan protokol kueri diperluas

Seperti halnya pernyataan prepared, saat driver aplikasi menggunakan protokol kueri diperluas, hanya pesan Execute yang memicu pembatasan. Untuk setiap pesan Execute, database proxy menemukan pesan Parse yang sesuai dan menggunakan SQL-nya untuk mencocokkan aturan pembatasan. Dengan demikian, Pembatasan SQL mendukung protokol kueri diperluas, sehingga Anda umumnya tidak perlu khawatir tentang protokol yang digunakan aplikasi Anda.

Catatan

Untuk informasi selengkapnya tentang protokol kueri diperluas, lihat dokumentasi komunitas.

Batasan

Saat ini, fitur Pembatasan SQL memiliki batasan berikut:

  • Pembatasan tidak didukung untuk multi-pernyataan. Jika Anda menggunakan multi-pernyataan, tidak ada aturan pembatasan yang dikonfigurasi yang dipicu.

    Multi-pernyataan mengacu pada teks SQL tunggal yang berisi beberapa pernyataan SQL yang dipisahkan titik koma. Berikut contoh multi-pernyataan yang dieksekusi menggunakan driver JDBC:

    Statement statement = connection.createStatement();
    statement.execute("select 1; select 2; select 3");

    Multi-pernyataan dapat mencocokkan beberapa aturan pembatasan secara bersamaan. Untuk mencegah perilaku tak terduga, pembatasan tidak didukung untuk multi-pernyataan.

  • Pembatasan tidak didukung untuk beberapa pernyataan khusus, seperti pernyataan kontrol transaksi dan prosedur tersimpan. Membatasi pernyataan kontrol transaksi seperti COMMIT akan mencegah transaksi berakhir secara normal. Oleh karena itu, pernyataan tersebut dikecualikan dari aturan pembatasan.

  • Saat klien atau driver menggunakan mode batching pernyataan, kueri SQL yang dibatch hanya memicu aturan pembatasan pertama yang cocok. Berikut contoh batching pernyataan menggunakan driver JDBC:

    Statement statement = connection.createStatement();
    statement.addBatch("select 1");
    statement.addBatch("select 2");
    statement.addBatch("select 3");
    int[] result = statement.executeBatch();
    statement.close();
    connection.close();

    Seperti halnya multi-pernyataan, saat Anda menggunakan batching pernyataan, driver biasanya menggabungkan pesan protokol kueri diperluas untuk beberapa kueri SQL dan mengirimkannya sekaligus. Hal ini juga dapat mengakibatkan situasi di mana beberapa aturan pembatasan dicocokkan secara bersamaan. Dalam kasus ini, hanya aturan pembatasan pertama yang cocok yang berlaku. Pada contoh sebelumnya, jika aturan pembatasan untuk tiga templat SQL berikut dikonfigurasi pada titik akhir:

    -- Template 1
    SELECT 1;
    -- Template 2
    SELECT 2;
    --Template 3
    SELECT 3;

    Hanya Template 1 yang akan dicocokkan.

  • Huruf besar/kecil kata kunci dalam templat Anda harus sesuai dengan huruf besar/kecil dalam teks SQL yang ingin Anda batasi.

  • Templat SQL tidak mendukung templat untuk ekspresi panjang variabel, seperti IN atau ANY, di mana jumlah elemennya dapat berbeda. Contohnya:

    -- SQL template
    SELECT * FROM tbl WHERE id IN ($1, $2, $3);
    -- SQL1, can match the template
    SELECT * FROM tbl WHERE id IN (1, 6, 8);
    -- SQL2, cannot match the template
    SELECT * FROM tbl WHERE id IN (1, 6, 8, 8);
  • Saat tidak ada aturan pembatasan yang dikonfigurasi, aturan pertama yang Anda tambahkan tidak berlaku untuk koneksi yang sudah ada. Namun, jika sudah ada aturan yang dikonfigurasi di konsol (diaktifkan atau dinonaktifkan), penambahan, modifikasi, atau penghapusan aturan berikutnya berlaku secara real time untuk semua koneksi.

    Catatan
    • Jika aplikasi Anda menggunakan koneksi persisten dan Anda ingin aturan baru berlaku segera, kami menyarankan Anda mengonfigurasi dan menonaktifkan aturan arbitrer pada titik akhir tersebut. Dengan demikian, aturan berikutnya yang Anda tambahkan atau ubah akan berlaku untuk koneksi baru maupun yang sudah ada.

    • Jika versi PolarProxy Anda 2.3.58 atau lebih baru, penambahan, modifikasi, dan penghapusan aturan pembatasan berlaku secara real time untuk semua koneksi.

Perilaku pembatasan

Pembatasan SQL menggunakan templat SQL dan antrian tunggu untuk membatasi QPS atau konkurensi aktif. Pernyataan SQL harus mencocokkan aturan pembatasan sebelum QPS atau konkurensinya dihitung untuk aturan tersebut. Saat konkurensi atau QPS melebihi batas yang ditetapkan dalam aturan, database proxy menempatkan pernyataan SQL ke dalam antrian tunggu untuk dicoba ulang setelah jeda. Hal ini memastikan konkurensi atau QPS pada database tetap dalam batas yang dikonfigurasi.

Waktu jeda antrian tunggu berbanding terbalik dengan QPS atau konkurensi yang dikonfigurasi dalam aturan. Jumlah maksimum pernyataan SQL yang dapat menunggu dalam antrian untuk aturan tertentu dibatasi oleh parameter Maximum Waiting Queue Length. Jika batas ini terlampaui, proxy tidak meneruskan pernyataan SQL dan mengembalikan error berikut ke klien:

SELECT 123;
Current query is being throttled and waiting queue is full.
Catatan

Error di atas tidak mengganggu atau mengubah status transaksi koneksi saat ini. Setelah menerima error ini, klien masih dapat memilih untuk commit atau rollback transaksi.

Selain itu, jika Anda mengatur Maximum Active Concurrent Statements atau Maximum QPS per Connection ke 0 dalam aturan pembatasan, pernyataan SQL apa pun yang cocok dengan aturan tersebut akan ditolak dan tidak diteruskan. Klien menerima error di atas secara langsung. Anda dapat menggunakan metode ini untuk sepenuhnya memblokir jenis pernyataan SQL tertentu.

Catatan
  • Antrian tunggu memiliki interval percobaan ulang minimum. Jika Anda mengatur QPS maksimum yang tinggi, QPS aktual mungkin sedikit lebih rendah dari nilai yang ditetapkan.

  • Untuk ketersediaan tinggi, database proxy biasanya diterapkan dengan dua node atau lebih, dan koneksi klien didistribusikan secara acak di antara node tersebut. Parameter Maximum Active Concurrent Statements dan Maximum Waiting Queue Length dikonfigurasi di tingkat node. Setiap node menghitung konkurensi dan panjang antrian secara independen, sehingga konkurensi aktual tidak dapat dikontrol secara tepat. Anggap jumlah node adalah N, dan konfigurasi per node adalah C (Maximum Active Concurrent Statements) dan Q (Maximum Waiting Queue Length). Rentang konkurensi klien adalah [C+Q, N×(C+Q)], dan rentang konkurensi aktif database adalah [C, N×C].

  • Setelah Anda mengonfigurasi aturan Pembatasan SQL apa pun, proxy harus menemplatkan setiap pernyataan SQL bisnis, menghasilkan pengenal unik, dan mencoba mencocokkannya dengan aturan, terlepas dari apakah ditemukan kecocokan atau tidak. Oleh karena itu, mengaktifkan Pembatasan SQL dapat menyebabkan penurunan kinerja penerusan sebesar 5% hingga 10%. Gunakan pembatasan hanya saat kueri SQL lambat secara signifikan memengaruhi operasi bisnis normal Anda. Setelah Anda menyelesaikan kueri SQL lambat tersebut, Anda dapat menonaktifkan aturan pembatasan di konsol. Aturan yang dinonaktifkan tidak berlaku tetapi disimpan, dan Anda dapat mengaktifkannya kembali kapan saja.

Praktik terbaik

Verifikasi aturan pembatasan

Karena aturan pembatasan dapat diterapkan pada akun dan database tertentu, Anda dapat membuat akun pengujian dan mengonfigurasi aturan dengan konkurensi atau QPS diatur ke 0 untuk memverifikasi apakah aturan tersebut dapat mencocokkan pernyataan SQL yang diinginkan.

Misalnya, Anda ingin membatasi pernyataan SQL berikut:

SELECT * FROM generate_series(1, 100000);
  1. Pastikan nama akun adalah test_usr, jenisnya adalah high-privilege account, dan statusnya adalah Available.

  2. Konfigurasikan aturan pembatasan untuk akun pengujian dan atur pernyataan konkuren aktif maksimum ke 0. Untuk detail cara mengonfigurasi aturan pembatasan, lihat Prosedur.

    Untuk Rule Type, pilih Throttle Active Concurrent Statements. Untuk Current Mode, pilih Template Match. Untuk Database Account Name, masukkan test_usr. Untuk SQL Template, masukkan select * from generate_series(1, 100000);.

  3. Verifikasi bahwa aturan berlaku. Aturan ini hanya berlaku untuk akun pengujian baru dan tidak memengaruhi layanan Anda saat ini. Setelah dikonfigurasi, sambungkan ke database melalui titik akhir yang dipilih dalam aturan dan eksekusi pernyataan SQL. Jika error yang diharapkan dikembalikan, aturan berfungsi dengan benar:

    SELECT * FROM generate_series(1, 100000);
    Current query is being throttled and waiting queue is full.

Menangani SQL lambat di produksi

  1. Siapkan lingkungan pengujian.

    • Siapkan instance ECS

      1. Buat instance ECS berbasis Linux. Untuk contoh ini, digunakan instance ECS yang menjalankan CentOS 7.6 64-bit. Untuk informasi selengkapnya, lihat Create an instance by using the wizard.

        Catatan

        Instance ECS dan kluster PolarDB harus berada di zona ketersediaan dan VPC yang sama.

      2. Instal tool pgbench pada instance ECS.

        sudo yum install postgresql-contrib
    • Siapkan kluster PolarDB

      1. Masuk ke halaman pembelian kluster PolarDB dan

      2. Jika kluster PolarDB dan instance ECS berada di zona ketersediaan yang sama, Anda dapat menggunakan titik akhir pribadi. Jika tidak, Anda harus mengajukan titik akhir publik. Tambahkan alamat IP instance ECS ke daftar putih kluster PolarDB. Untuk informasi selengkapnya, lihat

      3. Di konsol,

      4. Untuk memastikan aturan pembatasan yang dikonfigurasi selanjutnya berlaku pada koneksi yang sudah ada, konfigurasikan aturan placeholder di konsol dan nonaktifkan. Untuk informasi selengkapnya, lihat Prosedur.

        Catatan

        Langkah ini tidak diperlukan jika versi PolarProxy Anda 2.3.58 atau lebih baru, karena aturan pembatasan baru, yang dimodifikasi, atau dihapus berlaku secara real time untuk semua koneksi.

  2. Di instance ECS, gunakan pgbench untuk menyambung ke titik akhir kluster PolarDB dan inisialisasi data benchmark.

    pgbench -h <PolarDB cluster endpoint> -p <Port of PolarDB cluster endpoint> -i -s 10 -U <PolarDB database username> <Test database name>

    Kemudian, mulai uji stres. Gunakan mode tpcb-like bawaan pgbench untuk mensimulasikan workload aplikasi normal.

    pgbench -h <PolarDB cluster endpoint> -p <Port of PolarDB cluster endpoint> -P 1 -b tpcb-like -j 5 -c 10 -M prepared -T 6000 -U <PolarDB database username> <Test database name> 
  3. Simulasikan skenario SQL lambat. Buat sesi koneksi baru dan eksekusi pernyataan berikut di database pengujian:

    WITH t AS (SELECT md5(i::text) AS id FROM generate_series(1, 10000000) i) SELECT * FROM t ORDER BY id LIMIT 1;

    Pernyataan SQL ini mengonsumsi banyak sumber daya komputasi dan biasanya membutuhkan waktu sekitar 5 detik untuk mengembalikan hasil berikut:

                    id                
    ----------------------------------
     0000023f507999464aa2b78875b7e5d6
    (1 row)

    Jalankan pgbench lagi. Gunakan skrip kustom untuk menguji stres pernyataan SQL di atas. Mulai 10 koneksi untuk mensimulasikan beban kluster tinggi akibat kueri SQL lambat:

    echo "WITH t AS (SELECT md5(i::text) AS id FROM generate_series(1, 10000000) i) SELECT * FROM t ORDER BY id LIMIT 1;" > slow.sql
    pgbench -h <PolarDB cluster endpoint> -p <Port of PolarDB cluster endpoint> -P 1 -f slow.sql -j 5 -c 10 -M prepared -T 6000 -U <PolarDB database username> <Test database name> 

    Setelah uji stres dimulai, workload aplikasi normal awal turun drastis:

    progress: 11.0 s, 6324.2 tps, lat 1.581 ms stddev 0.454
    progress: 12.0 s, 6143.1 tps, lat 1.627 ms stddev 0.837
    progress: 13.0 s, 6251.8 tps, lat 1.599 ms stddev 0.464
    progress: 14.0 s, 6256.8 tps, lat 1.598 ms stddev 0.439
    progress: 15.0 s, 6201.0 tps, lat 1.612 ms stddev 0.536
    progress: 16.0 s, 6248.2 tps, lat 1.600 ms stddev 0.484
    progress: 17.0 s, 6290.0 tps, lat 1.589 ms stddev 0.439
    progress: 18.0 s, 6244.8 tps, lat 1.601 ms stddev 0.475
    progress: 19.0 s, 6195.0 tps, lat 1.613 ms stddev 0.576
    progress: 20.0 s, 6200.3 tps, lat 1.612 ms stddev 0.628
    progress: 21.0 s, 6099.7 tps, lat 1.640 ms stddev 0.666
    progress: 22.0 s, 5831.2 tps, lat 1.714 ms stddev 1.578
    progress: 23.0 s, 5122.8 tps, lat 1.952 ms stddev 3.239
    progress: 24.0 s, 5925.0 tps, lat 1.686 ms stddev 1.263
    progress: 25.0 s, 5677.0 tps, lat 1.763 ms stddev 1.606
    progress: 26.0 s, 5899.0 tps, lat 1.695 ms stddev 1.117
    progress: 27.0 s, 5832.0 tps, lat 1.714 ms stddev 2.484
    progress: 28.0 s, 6448.0 tps, lat 1.551 ms stddev 0.182
    progress: 29.0 s, 6449.0 tps, lat 1.550 ms stddev 0.187
    progress: 30.0 s, 1252.0 tps, lat 6.038 ms stddev 33.858
    progress: 31.0 s, 147.0 tps, lat 64.147 ms stddev 129.137
    progress: 32.0 s, 274.0 tps, lat 46.103 ms stddev 93.193
    progress: 33.0 s, 240.0 tps, lat 41.924 ms stddev 36.949
    progress: 34.0 s, 106.0 tps, lat 94.393 ms stddev 85.844
  4. Di konsol, konfigurasikan aturan pembatasan dengan templat SQL berikut, dan pilih Throttle Active Concurrent Statements sebagai jenis aturan:

    WITH t AS (SELECT md5(i::text) AS id FROM generate_series($1, $2) i) SELECT * FROM t ORDER BY id LIMIT $3;

    Untuk Current Mode, pilih Template Match. Untuk Database Account Name, masukkan test_usr. Untuk Database Name, masukkan test_db. Atur Maximum Waiting Queue Length ke 1024.

    Batasi konkurensi kueri SQL lambat menjadi 1. Setelah Anda mengaktifkan aturan, Anda dapat melihat workload aplikasi pulih, yang menunjukkan aturan pembatasan berlaku.

    progress: 56.0 s, 127.0 tps, lat 82.943 ms stddev 81.855
    progress: 57.0 s, 137.0 tps, lat 68.631 ms stddev 32.356
    progress: 58.0 s, 127.0 tps, lat 84.783 ms stddev 78.936
    progress: 59.0 s, 146.0 tps, lat 67.840 ms stddev 11.758
    progress: 60.0 s, 145.0 tps, lat 62.824 ms stddev 25.166
    progress: 61.0 s, 134.0 tps, lat 82.475 ms stddev 68.729
    progress: 62.0 s, 142.0 tps, lat 70.240 ms stddev 18.793
    progress: 63.0 s, 1994.1 tps, lat 5.134 ms stddev 14.502
    progress: 64.0 s, 3347.8 tps, lat 2.973 ms stddev 9.346
    progress: 65.0 s, 707.0 tps, lat 14.247 ms stddev 25.863
    progress: 66.0 s, 4410.0 tps, lat 2.273 ms stddev 5.326
    progress: 67.0 s, 5808.0 tps, lat 1.722 ms stddev 0.667
    progress: 68.0 s, 5436.0 tps, lat 1.840 ms stddev 3.052
    progress: 69.0 s, 6100.0 tps, lat 1.639 ms stddev 0.208
    progress: 70.0 s, 6107.0 tps, lat 1.638 ms stddev 0.204
    progress: 71.0 s, 6066.0 tps, lat 1.648 ms stddev 0.456
    progress: 72.0 s, 6086.0 tps, lat 1.643 ms stddev 0.202
  5. Di konsol, modifikasi aturan pembatasan. Di kolom Actions aturan target, klik Modify dan atur Maximum Active Concurrent Statements ke 0 untuk sepenuhnya memblokir kueri SQL lambat.

    Setelah konfigurasi, uji stres SQL lambat mengembalikan error dan terganggu. Pada titik ini, workload aplikasi sepenuhnya pulih.

    progress: 198.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
    progress: 199.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
    progress: 200.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
    progress: 201.0 s, 2.0 tps, lat 5733.302 ms stddev 39.976
    progress: 202.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
    pgbench: error: client 1 script 0 aborted in command 0 query 0: Current query is being throttled and waiting queue is full.
    pgbench: error: client 0 script 0 aborted in command 0 query 0: Current query is being throttled and waiting queue is full.
    pgbench: error: client 9 script 0 aborted in command 0 query 0: Current query is being throttled and waiting queue is full.
    pgbench: error: client 8 script 0 aborted in command 0 query 0: Current query is being throttled and waiting queue is full.
    pgbench: error: client 5 script 0 aborted in command 0 query 0: Current query is being throttled and waiting queue is full.
    pgbench: error: client 2 script 0 aborted in command 0 query 0: Current query is being throttled and waiting queue is full.
    pgbench: error: client 7 script 0 aborted in command 0 query 0: Current query is being throttled and waiting queue is full.
    pgbench: error: client 4 script 0 aborted in command 0 query 0: Current query is being throttled and waiting queue is full.
    pgbench: error: client 3 script 0 aborted in command 0 query 0: Current query is being throttled and waiting queue is full.
    pgbench: error: client 6 script 0 aborted in command 0 query 0: Current query is being throttled and waiting queue is full.
    transaction type: slow.sql
    scaling factor: 1
    query mode: prepared
    number of clients: 10
    number of threads: 5
    duration: 6000 s
    number of transactions actually processed: 112