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

Mengelola Aurora Postgre SQL RDS untuk koneksi Postgre churn

Ketika aplikasi klien terhubung dan terputus begitu sering sehingga waktu respons cluster Aurora SQL Postgre DB melambat, cluster dikatakan mengalami churn koneksi. Setiap koneksi baru ke titik akhir cluster Aurora Postgre SQL DB mengkonsumsi sumber daya, sehingga 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 meningkatkan waktu respons pada cluster Aurora SQL Postgre DB yang memiliki tingkat churn koneksi yang tinggi. Untuk melakukan ini, Anda dapat menggunakan pooler koneksi, seperti RDS Proxy. Pooler koneksi menyediakan cache koneksi siap pakai untuk klien. Hampir semua versi Aurora SQL Postgre mendukung Proxy. RDS Untuk informasi selengkapnya, lihat RDSProxy Amazon dengan Aurora Postgre SQL.

Jika versi spesifik Aurora Postgre Anda SQL tidak mendukung RDS Proxy, Anda dapat menggunakan pooler koneksi lain yang kompatibel dengan Postgre, sepertiSQL. PgBouncer Untuk mempelajari lebih lanjut, lihat situs PgBouncerweb.

Untuk melihat apakah cluster Aurora Postgre SQL DB Anda dapat memperoleh manfaat dari penyatuan koneksi, Anda dapat memeriksa file untuk koneksi dan pemutusan sambungan. postgresql.log Anda juga dapat menggunakan Performance Insights untuk mengetahui berapa banyak koneksi churn yang dialami cluster DB Aurora SQL Postgre Anda. Di bagian berikut ini, Anda dapat menemukan informasi tentang kedua topik tersebut.

Pencatatan log koneksi dan pemutusan koneksi

Postgre SQL log_connections dan log_disconnections parameter dapat menangkap koneksi dan pemutusan ke instance penulis dari cluster Aurora Postgre DB. SQL 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 Grup parameter cluster DB untuk cluster Amazon Aurora DB. Untuk memeriksa pengaturan, sambungkan ke titik akhir cluster DB Anda untuk Aurora SQL Postgre 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 SQL log Postgre untuk analisis dengan menjalankan aplikasi Anda dengan beban kerja dan periode waktu yang realistis. Anda dapat melihat file log di RDS konsol. Pilih instance penulis cluster Aurora Postgre SQL DB 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 Performance Insights untuk menilai jumlah churn koneksi pada klaster DB Aurora SQL Postgre -Compatible Edition Anda. Saat Anda membuat klaster SQL DB Aurora Postgre, pengaturan untuk Performance Insights 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 Performance Insights yang berjalan di klaster SQL DB Aurora Postgre, Anda dapat memilih metrik yang ingin dipantau. Anda dapat mengakses Wawasan Performa dari panel navigasi di konsol. Anda juga dapat mengakses Performance Insights dari tab Monitoring instance penulis untuk cluster SQL DB Aurora Postgre Anda, seperti yang ditunjukkan pada gambar berikut.

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

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 lebih lanjut tentang pgbench dan cara menggunakannya, lihat pgbench di dokumentasi Postgre. SQL

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 penyatuan koneksi RDS Proxy, upaya 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.

Untuk informasi selengkapnya tentang penggunaan Performance Insights dengan klaster DB Aurora SQL Postgre Anda, lihat. Memantau beban DB dengan Performance Insights 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 cluster Aurora Postgre SQL DB Anda memiliki masalah churn koneksi, Anda dapat menggunakan RDS Proxy untuk meningkatkan kinerja. 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 SQL klien Postgre yang dapat Anda instal dan jalankan dari mesin klien lokal Anda. Anda juga dapat menginstal dan menjalankannya dari EC2 instans Amazon yang Anda gunakan untuk mengelola klaster Aurora SQL Postgre DB Anda. Untuk informasi lebih lanjut, lihat pgbench di dokumentasi SQL Postgre.

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 sesuai kebutuhan untuk cluster Aurora SQL Postgre DB Anda. Anda membuat lingkungan pgbench dalam basis data pada instans penulis klaster Anda.

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.

Setelah lingkungan pgbench diatur, Anda kemudian dapat menjalankan pengujian tolok ukur dengan dan tanpa pooling koneksi. Tes default terdiri dari serangkaian limaSELECT,UPDATE, dan INSERT perintah per transaksi yang berjalan berulang kali untuk 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)

Menjalankan pgbench pada instance penulis cluster Aurora Postgre SQL DB tanpa menggunakan kembali koneksi menunjukkan 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 Aurora SQL Postgre DB cluster untuk jumlah pengguna 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 pengaturan RDS Proxy untuk klaster SQL DB Aurora Postgre Anda, lihat. Menggunakan Amazon RDS Proxy untuk Aurora