Mengelola churn koneksi Aurora PostgreSQL dengan pooling - Amazon Aurora
Logging koneksi dan pemutusan koneksiMendeteksi churn koneksiMenunjukkan manfaat dari pooling koneksi

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mengelola churn koneksi Aurora PostgreSQL dengan pooling

Ketika aplikasi klien terhubung dan terputus begitu sering sehingga waktu respons klaster DB Aurora PostgreSQL melambat, klaster dikatakan mengalami churn koneksi. Setiap koneksi baru ke titik akhir klaster DB Aurora PostgreSQL menghabiskan sumber daya, sehingga akan mengurangi sumber daya yang dapat digunakan untuk memproses beban kerja yang sebenarnya. Churn koneksi adalah masalah yang kami sarankan agar Anda kelola dengan mengikuti beberapa praktik terbaik yang dibahas berikut.

Sebagai permulaan, Anda dapat mempersingkat waktu respons pada klaster DB Aurora PostgreSQL yang memiliki tingkat churn koneksi yang tinggi. Untuk melakukannya, Anda dapat menggunakan pooler koneksi, seperti Proksi RDS. Pooler koneksi menyediakan cache koneksi siap pakai untuk klien. Hampir semua versi Aurora PostgreSQL mendukung Proksi RDS. Untuk informasi selengkapnya, lihat Proksi Amazon RDS dengan Aurora PostgreSQL.

Jika versi spesifik Aurora PostgreSQL Anda tidak mendukung Proksi RDS, Anda dapat menggunakan pooler koneksi lain yang kompatibel dengan PostgreSQL, seperti PgBouncer. Untuk mempelajari selengkapnya, lihat situs web PgBouncer.

Untuk melihat apakah klaster DB Aurora PostgreSQL Anda dapat memperoleh manfaat dari pooling koneksi, Anda dapat memeriksa file postgresql.log apakah ada koneksi dan pemutusan koneksi. Anda juga dapat menggunakan Wawasan Performa untuk mengetahui jumlah koneksi churn yang dialami klaster DB Aurora PostgreSQL Anda. Di bagian berikut ini, Anda dapat menemukan informasi tentang kedua topik tersebut.

Logging koneksi dan pemutusan koneksi

Parameter log_connections dan log_disconnections PostgreSQL dapat menangkap koneksi dan pemutusan koneksi ke instans penulis klaster DB Aurora PostgreSQL. Secara default, parameter ini dinonaktifkan. Untuk mengaktifkan parameter ini, gunakan grup parameter kustom dan aktifkan dengan mengubah nilainya menjadi 1. Untuk informasi selengkapnya tentang grup parameter kustom, lihat Menggunakan grup parameter klaster DB. Untuk memeriksa pengaturan, hubungkan ke titik akhir klaster DB Anda untuk Aurora PostgreSQL dengan menggunakan psql dan kueri sebagai berikut.

labdb=> SELECT setting FROM pg_settings
  WHERE name = 'log_connections';
 setting
---------
on
(1 row)
labdb=> SELECT setting FROM pg_settings
  WHERE name = 'log_disconnections';
setting
---------
on
(1 row)

Dengan kedua parameter ini diaktifkan, log akan menangkap semua koneksi dan pemutusan koneksi baru. Anda melihat pengguna dan basis data untuk setiap koneksi baru yang diotorisasi. Pada waktu pemutusan koneksi, durasi sesi juga dicatat dalam log, seperti yang ditunjukkan pada contoh berikut.

2022-03-07 21:44:53.978 UTC [16641] LOG: connection authorized: user=labtek database=labdb application_name=psql
2022-03-07 21:44:55.718 UTC [16641] LOG: disconnection: session time: 0:00:01.740 user=labtek database=labdb host=[local]

Untuk memeriksa churn koneksi aplikasi Anda, aktifkan parameter ini jika belum aktif. Kemudian kumpulkan data di log PostgreSQL untuk analisis dengan menjalankan aplikasi Anda dengan beban kerja dan periode waktu yang realistis. Anda dapat melihat file log di konsol RDS. Pilih instans penulis klaster DB Aurora PostgreSQL Anda, lalu pilih tab Log & peristiwa. Untuk informasi selengkapnya, lihat Melihat dan mencantumkan file log basis data.

Atau, Anda dapat mengunduh file log dari konsol dan menggunakan urutan perintah berikut. Urutan ini menemukan jumlah total koneksi yang diotorisasi dan diputus per menit. 

grep "connection authorized\|disconnection: session time:" postgresql.log.2022-03-21-16|\
awk {'print $1,$2}' |\
sort |\
uniq -c |\
sort -n -k1

Dalam contoh output ini, Anda dapat melihat lonjakan koneksi yang diotorisasi diikuti dengan pemutusan koneksi mulai dari 16:12:10.

.....
,......
.........
5 2022-03-21 16:11:55 connection authorized:
9 2022-03-21 16:11:55 disconnection: session
5 2022-03-21 16:11:56 connection authorized:
5 2022-03-21 16:11:57 connection authorized:
5 2022-03-21 16:11:57 disconnection: session
32 2022-03-21 16:12:10 connection authorized:
30 2022-03-21 16:12:10 disconnection: session
31 2022-03-21 16:12:11 connection authorized:
27 2022-03-21 16:12:11 disconnection: session
27 2022-03-21 16:12:12 connection authorized:
27 2022-03-21 16:12:12 disconnection: session
41 2022-03-21 16:12:13 connection authorized:
47 2022-03-21 16:12:13 disconnection: session
46 2022-03-21 16:12:14 connection authorized:
41 2022-03-21 16:12:14 disconnection: session
24 2022-03-21 16:12:15 connection authorized:
29 2022-03-21 16:12:15 disconnection: session
28 2022-03-21 16:12:16 connection authorized:
24 2022-03-21 16:12:16 disconnection: session
40 2022-03-21 16:12:17 connection authorized:
42 2022-03-21 16:12:17 disconnection: session
40 2022-03-21 16:12:18 connection authorized:
40 2022-03-21 16:12:18 disconnection: session
.....
,......
.........
1 2022-03-21 16:14:10 connection authorized:
1 2022-03-21 16:14:10 disconnection: session
1 2022-03-21 16:15:00 connection authorized:
1 2022-03-21 16:16:00 connection authorized:

Dengan informasi ini, Anda dapat memutuskan apakah beban kerja Anda dapat memperoleh manfaat dari pooler koneksi. Untuk analisis yang lebih mendetail, Anda dapat menggunakan Wawasan Performa.

Mendeteksi churn koneksi dengan Wawasan Performa

Anda dapat menggunakan Wawasan Performa untuk menilai jumlah koneksi pada klaster DB Aurora PostgreSQL-Compatible Edition. Saat Anda membuat klaster DB Aurora PostgreSQL, pengaturan untuk Wawasan Performa diaktifkan secara default. Jika Anda menghapus pilihan ini saat membuat klaster DB, ubah klaster Anda agar mengaktifkan fitur tersebut. Untuk informasi selengkapnya, lihat Memodifikasi klaster DB Amazon Aurora.

Dengan Wawasan Performa yang berjalan di klaster DB Aurora PostgreSQL, Anda dapat memilih metrik yang ingin dipantau. Anda dapat mengakses Wawasan Performa dari panel navigasi di konsol. Anda juga dapat mengakses Wawasan Performa dari tab Pemantauan untuk instans penulis klaster DB Aurora PostgreSQL Anda, seperti yang ditunjukkan pada gambar berikut.

Gambar Wawasan Performa yang diakses dari dalam konsol RDS dan klaster DB Aurora PostgreSQL yang dipilih.

Dari konsol Wawasan Performa, pilih Kelola metrik. Untuk menganalisis aktivitas koneksi dan pemutusan koneksi klaster DB Aurora PostgreSQL Anda, pilih metrik berikut. Ini semua adalah metrik dari PostgreSQL.

  • xact_commit – Jumlah transaksi yang dikomit.

  • total_auth_attempts – Jumlah percobaan koneksi pengguna yang diautentikasi per menit.

  • numbackends – Jumlah backend yang saat ini terhubung ke basis data.

Gambar Wawasan Performa yang diakses dari dalam konsol RDS dan klaster DB Aurora PostgreSQL yang dipilih.

Untuk menyimpan pengaturan dan menampilkan aktivitas koneksi, pilih Perbarui grafik.

Pada gambar berikut, Anda dapat melihat dampak dari pgbench yang dijalankan dengan 100 pengguna. Garis yang menunjukkan koneksi berada pada kemiringan ke atas yang konsisten. Untuk mempelajari selengkapnya tentang pgbench dan cara menggunakannya, lihat pgbench dalam dokumentasi PostgreSQL.

Gambar Wawasan Performa yang menunjukkan perlunya pooling koneksi.

Gambar ini menunjukkan bahwa menjalankan beban kerja dengan sedikitnya 100 pengguna tanpa pooler koneksi dapat menyebabkan peningkatan yang signifikan dalam jumlah total_auth_attempts selama durasi pemrosesan beban kerja.

Dengan pooling koneksi Proksi RDS, percobaan koneksi meningkat pada awal beban kerja. Setelah mengatur pool koneksi, rata-ratanya menurun. Sumber daya yang digunakan oleh transaksi dan penggunaan backend tetap konsisten selama pemrosesan beban kerja.

Gambar Wawasan Performa yang menunjukkan manfaat Proksi RDS untuk pooling koneksi.

Untuk informasi selengkapnya tentang cara menggunakan Wawasan Performa dengan klaster DB Aurora PostgreSQL, lihat Memantau muatan DB dengan Wawasan Performa di Amazon Aurora. Untuk menganalisis metrik, lihat Menganalisis metrik dengan dasbor Wawasan Performa.

Menunjukkan manfaat dari pooling koneksi

Seperti disebutkan sebelumnya, jika Anda menentukan bahwa klaster DB Aurora PostgreSQL Anda memiliki masalah churn koneksi, Anda dapat menggunakan Proksi RDS untuk meningkatkan performa. Di bagian berikut ini, Anda dapat menemukan contoh yang menunjukkan perbedaan dalam memproses beban kerja saat koneksi di-pool dan saat tidak. Contoh ini menggunakan pgbench untuk memodelkan beban kerja transaksi.

Seperti psql, pgbench adalah aplikasi klien PostgreSQL yang dapat Anda instal dan jalankan dari mesin klien lokal Anda. Anda juga dapat menginstal dan menjalankannya dari instans Amazon EC2 yang Anda gunakan untuk mengelola klaster DB Aurora PostgreSQL Anda. Untuk informasi selengkapnya, lihat pgbench dalam dokumentasi PostgreSQL.

Untuk mempelajari contoh ini, pertama-tama Anda perlu membuat lingkungan pgbench dalam basis data Anda. Perintah berikut adalah templat dasar untuk menginisialisasi tabel pgbench dalam basis data yang ditentukan. Contoh ini menggunakan akun pengguna utama default, postgres, untuk login. Ubah akunnya sesuai kebutuhan untuk klaster DB Aurora PostgreSQL Anda. Anda membuat lingkungan pgbench dalam basis data pada instans penulis klaster Anda.

catatan

Proses inisialisasi pgbench menghapus dan membuat ulang tabel bernama pgbench_accounts, pgbench_branches, pgbench_history, dan pgbench_tellers. Pastikan basis data yang Anda pilih untuk dbname ketika Anda menginisialisasi pgbench tidak menggunakan nama-nama ini.

pgbench -U postgres -h db-cluster-instance-1.111122223333.aws-region.rds.amazonaws.com -p 5432 -d -i -s 50 dbname

Untuk pgbench, tentukan parameter berikut.

-d

Menghasilkan laporan debugging saat pgbench berjalan.

-h

Menentukan titik akhir instans penulis klaster DB Aurora PostgreSQL.

-i

Menginisialisasi lingkungan pgbench dalam basis data untuk pengujian tolok ukur.

-p

Mengidentifikasi port yang digunakan untuk koneksi basis data. Port default untuk Aurora PostgreSQL biasanya adalah 5432 atau 5433.

-s

Menentukan faktor penskalaan yang akan digunakan untuk mengisi tabel dengan baris. Faktor penskalaan default adalah 1, yang menghasilkan 1 baris dalam tabel pgbench_branches, 10 baris dalam tabel pgbench_tellers, dan 100.000 baris dalam tabel pgbench_accounts.

-U

Menentukan akun pengguna untuk instans penulis klaster DB Aurora PostgreSQL.

Setelah lingkungan pgbench diatur, Anda kemudian dapat menjalankan pengujian tolok ukur dengan dan tanpa pooling koneksi. Pengujian default terdiri dari serangkaian lima perintah SELECT, UPDATE, dan INSERT per transaksi yang berjalan berulang kali selama waktu yang ditentukan. Anda dapat menentukan faktor penskalaan, jumlah klien, dan detail lainnya untuk memodelkan kasus penggunaan Anda sendiri.

Sebagai contoh, perintah yang ditampilkan berikutnya akan menjalankan tolok ukur selama 60 detik (opsi -T, untuk waktu) dengan 20 koneksi konkuren (opsi -c). Opsi -C membuat pengujian menggunakan koneksi baru setiap kali dijalankan, bukan sekali per sesi klien. Pengaturan ini memberi Anda indikasi overhead koneksi. 

pgbench -h docs-lab-apg-133-test-instance-1.c3zr2auzukpa.us-west-1.rds.amazonaws.com -U postgres -p 5432 -T 60 -c 20 -C labdb
Password:**********
pgbench (14.3, server 13.3)
  starting vacuum...end.
  transaction type: <builtin: TPC-B (sort of)>
    scaling factor: 50
    query mode: simple
    number of clients: 20
    number of threads: 1
    duration: 60 s
    number of transactions actually processed: 495
    latency average = 2430.798 ms
    average connection time = 120.330 ms
    tps = 8.227750 (including reconnection times)

Dengan menjalankan pgbench pada instans penulis klaster DB Aurora PostgreSQL tanpa menggunakan kembali koneksi, akan terlihat bahwa hanya sekitar 8 transaksi yang diproses setiap detik. Artinya, ada total 495 transaksi selama pengujian 1 menit.

Jika Anda menggunakan kembali koneksi, respons dari klaster DB Aurora PostgreSQL untuk jumlah pengguna tersebut hampir 20 kali lebih cepat. Dengan penggunaan kembali koneksi, total 9.042 transaksi diproses dibandingkan dengan 495 dalam jumlah waktu yang sama dan untuk jumlah koneksi pengguna yang sama. Perbedaannya adalah bahwa dalam contoh berikut ini, setiap koneksi digunakan kembali.

pgbench -h docs-lab-apg-133-test-instance-1.c3zr2auzukpa.us-west-1.rds.amazonaws.com -U postgres -p 5432 -T 60 -c 20 labdb
Password:*********
pgbench (14.3, server 13.3)
      starting vacuum...end.
      transaction type: <builtin: TPC-B (sort of)>
      scaling factor: 50
      query mode: simple
      number of clients: 20
      number of threads: 1
      duration: 60 s
      number of transactions actually processed: 9042
      latency average = 127.880 ms
      initial connection time = 2311.188 ms
      tps = 156.396765 (without initial connection time)

Contoh ini menunjukkan kepada Anda bahwa pooling koneksi dapat secara signifikan mempersingkat waktu respons. Untuk informasi tentang cara menyiapkan Proksi RDS untuk klaster DB Aurora PostgreSQL Anda, lihat Menggunakan Proksi Amazon RDS untuk Aurora.