Prestasi PostgreSQL & Pengoptimuman Pertanyaan · Pelajaran

Mod Pengumpulan Transaksi berbanding Sesi

Pilih mod PgBouncer yang sesuai dan ketahui ciri yang tidak berfungsi dalam pengumpulan transaksi.

Pelajaran 2 daripada 413 langkah

Mod Pengumpulan Transaksi berbanding Sesi ialah pelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan percuma di CoddyKit. Ini ialah pelajaran 2 daripada 4. Sebanyak 3 pelajaran dalam laluan pembelajaran ini boleh dibaca sepenuhnya secara percuma — selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan praktikal dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus Prestasi PostgreSQL & Pengoptimuman Pertanyaan merangkumi sejumlah 4 pelajaran.

Mengapa Mod Pengumpulan Penting

Setiap proses pelayan belakang PostgreSQL menggunakan memori (work_mem, cache katalog, cache pelan) dan CPU. Beberapa ribu sambungan pelanggan yang melahu boleh memenuhi pelayan walaupun tiada apa-apa sedang dijalankan.

PgBouncer berada di antara aplikasi anda dengan PostgreSQL, lalu memultiplekskan banyak sambungan pelanggan kepada sekumpulan kecil sambungan pelayan sebenar. Tetapan pool_mode menentukan bila sambungan pelayan dikembalikan kepada kumpulan.

  • sesi — pelayan dipegang sepanjang sesi pelanggan
  • transaksi — pelayan dipegang hanya untuk satu transaksi
  • pernyataan — pelayan dilepaskan selepas setiap pernyataan

Mod Pengumpulan Sesi

Dalam pengumpulan sesi, sambungan pelayan diberikan kepada pelanggan apabila pelanggan bersambung dan hanya dikembalikan kepada kumpulan apabila pelanggan memutuskan sambungan.

Ini ialah mod paling selamat: pelanggan mendapat proses pelayan belakang khusus sepanjang jangka hayatnya, jadi setiap ciri PostgreSQL berfungsi tepat seperti sambungan terus. Kosnya ialah penggunaan semula yang lemah — pelanggan yang bersambung tetapi melahu masih mengikat satu sambungan pelayan.

; PgBouncer config: pgbouncer.ini
[pgbouncer]
pool_mode = session
max_client_conn = 10000
default_pool_size = 20

[databases]
appdb = host=127.0.0.1 port=5432 dbname=appdb

Mod Pengumpulan Transaksi

Dalam pengumpulan transaksi, sambungan pelayan diberikan hanya sepanjang satu transaksi. Sebaik sahaja transaksi dilakukan atau dibatalkan, proses pelayan belakang kembali ke kumpulan dan mungkin melayani pelanggan lain selepas itu.

Ini memberikan penggunaan semula yang jauh lebih baik: beribu-ribu pelanggan yang kebanyakannya melahu boleh berkongsi kumpulan kecil kerana sambungan pelayan hanya dipinjam semasa kerja aktif. Ini ialah mod yang disyorkan untuk aplikasi web dengan banyak permintaan yang berjangka hayat pendek.

[pgbouncer]
pool_mode = transaction
max_client_conn = 10000
default_pool_size = 20

; 10000 clients multiplexed onto only 20 backends

Pertukaran Teras

Keputusannya ialah antara penggunaan semula dengan keserasian ciri:

  • Sesi: keserasian penuh, penggunaan semula sambungan rendah.
  • Transaksi: penggunaan semula tinggi, tetapi apa-apa yang bergantung pada keadaan di luar transaksi boleh gagal.

Pemahaman utama: dalam mod transaksi, transaksi berturutan daripada pelanggan yang sama mungkin ditempatkan pada proses pelayan belakang yang berbeza. Apa-apa yang kekal pada sambungan antara transaksi adalah tidak selamat.

Perkara yang Gagal: Keadaan pada Peringkat Sesi

Oleh sebab proses pelayan belakang dikongsi antara pelanggan di antara transaksi, apa-apa keadaan berlingkup sesi yang ditetapkan dalam satu transaksi boleh tertiris kepada pelanggan lain atau hilang.

Perkara berikut lazimnya gagal dalam pengumpulan transaksi:

  • GUC sesi SET / SET SESSION (contohnya SET statement_timeout, SET search_path di luar transaksi)
  • Kunci nasihat pada peringkat sesi (pg_advisory_lock)
  • Langganan LISTEN / NOTIFY
  • Pemboleh ubah sesi tanpa parameter dan kursor WITH HOLD
-- Unsafe in transaction pooling: runs in its own tx,
-- the GUC is reset before your next query reuses a backend
SET statement_timeout = '5s';

-- Session advisory lock may be acquired on one backend
-- and never matched by the unlock on another
SELECT pg_advisory_lock(42);

Perkara yang Gagal: Pernyataan Prasedia

Pernyataan prasedia bernama disimpan pada proses pelayan belakang tertentu. Dalam mod transaksi, pelaksanaan seterusnya mungkin sampai pada proses pelayan belakang lain yang tidak pernah melihat pernyataan prasedia itu, lalu menyebabkan ralat seperti prepared statement "sN" does not exist.

Langkah mitigasi:

  • Nyahdayakan pernyataan prasedia pada sisi pelanggan, atau gunakan protokol ringkas/tanpa nama.
  • PgBouncer 1.21+ menyokong max_prepared_statements untuk menjejak dan menyediakan semula pernyataan bernama bagi setiap proses pelayan belakang secara automatik.
; PgBouncer 1.21+ : safely allow named prepared statements
; in transaction mode by tracking them per server connection
[pgbouncer]
pool_mode = transaction
max_prepared_statements = 200

Kekalkan Tetapan Dalam Transaksi

Jika anda memerlukan GUC seperti statement_timeout atau search_path di bawah pengumpulan transaksi, lingkupkannya kepada transaksi dengan SET LOCAL. Tetapan itu hanya berkuat kuasa sehingga transaksi berakhir, jadi ia tidak mungkin tertiris kepada pelanggan seterusnya pada proses pelayan belakang tersebut.

Gunakan corak ini dan bukannya SET biasa.

BEGIN;
  SET LOCAL statement_timeout = '5s';
  SET LOCAL search_path = analytics, public;

  SELECT count(*) FROM orders WHERE created_at >= now() - interval '1 day';
COMMIT;

Transaksi Panjang Mengikat Kumpulan

Pengumpulan transaksi hanya menggunakan semula proses pelayan belakang di antara transaksi. Pertanyaan yang berjalan lama atau melahu dalam transaksi memegang proses pelayan belakangnya sepanjang tempoh tersebut, sama seperti dalam mod sesi.

Jika ramai pelanggan membiarkan transaksi terbuka, kumpulan kecil akan kehabisan kapasiti dan permintaan baharu akan beratur. Lindunginya dengan cara berikut:

  • Tetapkan idle_in_transaction_session_timeout yang rendah pada pelayan.
  • Pastikan transaksi ringkas; jangan sekali-kali BEGIN kemudian menunggu I/O pada sisi aplikasi.
-- Server-side safety net (postgresql.conf or ALTER ROLE)
ALTER ROLE app_user SET idle_in_transaction_session_timeout = '10s';

-- Now an app that BEGINs and stalls gets its backend
-- reclaimed instead of starving the PgBouncer pool

Menentukan Saiz default_pool_size

Dalam pengumpulan transaksi, default_pool_size ialah bilangan proses pelayan belakang sebenar bagi setiap pasangan (pangkalan data, pengguna). Oleh sebab kerja diselang-selikan, anda memerlukan jauh lebih sedikit proses pelayan belakang berbanding pelanggan.

Titik permulaan yang biasa ialah kira-kira bilangan teras CPU yang tersedia untuk pertanyaan, bukannya bilangan pelanggan. Membesarkan kumpulan secara berlebihan hanya mengulangi masalah lonjakan sambungan yang cuba dielakkan dengan PgBouncer.

[pgbouncer]
pool_mode = transaction
default_pool_size = 20      ; ~ matches Postgres CPU capacity
min_pool_size = 5           ; keep warm backends ready
reserve_pool_size = 5       ; burst headroom
max_client_conn = 10000     ; how many apps can attach

Memeriksa Tingkah Laku Kumpulan

PgBouncer menyediakan pangkalan data pentadbir maya. Sambung kepadanya dan jalankan SHOW POOLS; untuk melihat, bagi setiap kumpulan, bilangan pelanggan yang aktif/menunggu serta bilangan sambungan pelayan yang aktif/melahu.

Jika cl_waiting sentiasa melebihi sifar, pelanggan sedang beratur untuk mendapatkan proses pelayan belakang — sama ada tingkatkan default_pool_size atau pendekkan transaksi.

-- psql -p 6432 pgbouncer
SHOW POOLS;
-- columns: database | user | cl_active | cl_waiting
--          sv_active | sv_idle | sv_used | pool_mode

SHOW STATS;   -- query/transaction throughput per database

Penggantian Mod Mengikut Pangkalan Data

Anda tidak perlu memilih satu mod untuk seluruh sistem. Tetapkan pool_mode lalai dan gantikannya bagi setiap pangkalan data. Pembahagian yang biasa:

  • Pangkalan data aplikasi OLTP utama dalam mod transaksi untuk penggunaan semula maksimum.
  • Pangkalan data legasi atau pentadbir yang menggunakan LISTEN/NOTIFY, kunci nasihat atau jadual sementara dalam mod sesi untuk ketepatan.
[databases]
; high-concurrency web traffic -> transaction reuse
appdb  = host=127.0.0.1 dbname=appdb pool_mode=transaction

; uses LISTEN/NOTIFY + session advisory locks -> keep session
jobsdb = host=127.0.0.1 dbname=jobsdb pool_mode=session

Semakan Pantas

Pilih tingkah laku yang betul di bawah pengumpulan transaksi PgBouncer.

Ringkasan

Pengumpulan sesi berbanding transaksi, dirumuskan:

  • Mod sesi: proses pelayan belakang dipegang sehingga pelanggan memutuskan sambungan. Keserasian ciri penuh, penggunaan semula rendah. Gunakannya untuk pangkalan data yang memerlukan LISTEN/NOTIFY, kunci nasihat sesi atau pernyataan prasedia yang berterusan.
  • Mod transaksi: proses pelayan belakang dilepaskan bagi setiap transaksi. Penggunaan semula tinggi untuk banyak permintaan ringkas, tetapi keadaan pada peringkat sesi boleh tertiris atau hilang.
  • Perkara yang gagal dalam mod transaksi: GUC SET biasa, pernyataan prasedia bernama, kunci nasihat sesi, LISTEN/NOTIFY, kursor WITH HOLD.
  • Pembaikan: SET LOCAL dalam transaksi, max_prepared_statements (1.21+), transaksi ringkas, idle_in_transaction_session_timeout dan penggantian pool_mode mengikut pangkalan data.
Percuma untuk bermula

Pelajari SQL dengan tutor kecerdasan buatan — percuma

Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.

Kursus
22
Pelajaran
88

Soalan Lazim

Adakah pelajaran “Mod Pengumpulan Transaksi berbanding Sesi” percuma?

Ya — sebanyak 3 pelajaran dalam laluan pembelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan, termasuk “Mod Pengumpulan Transaksi berbanding Sesi”, boleh dibaca sepenuhnya secara percuma di web ini. Selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan interaktif dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Kursus Prestasi PostgreSQL & Pengoptimuman Pertanyaan merangkumi sejumlah 4 pelajaran.

Apakah yang akan saya pelajari dalam “Mod Pengumpulan Transaksi berbanding Sesi”?

Pilih mod PgBouncer yang sesuai dan ketahui ciri yang tidak berfungsi dalam pengumpulan transaksi. Anda berlatih Prestasi PostgreSQL & Pengoptimuman Pertanyaan menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.

Adakah saya memerlukan pengalaman untuk memulakan Prestasi PostgreSQL & Pengoptimuman Pertanyaan?

Tiada pengalaman terdahulu diperlukan. Pembelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 2 daripada 4.

Berapa lamakah pelajaran “Mod Pengumpulan Transaksi berbanding Sesi” diambil?

Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.

Bolehkah saya menulis dan menjalankan kod dalam pelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan ini?

Ya. Setiap pelajaran Prestasi PostgreSQL & Pengoptimuman Pertanyaan menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.

Semua pelajaran dalam kursus ini

  1. Mengapa Sambungan Mahal dalam PostgreSQL
  2. Mod Pengumpulan Transaksi berbanding Sesi
  3. Menentukan Saiz Kumpulan Berdasarkan Bilangan Teras
  4. Mendiagnosis Ketepuan Kumpulan dan Baris Giliran
← Kembali ke Prestasi PostgreSQL & Pengoptimuman Pertanyaan