PostgreSQL प्रदर्शन और क्वेरी अनुकूलन · पाठ

Transaction और Session Pooling Modes

सही PgBouncer mode चुनें और जानें कि transaction pooling में कौन-सी सुविधाएँ काम करना बंद कर देती हैं।

पाठ 2, कुल 4 में से13 चरण

Transaction और Session Pooling Modes, CoddyKit पर PostgreSQL प्रदर्शन और क्वेरी अनुकूलन का एक निःशुल्क पाठ है। यह 4 में से 2वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह PostgreSQL प्रदर्शन और क्वेरी अनुकूलन सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

पूलिंग मोड क्यों महत्वपूर्ण हैं

हर PostgreSQL बैकएंड प्रक्रिया मेमोरी (work_mem, कैटलॉग कैश, प्लान कैश) और CPU खर्च करती है। कुछ हजार निष्क्रिय क्लाइंट कनेक्शन भी सर्वर को पूरी तरह व्यस्त कर सकते हैं, भले ही कुछ चल नहीं रहा हो।

PgBouncer आपके ऐप और PostgreSQL के बीच रहकर अनेक क्लाइंट कनेक्शनों को कुछ वास्तविक सर्वर कनेक्शनों पर साझा करता है। pool_mode सेटिंग तय करती है कि सर्वर कनेक्शन कब पूल को वापस दिया जाएगा।

सत्र — क्लाइंट के पूरे सत्र तक सर्वर कनेक्शन उसी के पास रहता है
लेन-देन — सर्वर कनेक्शन केवल एक लेन-देन तक रखा जाता है
कथन — प्रत्येक कथन के बाद सर्वर कनेक्शन वापस कर दिया जाता है

सत्र पूलिंग मोड

सत्र पूलिंग में, क्लाइंट के कनेक्ट होने पर उसे एक सर्वर कनेक्शन दिया जाता है और क्लाइंट के डिस्कनेक्ट होने पर ही वह कनेक्शन पूल में लौटता है।

यह सबसे सुरक्षित मोड है: क्लाइंट को अपने पूरे जीवनकाल के लिए समर्पित बैकएंड मिलता है, इसलिए हर PostgreSQL सुविधा ठीक उसी तरह काम करती है जैसे सीधे कनेक्ट करने पर करती। इसकी कीमत कम पुनः उपयोग है—कनेक्टेड लेकिन निष्क्रिय क्लाइंट भी सर्वर कनेक्शन को अपने लिए रोककर रखता है।

; 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

लेन-देन पूलिंग मोड

लेन-देन पूलिंग में, सर्वर कनेक्शन केवल एक लेन-देन की अवधि के लिए दिया जाता है। लेन-देन के कमिट या रोलबैक होते ही बैकएंड पूल में लौट जाता है और अगली बार किसी दूसरे क्लाइंट की सेवा कर सकता है।

इससे पुनः उपयोग बहुत बेहतर हो जाता है: अधिकतर समय निष्क्रिय रहने वाले हजारों क्लाइंट छोटे से पूल को साझा कर सकते हैं, क्योंकि सर्वर कनेक्शन केवल सक्रिय कार्य के दौरान उधार लिया जाता है। अनेक कम-अवधि वाले अनुरोधों वाले वेब ऐप के लिए यही अनुशंसित मोड है।

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

; 10000 clients multiplexed onto only 20 backends

मुख्य समझौता

निर्णय पुनः उपयोग और सुविधा-संगतता के बीच है:

सत्र: पूर्ण संगतता, कम कनेक्शन पुनः उपयोग।
लेन-देन: अधिक पुनः उपयोग, लेकिन लेन-देन के बाहर की स्थिति पर निर्भर कोई भी चीज़ विफल हो सकती है।

मुख्य बात: लेन-देन मोड में, एक ही क्लाइंट के लगातार लेन-देन अलग-अलग बैकएंड पर पहुँच सकते हैं। लेन-देन के बीच कनेक्शन पर मौजूद रहने वाली कोई भी चीज़ सुरक्षित नहीं है।

क्या टूटता है: सत्र-स्तरीय स्थिति

चूँकि लेन-देन के बीच बैकएंड अलग-अलग क्लाइंट के बीच साझा होता है, इसलिए किसी एक लेन-देन में निर्धारित कोई भी सत्र-सीमित स्थिति दूसरे क्लाइंट तक पहुँच सकती है या खो सकती है।

लेन-देन पूलिंग में ये चीज़ें अक्सर टूट जाती हैं:

SET / SET SESSION सत्र GUC (जैसे SET statement_timeout, लेन-देन के बाहर SET search_path)
सत्र-स्तरीय सलाहकार लॉक (pg_advisory_lock)
LISTEN / NOTIFY सदस्यताएँ
पैरामीटर-विहीन सत्र चर और 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);

क्या टूटता है: पहले से तैयार कथन

नामित पहले से तैयार कथन किसी विशिष्ट बैकएंड पर संग्रहीत होते हैं। लेन-देन मोड में अगला निष्पादन किसी ऐसे अलग बैकएंड पर पहुँच सकता है जिसने उस पहले से तैयार कथन को कभी देखा ही नहीं; इससे prepared statement "sN" does not exist जैसी त्रुटियाँ आती हैं।

उपाय:

क्लाइंट-साइड पहले से तैयार कथन बंद करें या सरल/अनाम प्रोटोकॉल का उपयोग करें।
PgBouncer 1.21+ में max_prepared_statements की सुविधा है, जो नामित कथनों को हर बैकएंड के लिए स्वतः ट्रैक करके फिर से तैयार करती है।

; 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

सेटिंग को लेन-देन के भीतर रखें

यदि लेन-देन पूलिंग में आपको statement_timeout या search_path जैसे GUC की आवश्यकता है, तो उसे SET LOCAL के साथ लेन-देन तक सीमित करें। यह केवल लेन-देन समाप्त होने तक लागू रहता है, इसलिए उस बैकएंड पर अगले क्लाइंट तक कभी नहीं पहुँच सकता।

साधारण SET के बजाय इस तरीके का उपयोग करें।

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

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

लंबे लेन-देन पूल को रोककर रखते हैं

लेन-देन पूलिंग केवल लेन-देन के बीच बैकएंड का पुनः उपयोग करती है। लंबे समय तक चलने वाली या idle-in-transaction क्वेरी पूरे समय अपना बैकएंड रोककर रखती है, ठीक वैसे ही जैसे सत्र मोड में होता।

यदि कई क्लाइंट खुले हुए लेन-देन रोककर रखते हैं, तो छोटा पूल खाली हो जाता है और नए अनुरोध कतार में लगते हैं। इससे बचने के लिए:

सर्वर पर idle_in_transaction_session_timeout का मान कम रखें।
लेन-देन छोटे रखें; BEGIN के बाद ऐप की ओर से होने वाले I/O का इंतज़ार कभी न करें।

-- 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

default_pool_size का आकार तय करना

लेन-देन पूलिंग में, default_pool_size प्रत्येक (डेटाबेस, उपयोगकर्ता) जोड़ी के लिए वास्तविक बैकएंड की संख्या है। चूँकि काम बारी-बारी से किया जाता है, इसलिए आपको क्लाइंट की संख्या से बहुत कम बैकएंड चाहिए।

एक सामान्य शुरुआती बिंदु क्वेरी के लिए उपलब्ध CPU कोर की संख्या है, क्लाइंट की संख्या नहीं। पूल का आकार बहुत बड़ा करने से वही कनेक्शन-तूफान की समस्या फिर पैदा हो जाती है जिससे बचने के लिए आपने 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

पूल के व्यवहार का निरीक्षण

PgBouncer एक वर्चुअल प्रशासनिक डेटाबेस उपलब्ध कराता है। उससे कनेक्ट करके SHOW POOLS; चलाएँ और प्रत्येक पूल में सक्रिय/प्रतीक्षारत क्लाइंट तथा सक्रिय/निष्क्रिय सर्वर कनेक्शनों की संख्या देखें।

यदि cl_waiting लगातार शून्य से अधिक है, तो क्लाइंट बैकएंड के लिए कतार में लग रहे हैं—या तो default_pool_size बढ़ाएँ या लेन-देन छोटे करें।

-- 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

प्रति-डेटाबेस मोड ओवरराइड

आपको पूरे स्तर पर केवल एक मोड चुनना आवश्यक नहीं है। एक डिफ़ॉल्ट pool_mode निर्धारित करें और प्रत्येक डेटाबेस के लिए उसे बदलें। एक सामान्य विभाजन इस प्रकार है:

अधिकतम पुनः उपयोग के लिए मुख्य OLTP ऐप डेटाबेस को लेन-देन मोड में रखें।
LISTEN/NOTIFY, सलाहकार लॉक या अस्थायी तालिकाओं का उपयोग करने वाले पुराने या प्रशासनिक डेटाबेस को सही व्यवहार के लिए सत्र मोड में रखें।

[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

त्वरित जाँच

PgBouncer लेन-देन पूलिंग में सही व्यवहार चुनें।

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावलोकन

सत्र बनाम लेन-देन पूलिंग, संक्षेप में:

सत्र मोड: क्लाइंट के डिस्कनेक्ट होने तक बैकएंड उसी के पास रहता है। पूर्ण सुविधा-संगतता, कम पुनः उपयोग। इसका उपयोग उन डेटाबेस के लिए करें जिन्हें LISTEN/NOTIFY, सत्र सलाहकार लॉक या स्थायी रूप से तैयार कथनों की आवश्यकता होती है।
लेन-देन मोड: प्रत्येक लेन-देन के बाद बैकएंड वापस कर दिया जाता है। कई छोटे अनुरोधों के लिए अधिक पुनः उपयोग, लेकिन सत्र-स्तरीय स्थिति पहुँच सकती है या गायब हो सकती है।
लेन-देन मोड में टूटने वाली चीज़ें: साधारण SET GUC, नामित पहले से तैयार कथन, सत्र सलाहकार लॉक, LISTEN/NOTIFY और WITH HOLD कर्सर।
उपाय: लेन-देन के भीतर SET LOCAL, max_prepared_statements (1.21+), छोटे लेन-देन, idle_in_transaction_session_timeout और प्रति-डेटाबेस pool_mode ओवरराइड।

शुरुआत निःशुल्क

एआई शिक्षक के साथ SQL सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 22
पाठ: 88

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “Transaction और Session Pooling Modes” पाठ निःशुल्क है?

हाँ — PostgreSQL प्रदर्शन और क्वेरी अनुकूलन अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “Transaction और Session Pooling Modes” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“Transaction और Session Pooling Modes” में मैं क्या सीखूँगा?

सही PgBouncer mode चुनें और जानें कि transaction pooling में कौन-सी सुविधाएँ काम करना बंद कर देती हैं। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ PostgreSQL प्रदर्शन और क्वेरी अनुकूलन का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या PostgreSQL प्रदर्शन और क्वेरी अनुकूलन शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर PostgreSQL प्रदर्शन और क्वेरी अनुकूलन शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 2वाँ पाठ है।

“Transaction और Session Pooling Modes” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

PostgreSQL में Connections महँगे क्यों होते हैं
Transaction और Session Pooling Modes
Core Count के अनुसार Pools का आकार तय करना
Pool Saturation और Queueing का निदान

← PostgreSQL प्रदर्शन और क्वेरी अनुकूलन पर वापस जाएँ