Temu Duga Backend: Bagaimana Anda Menentukan Saiz Kolam Sambungan Pangkalan Data dan Mendiagnosis Kehabisannya?

Masalah dan Skop

Sebuah platform pesanan yang menggunakan PostgreSQL menjalankan 100 tika API tanpa keadaan (stateless) dan 20 background worker. Pangkalan data mempunyai max_connections yang ditetapkan kepada 500. Migrasi, tindak balas insiden dan alat operasi memerlukan simpanan sebanyak 50, meninggalkan belanjawan seluruh aplikasi sebanyak 450 sambungan. Trafik puncak ialah 6,000 permintaan sesaat, kira-kira 70% daripada permintaan mengakses pangkalan data, dan jejak (trace) aplikasi menunjukkan bahawa sesuatu operasi pangkalan data memegang sambungan selama 40 milisaat secara purata. Sasaran p99 hujung-ke-hujung untuk permintaan API ialah 800 milisaat.

Setiap proses pada masa ini mempunyai kolam sebanyak 10, jadi penggunaan tersebut secara teorinya boleh mencipta 100 × 10 + 20 × 10 = 1,200 sesi pangkalan data. Pemerolehan sambungan mula tamat masa pada waktu puncak. Kadangkala CPU pangkalan data hanya 55%; pada masa lain, penantian kunci (lock waits) dan kependaman pertanyaan turut meningkat. Reka bentuk peruntukan kolam awal, dasar tamat masa dan kitaran hayat sambungan. Terangkan cara membezakan kolam tempatan bersaiz kecil, kebocoran sambungan, transaksi yang panjang, penskalaan replika yang melebihi belanjawan dan beban lampau di dalam pangkalan data.

Bilangan tika, daya pemprosesan, masa pegangan 40 milisaat dan had 500 sambungan adalah andaian temu duga, bukannya tuntutan prestasi universal untuk PostgreSQL, HikariCP atau PgBouncer. Panduan temu duga backend semasa masih menilai pertimbangan prestasi, kebolehpercayaan dan operasi dalam reka bentuk sistem, dan soalan reka bentuk kolam sambungan pangkalan data khusus telah diterbitkan pada tahun 2026. Kemahiran teras ialah menguruskan konkurensi pangkalan data dan pemilikan sumber merentas replika aplikasi, jadi kategorinya ialah backend.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah menganggap kolam sebagai kawalan kemasukan (admission control) konkurensi, bukan mengandaikan bahawa lebih banyak sambungan menghasilkan lebih banyak daya pemprosesan. max_connections PostgreSQL adalah untuk seluruh pangkalan data, dan meningkatkannya akan menambah peruntukan sumber. Angka yang dikonfigurasikan secara bebas pada satu tika mesti didarabkan dengan replika API, worker, tugas berjadual dan replika sementara semasa pelepasan bergolek (rolling release).

Isyarat kedua ialah menggunakan Hukum Little untuk semakan tertib magnitud tanpa membentangkan purata sebagai jawapan kapasiti. Kadar ketibaan purata pangkalan data ialah 6,000 × 70% = 4,200 operasi sesaat. Penghunian sambungan purata adalah kira-kira 4,200 × 0.04 = 168. Ini hanya menerangkan konkurensi purata keadaan mantap (steady-state). Lonjakan (bursts), masa pegangan p99, penantian kunci, percubaan semula transaksi dan ketidakseimbangan beban dalam kalangan replika masih memerlukan pengukuran dan ujian beban.

Isyarat ketiga ialah mencari lokasi giliran dengan bukti daripada kedua-dua belah pihak. Aplikasi harus mendedahkan kiraan aktif, melahu (idle) dan belum selesai (pending), kependaman pemerolehan dan tamat masa, serta masa pegangan sambungan. Pangkalan data harus mendedahkan keadaan pg_stat_activity, wait_event, pertanyaan aktif, transaksi melahu dan asal sambungan. Menaikkan kolam semata-mata kerana "pemerolehan sambungan tamat masa" mungkin hanya memindahkan giliran daripada aplikasi ke dalam pangkalan data.

Akhir sekali, jawapan harus mentakrifkan sempadan kegagalan. Reka bentuk yang mantap merangkumi tarikh akhir permintaan, kebocoran sambungan, transaksi panjang, pelepasan bergolek, penskalaan automatik, permulaan semula pangkalan data, sambungan basi (stale), dan perbezaan antara pengumpulan sesi dan transaksi PgBouncer. Ia juga menamakan ciri-ciri berskop sesi yang mungkin tidak selamat dengan pengumpulan transaksi.

Soalan Penjelasan Sebelum Menjawab

• Adakah had 500 dikenakan pada satu nod utama atau kluster yang lebih besar? Replika bacaan, sasaran failover dan akses operasi mungkin mempunyai belanjawan yang berbeza. Kira kolam secara berasingan untuk pangkalan data yang sebenarnya melayani setiap beban kerja.
• Berapakah bilangan replika maksimum? Adakah 100 tika API merupakan keadaan biasa atau maksimum penskalaan automatik? Pelepasan bergolek mungkin menjalankan replika lama dan baharu secara serentak buat sementara waktu. Konfigurasi yang hanya berasaskan replika keadaan mantap boleh melebihi belanjawan semasa pelepasan atau insiden.
• Bagaimanakah taburan masa pegangan sambungan? Purata 40 milisaat tidak menunjukkan p95, p99, panggilan rangkaian di dalam transaksi atau penantian kunci. Ekor panjang (long tail) mengawal giliran dan tamat masa, jadi segmenkannya mengikut laluan, tugas dan label transaksi.
• Bolehkah kerja latar belakang dimasukkan ke dalam giliran atau dihadkan konkurensinya? Kerja kelompok (batch) yang panjang tidak sepatutnya bersaing secara bebas dengan permintaan API yang singkat. Kolam yang berasingan adalah berguna, tetapi setiap kolam masih berkongsi belanjawan global 450 yang sama.
• Apakah percubaan semula yang berlaku selepas tamat masa? Percubaan semula serta-merta tanpa backoff meningkatkan kadar ketibaan tepat pada masa pangkalan data menjadi perlahan. Tamat masa pemerolehan mesti muat di dalam tarikh akhir permintaan dan berfungsi dengan kawalan kemasukan, backoff atau tindak balas kegagalan yang ditetapkan.
• Ciri-ciri berskop sesi yang manakah digunakan oleh aplikasi? Jadual sementara, LISTEN, kunci penasihat (advisory locks) sesi, keadaan SET merentas transaksi dan tingkah laku prepared-statement mempengaruhi sama ada pengumpulan transaksi PgBouncer adalah selamat.
• Di manakah proksi sambungan akan dijalankan? Satu tika PgBouncer mencipta sempadan kapasiti dan ketersediaan. Sidecar bagi setiap nod, lapisan proksi khusus dan proksi terurus mempunyai mod kegagalan yang berbeza.

Rangka Kerja Jawapan 30 Saat

"Saya akan bermula dengan belanjawan global. Memperuntukkan 50 daripada 500 sambungan meninggalkan 450 untuk aplikasi; had setiap proses semasa mengembang kepada 1,200. Konkurensi purata sebanyak 168 hanyalah semakan skala. Peruntukan awal boleh memberikan 2 kepada setiap tika API dan 4 kepada setiap worker, berjumlah 280 dengan 170 ruang tambahan (headroom), kemudian menala di bawah beban puncak. Tamat masa pemerolehan mesti muat di dalam tarikh akhir permintaan 800 milisaat. Saya akan membandingkan kiraan pending kolam, kependaman pemerolehan dan masa pegangan dengan pg_stat_activity serta peristiwa menunggu (wait events). Jika kolam beratur manakala pangkalan data mempunyai ruang tambahan, periksa kepencongan (skew), kebocoran dan had tempatan. Jika pertanyaan atau kunci sudah merosot, jangan besarkan kolam. Penskalaan automatik mesti mengira semula belanjawan, dan pengumpulan transaksi PgBouncer memerlukan audit keadaan sesi."

Perbincangan Mendalam Langkah Demi Langkah

Wujudkan Belanjawan Sambungan Global

Tulis belanjawan sebagai satu invarian yang eksplisit:

application_connection_cap
  = max_connections
  - operations_reserve
  = 500 - 50
  = 450

Jumlah semua had kolam API, worker, migrasi, pentadbiran dan pelepasan bergolek mesti kekal pada atau di bawah 450. Jika aplikasi lain menggunakan pangkalan data yang sama, tolak belanjawan mereka juga. Simpanan operasi bukanlah daya pemprosesan tambahan untuk trafik normal. Ia mengekalkan keupayaan untuk menyambung, memerhati dan membaiki pangkalan data semasa insiden.

Semakan konkurensi purata ialah:

database_arrival_rate = 6,000 × 70% = 4,200 operations/second
average_in_flight     = 4,200 × 0.04 seconds = 168

Ini dengan cepat menunjukkan bahawa 1,200 sambungan tidak dijustifikasikan oleh beban kerja purata dan 20 jumlah sambungan berkemungkinan terlalu sedikit. Ia tidak menghasilkan saiz kolam akhir kerana purata menyembunyikan lonjakan, masa pegangan p99, percubaan semula transaksi dan maklum balas giliran. Angka akhir mesti menggabungkan SLO perkhidmatan, konkurensi pangkalan data aktif yang mampan dan ujian beban.

Cadangkan Peruntukan Awal yang Boleh Diuji

Titik permulaan yang konservatif ialah 2 sambungan bagi setiap tika API dan 4 bagi setiap worker:

API cap      = 100 × 2 = 200
worker cap   = 20 × 4  = 80
allocated    = 280
app headroom = 450 - 280 = 170

Peruntukan worker sebanyak 4 hanyalah had terpencil awal, bukannya nilai yang terhasil secara langsung daripada "kerja yang lebih panjang." Nilai sebenar harus mengikut taburan masa pegangan, kadar ketibaan dan had konkurensi bagi setiap beban kerja. Dua ratus lapan puluh adalah calon yang menghormati belanjawan global dan boleh diuji beban; baki 170 tidak seharusnya diperuntukkan secara automatik. Jika replika API berkembang kepada 200, mengekalkan 2 bagi setiap replika menggunakan 400, dan 80 daripada worker menolak jumlah melebihi 450. Penskalaan mesti mengurangkan had setiap tika, mengehadkan replika maksimum atau menggunakan proksi untuk menguatkuasakan belanjawan sambungan pelayan yang lebih berpusat.

Jangan tetapkan minimumIdle yang besar semata-mata supaya setiap proses sentiasa mempunyai sambungan ganti. Sesi melahu masih menggunakan had global. Sesuatu kolam boleh berkembang atas permintaan sehingga maksimum yang ketat. Sama ada ia perlu mengekalkan bilangan minimum sambungan melahu mesti dijustifikasikan oleh kos penubuhan sambungan yang diukur dan kependaman lonjakan.

Tetapkan Tamat Masa Pemerolehan dan Jangka Hayat Sambungan

Tamat masa pemerolehan mestilah lebih pendek daripada baki tarikh akhir permintaan. Dengan sasaran p99 800 milisaat, benang (thread) tidak boleh menunggu 30 saat untuk mendapatkan sambungan. Ujian pertama boleh memberikan pemerolehan 100 hingga 200 milisaat dan melaraskannya daripada taburan giliran yang diukur. Julat tersebut ialah pilihan reka bentuk senario, bukan cadangan perpustakaan universal. Selepas tamat masa, kembalikan ralat beban lampau yang boleh dikenal pasti dan gunakan kawalan kemasukan huluan atau backoff bergetar (jittered backoff). Jangan cuba semula serta-merta tanpa had.

Jangka hayat sambungan maksimum hendaklah lebih pendek daripada sebarang jangka hayat paksa yang dikenakan oleh pangkalan data, proksi atau rangkaian, dan ia harus merangkumi getaran (jitter) supaya banyak sambungan tidak tamat tempoh bersama-sama. Keepalive adalah untuk sambungan melahu yang harus kekal sah dan mesti dijalankan lebih kerap daripada jangka hayat maksimum. Menguji setiap sambungan sebelum setiap pinjaman (borrow) menambah masa ulang-alik (round trip) dan memerlukan pengukuran. Lebih penting lagi, kendalikan operasi gagal pertama selepas permulaan semula pangkalan data atau failover dengan betul dan cuba semula operasi perniagaan yang idempoten sahaja.

Tentukan Sama Ada Kolam Aplikasi Merupakan Halangan (Bottleneck)

Setiap kolam harus mendedahkan sekurang-kurangnya metrik ini dengan label perkhidmatan, tika dan beban kerja:

• maksimum yang dikonfigurasikan, aktif, melahu dan belum selesai;
• kependaman pemerolehan p50, p95 dan p99 serta kiraan tamat masa;
• masa pegangan sambungan yang ditag mengikut laluan, tugas atau transaksi;
• kadar penciptaan, penutupan, pengesahan yang gagal dan penciptaan semula sambungan;
• had jumlah teori: maksimum kolam yang dikonfigurasikan didarab dengan bilangan replika semasa.

Tafsirkan kombinasi, bukan nilai yang terasing. Peningkatan kiraan pending dan kependaman pemerolehan dengan sambungan aktif tersekat pada had maksimum, manakala pangkalan data masih mempunyai sambungan aktif mampan dan ruang tambahan CPU, boleh menunjukkan kolam tempatan yang kecil, trafik senget (skewed) atau beberapa operasi yang memegang sambungan terlalu lama. Jika pinjaman aktif tidak pernah berkurang selepas permintaan selesai, atau tindanan (stack) kekal dalam kod aplikasi, sambungan mungkin tidak dikembalikan. Peningkatan mendadak dalam penciptaan dan penutupan sambungan boleh menunjukkan ketidakpadanan jangka hayat, tamat masa proksi atau isu rangkaian.

Gunakan skop sambungan berstruktur supaya laluan kejayaan, ralat, pembatalan dan pemulangan awal semuanya melepaskan sambungan. Ambang pengesanan kebocoran boleh membantu mencari laluan, tetapi ia tidak menggantikan taburan masa pegangan dan semakan kod. Ambang yang terlalu pendek akan melabelkan transaksi panjang yang sah sebagai kebocoran.

Gunakan Bukti PostgreSQL untuk Mengasingkan Beban Lampau Pangkalan Data

PostgreSQL mendedahkan satu baris pg_stat_activity bagi setiap proses pelayan. Kumpulkannya mengikut application_name, alamat klien, keadaan dan peristiwa menunggu. Mulakan dengan:

SELECT application_name, state, wait_event_type, wait_event, count(*)
FROM pg_stat_activity
WHERE datname = current_database()
GROUP BY application_name, state, wait_event_type, wait_event
ORDER BY count(*) DESC;

Kemudian cari sesi yang kekal melahu di dalam transaksi:

SELECT pid, application_name, xact_start, state_change, wait_event_type, wait_event
FROM pg_stat_activity
WHERE state = 'idle in transaction'
ORDER BY xact_start;

Jika sesi aktif, kependaman pertanyaan, penantian kunci atau I/O semakin merosot apabila kiraan sambungan meningkat, halangan berada dalam pertanyaan, transaksi atau sumber pangkalan data. Membesarkan kolam meningkatkan perebutan (contention). Jika pangkalan data menghampiri 500 sesi tetapi kebanyakannya adalah sesi aplikasi yang melahu, kolam melahu bagi setiap tika telah menggunakan belanjawan; kecilkannya atau perkenalkan pemultipleksan. Jika idle in transaction berterusan, baiki sempadan transaksi kerana sesi tersebut menggunakan sambungan dan mungkin mengekalkan kunci atau menghalang kemajuan vakum (vacuum).

Jumlah sesi tidak sama dengan pelaksanaan selari. Sesi melahu dan sesi yang menunggu kunci memerlukan penjelasan yang berbeza. CPU pada 55% tidak membuktikan kapasiti pangkalan data ganti: perebutan kunci, kependaman storan, satu partition panas atau laluan pelaksanaan bersiri boleh menyekat kerja pada CPU agregat yang rendah.

Asingkan Beban Kerja dan Ambil Kira Penskalaan

Apabila permintaan API yang pendek dan worker yang panjang berkongsi satu kolam, beberapa kerja kelompok boleh menyebabkan sekatan kepala barisan (head-of-line blocking). Berikan mereka kolam berasingan dan giliran konkurensi berasingan, seperti pembahagian 200/80 dalam senario ini. Pengasingan melindungi kependaman; ia tidak mencipta belanjawan yang lebih besar. Kolam worker harus dibenarkan mengecil apabila melahu, dan kerja itu sendiri memerlukan had konkurensi.

Penskala automatik mesti mengetahui belanjawan pangkalan data. Kekangan tegar paling mudah ialah:

max_replicas × pool_size_per_replica + other_pool_caps <= 450

Sertakan maxSurge penggunaan bergolek. Jika bilangan replika berubah secara meluas, had tetap setiap tika membazirkan kapasiti dengan replika yang sedikit dan melebihi belanjawan dengan replika yang banyak. Gunakan kolam tetap yang kecil berserta giliran permintaan, atau gunakan PgBouncer untuk memultiplekskan banyak sesi klien ke atas bilangan sambungan pelayan yang terkawal. Walau apa pun caranya, teruskan mengehadkan konkurensi aktif di dalam pangkalan data.

Tentukan Sama Ada Perlu Menggunakan PgBouncer

Pengumpulan sesi PgBouncer mengekalkan sambungan pelayan yang sama sehingga sesi klien berakhir. Ia menyokong tingkah laku sesi PostgreSQL dengan baik tetapi menyediakan kurang pemultipleksan. Pengumpulan transaksi memperuntukkan sambungan pelayan hanya sepanjang tempoh transaksi. Ia boleh menghalang klien melahu daripada memegang sambungan pelayan, tetapi ia menghapuskan andaian bahawa transaksi seterusnya menggunakan sesi pelayan yang sama.

Sebelum pengumpulan transaksi, audit SET/RESET merentas transaksi, LISTEN, kunci penasihat sesi, jadual sementara dan keadaan sesi lain. Jika aplikasi memerlukan semantik tersebut, kekalkan pengumpulan sesi, berikan laluan terpilih kolam langsung yang berasingan atau alihkan keadaan ke dalam transaksi. Kiraan sambungan yang lebih rendah sahaja tidak membuktikan kejayaan. Uji giliran proksi, kegagalan proksi, pengesahan, penciptaan semula sambungan dan failover pangkalan data.

Lengkapkan Gelung Kapasiti Dengan Ujian Kegagalan

Mulakan dengan beban bertingkat, tingkatkan ke arah 6,000 permintaan sesaat, kemudian tambah lonjakan dan penskalaan automatik. Pada setiap langkah rekodkan p95/p99 hujung-ke-hujung, kependaman pemerolehan, kiraan pending, masa pegangan, sesi pangkalan data aktif, penantian kunci, kependaman pertanyaan, CPU dan I/O. Bandingkan beberapa calon peruntukan di sekitar pembahagian awal 200/80 dan cari tempat daya pemprosesan berhenti berkembang atau kependaman pangkalan data dan giliran mula merosot.

Ujian permusuhan (adversarial tests) harus merangkumi laluan disuntik yang tidak mengembalikan sambungan, beberapa transaksi yang memegang sambungan selama beberapa saat, perebutan kunci, replika lama dan baharu yang berjalan semasa pelepasan bergolek, permulaan semula pangkalan data, proksi yang memutuskan sambungan pelayan sedia ada dan lonjakan tunggakan worker. Lulus bukan bermaksud "tiada ralat." Di bawah belanjawan sambungan global, sistem harus gagal dengan cepat (fail fast) atau melepaskan beban (shed load), metrik harus mengenal pasti giliran dan pemulihan tidak sepatutnya mencipta ribut sambungan (connection storm).

Contoh Jawapan Berkualiti Tinggi

"Saya akan membahagikan 500 sambungan pangkalan data kepada belanjawan sebelum memilih nombor bagi setiap tika. Memperuntukkan 50 untuk operasi meninggalkan 450 untuk aplikasi. Sebanyak 120 proses semasa dengan 10 setiap satu menghasilkan had teori sebanyak 1,200, jadi pelepasan bergolek dan lonjakan boleh melebihi had pangkalan data.

Maklumat yang diberikan menyatakan 4,200 operasi pangkalan data sesaat dan masa pegangan purata 40 milisaat. Hukum Little memberikan kira-kira 168 operasi serentak purata. Saya akan menggunakannya hanya sebagai semakan skala, bukan kapasiti p99. Peruntukan awal boleh memberikan 2 sambungan kepada setiap 100 replika API dan 4 kepada setiap 20 worker, berjumlah 280 dan meninggalkan 170 sambungan sebagai ruang tambahan aplikasi. Saya akan menguji beban calon di sekitar 280 dengan taburan masa pegangan sebenar, lonjakan dan perebutan kunci. Maksimum penskalaan automatik dan replika pelepasan bergolek perlu dimasukkan ke dalam formula; jika tidak, 200 replika API ditambah kolam worker akan melebihi 450.

Tamat masa pemerolehan mesti muat di dalam tarikh akhir permintaan 800 milisaat. Saya akan bermula dengan menguji 100 hingga 200 milisaat. Pada bahagian aplikasi, saya akan memantau aktif, melahu, pending, kependaman pemerolehan, kiraan tamat masa, masa pegangan dan penciptaan semula sambungan. Dalam PostgreSQL, saya akan mengumpulkan pg_stat_activity mengikut nama aplikasi dan memeriksa aktif, melahu, melahu-dalam-transaksi dan peristiwa menunggu. Jika kolam beratur manakala pangkalan data mempunyai ruang tambahan yang mampan, periksa kepencongan replika, had tempatan dan sambungan yang tidak dilepaskan. Jika pertanyaan, kunci atau I/O sudah merosot, kolam yang lebih besar hanya meningkatkan konkurensi pangkalan data. Jika kebanyakan sesi yang menghampiri max_connections adalah melahu, kecilkan kolam melahu setiap tika atau multiplekskannya melalui proksi.

Saya akan mengasingkan API pendek dan worker panjang dengan kolam dan had konkurensi yang berasingan, sambil mengekalkan jumlahnya di bawah 450. Jika PgBouncer diperlukan, saya akan memilih mod secara sengaja: pengumpulan sesi mengekalkan lebih banyak keserasian; pengumpulan transaksi memultipleks dengan lebih agresif tetapi memerlukan audit LISTEN, kunci penasihat sesi, jadual sementara dan SET merentas transaksi. Akhir sekali, saya akan mengesahkan p99, giliran, jumlah sambungan dan pemulihan dengan beban bertingkat, lonjakan, kebocoran, transaksi panjang, perebutan kunci, penggunaan bergolek, permulaan semula pangkalan data dan pemutusan proksi."

Kesilapan Biasa

• Menetapkan 20 sambungan kepada setiap tika → jumlah sesi menjadi tidak terkawal apabila bilangan replika berubah → tentukan belanjawan seluruh pangkalan data terlebih dahulu dan bahagikannya antara semua kolam dan replika maksimum.
• Mengkonfigurasi tepat 168 sambungan daripada purata → lonjakan, masa pegangan p99, penantian kunci dan granulariti peruntukan terlepas pandang → gunakan Hukum Little sebagai semakan skala, kemudian buat keputusan dengan taburan dan ujian beban.
• Meningkatkan kolam setiap kali pemerolehan tamat masa → giliran aplikasi boleh berpindah ke dalam kunci pangkalan data, I/O atau giliran CPU → periksa pending kolam dan sesi aktif pangkalan data, peristiwa menunggu dan kependaman pertanyaan secara bersama.
• Hanya melihat CPU pangkalan data → kunci, kependaman storan dan titik panas boleh menyekat sambungan pada CPU yang rendah → tafsirkan sesi mengikut keadaan dan peristiwa menunggu.
• Mengabaikan sambungan melahu → kolam melahu merentas banyak replika boleh menghabiskan max_connections terlebih dahulu → pantau had kolam didarabkan dengan bilangan replika dan kawal minimum melahu.
• Menganggap idle-in-transaction sebagai melahu biasa → transaksi boleh memegang kunci, mengekalkan snapshot lama dan menghalang pembersihan → cari permulaan transaksi dan sempadan kod serta gunakan tamat masa yang sesuai.
• Meletakkan setiap beban kerja dalam satu kolam → worker yang panjang menduduki sambungan yang diperlukan oleh API pendek → asingkan kolam dan giliran mengikut profil kependaman tanpa melebihi belanjawan global.
• Mengguna pakai PgBouncer dan menjadikannya lalai kepada pengumpulan transaksi → keadaan sesi boleh hilang antara transaksi atau mendarat pada sambungan pelayan yang lain → audit keserasian sebelum memilih mod pengumpulan.
• Mencuba semula semua ralat sambungan serta-merta → pemulihan pangkalan data menghadapi ribut sambungan dan kadar ketibaan yang lebih tinggi → hadkan percubaan semula, tambah backoff bergetar dan cuba semula operasi idempoten sahaja.
• Menguji keadaan mantap sahaja → pelepasan bergolek, penskalaan, transaksi panjang dan permulaan semula pangkalan data mendedahkan kegagalan belanjawan dan kitaran hayat → sertakannya dalam matriks penerimaan.

Soalan Susulan

Susulan 1: Mengapakah Sambungan yang Lebih Banyak Boleh Menjadikan Sistem Lebih Perlahan?

CPU pangkalan data, cache, kunci dan lebar jalur storan adalah terhad. Melangkaui konkurensi aktif yang mampan, lebih banyak sambungan meningkatkan pertukaran konteks (context switching), perebutan cache dan penantian kunci. Setiap pertanyaan menjadi lebih perlahan, yang memanjangkan masa pegangan sambungan dan menghasilkan maklum balas positif. Kolam kecil menyediakan giliran terhad dalam aplikasi, yang biasanya lebih mudah dikawal berbanding membiarkan setiap permintaan memasuki pangkalan data. Kolam tersebut masih tidak boleh terlalu kecil sehingga ia membiarkan kapasiti pangkalan data yang mampan tidak digunakan.

Susulan 2: Apakah yang Berubah Jika API Diskala kepada 200 Tika?

Mengekalkan 2 sambungan bagi setiap tika akan mencipta 400 sambungan API; 80 daripada worker akan menolak jumlah melebihi 450. Kurangkan setiap kolam API kepada 1 dan peruntukkan semula belanjawan worker, hadkan replika maksimum dan lonjakan pelepasan bergolek, atau multiplekskan klien dengan PgBouncer. Gunakan giliran lonjakan dan ujian konkurensi pangkalan data yang mampan untuk membuat keputusan. Penskala automatik tidak boleh melihat CPU sahaja sambil mengabaikan kapasiti pangkalan data hiliran.

Susulan 3: Bagaimanakah Anda Membuktikan Kebocoran dan Bukannya Pertanyaan yang Benar-benar Perlahan?

Kebocoran sering muncul sebagai pinjaman aktif yang hanya meningkat, permintaan pending yang berterusan dan permintaan yang telah pun selesai manakala sesi pangkalan datanya mungkin melahu. Kaitkan setiap pinjaman dengan laluan, tugas dan sampel tindanan; bandingkan masa pegangan dengan jangka hayat permintaan; dan periksa laluan pengecualian, pembatalan dan pemulangan awal. Jika sesi PostgreSQL kekal aktif atau menunggu pada kunci, jelaskan pertanyaan dan transaksi sebelum melabelkannya sebagai kebocoran.

Susulan 4: Bolehkah Anda Menggunakan Formula Saiz Kolam HikariCP Secara Terus?

(core_count × 2) + effective_spindle_count ialah heuristik permulaan dalam dokumentasi HikariCP, yang menyatakan secara eksplisit untuk menguji beban di sekitarnya. SSD, kadar hit cache, jenis pertanyaan dan pangkalan data jarak jauh mengubah hasilnya. Lebih penting lagi, apabila satu pangkalan data dikongsi oleh banyak replika aplikasi, mana-mana calon peringkat pangkalan data masih perlu dibahagikan dalam kalangan mereka. Formula tersebut tidak boleh menggantikan belanjawan global 450 atau bukti SLO sebenar.

Susulan 5: Adakah Prepared Statement Sentiasa Tidak Disokong Dengan Pengumpulan Transaksi PgBouncer?

Jangan buat tuntutan mutlak merentas setiap versi dan konfigurasi. Sahkan matriks ciri PgBouncer terhadap versi yang digunakan, sokongan prepared-statement peringkat protokol dan tetapan pemacu (driver). Pengumpulan transaksi masih tidak menjamin bahawa dua transaksi menggunakan sesi pelayan yang sama. Senaraikan semantik sesi sebenar yang diharapkan oleh aplikasi, sahkan ia dalam ujian integrasi, dan kemudian pilih pengumpulan transaksi, pengumpulan sesi atau kolam langsung untuk setiap laluan.

Susulan 6: Kependaman Pemerolehan Menurun Selepas Meningkatkan Kolam, tetapi p99 Hujung-ke-Hujung Meningkat. Mengapa?

Giliran telah berpindah daripada kolam aplikasi ke dalam pangkalan data. Dengan lebih banyak pertanyaan yang masuk bersama-sama, perebutan kunci, I/O atau giliran CPU meningkatkan masa pelaksanaan pertanyaan. Metrik pemerolehan yang lebih baik tidak bermakna kependaman pengguna yang lebih baik. Bandingkan p99 hujung-ke-hujung, tempoh pertanyaan pangkalan data, peristiwa menunggu dan daya pemprosesan, serta pilih titik konkurensi dengan jumlah kependaman terendah dan ruang tambahan yang stabil.