Postgres max_connections बिना पूलर के

पोस्टग्रेज़ अपने कनेक्शन के लिए हल्के थ्रेड पूल का उपयोग नहीं करता है। प्रत्येक क्लाइंट कनेक्शन एक पूर्ण सिस्टम प्रक्रिया को ट्रिगर करता है।

postmaster प्रक्रिया प्रत्येक कनेक्शन प्रयास के लिए एक नया ("कांटा") बनाती है, जो इस एकल सत्र के बंद होने तक समर्पित होती है। आधिकारिक परियोजना दस्तावेज वास्तुशिल्प बुनियादी बातों पर अपने अध्याय में इस तंत्र का सटीक वर्णन करता है (postgresql.org/docs/current/connect-estab.html, "कनेक्शन सिमेंटिक्स" अनुभाग, 24 अगस्त, 2026 को एक्सेस किया गया)।

इस विकल्प का एक वास्तविक लाभ है: एक कनेक्शन पर क्रैश होने से दूसरे पर कोई प्रभाव नहीं पड़ता है, प्रत्येक प्रक्रिया बाकी सर्वर से अलग हो जाती है। इसकी एक प्रत्यक्ष लागत भी है: प्रत्येक अतिरिक्त कनेक्शन अपने स्वयं के मेमोरी स्पेस और कर्नेल के लिए अपने स्वयं के संदर्भ स्विचिंग ओवरहेड के साथ शेड्यूल करने के लिए एक संपूर्ण ओएस प्रक्रिया जोड़ता है।

दो अलग-अलग तंत्र स्मृति को प्रभावित करते हैं, और उन्हें भ्रमित करने से लगभग हमेशा गलत निदान होता है।

पहला तय हो गया है. स्टार्टअप पर, पोस्टग्रेज साझा मेमोरी संरचनाओं (लॉक, प्रोसेस टेबल) को max_connections के मूल्य पर आरक्षित करता है, भले ही ये कनेक्शन बाद में खोले गए हों या नहीं। सेटिंग के लिए आधिकारिक दस्तावेज़ स्पष्ट रूप से इंगित करता है: इसे बढ़ाने के लिए आपके OS के डिफ़ॉल्ट कॉन्फ़िगरेशन की अनुमति से अधिक सिस्टम साझा मेमोरी की आवश्यकता हो सकती है (postgresql.org/docs/current/runtime-config-connection.html, 24 अगस्त, 2026 को एक्सेस किया गया)।

दूसरा परिवर्तनशील है, और पैमाने पर बहुत अधिक खतरनाक है: work_mem को प्रति कनेक्शन एक बार आवंटित नहीं किया जाता है, बल्कि क्वेरी योजना में प्रति सॉर्टिंग या हैशिंग ऑपरेशन के लिए एक बार आवंटित किया जाता है। इस बिंदु पर आधिकारिक दस्तावेज स्पष्ट है: एक जटिल क्वेरी इनमें से कई ऑपरेशनों को समानांतर में लॉन्च कर सकती है, और कई सत्र एक साथ ऐसा कर सकते हैं, ताकि वास्तव में उपयोग की गई मेमोरी कई बार काम करने योग्य हो सके (postgresql.org/docs/current/runtime-config-resource.html, 24 अगस्त 2026 को एक्सेस किया गया)।

आधिकारिक PostgreSQL प्रोजेक्ट विकी यह गणना करने के लिए एक बेंचमार्क फॉर्मूला दस्तावेज करता है कि आपका हार्डवेयर कितने सक्रिय कनेक्शन को समानांतर में कुशलतापूर्वक संसाधित कर सकता है, न कि कुल कितने कनेक्शन खुलते हैं (wiki.postgresql.org/wiki/Number_Of_Database_Connections, 24 अगस्त 2026 को एक्सेस किया गया)।

8 भौतिक कोर और एसएसडी स्टोरेज वाले सर्वर पर, थ्रूपुट ख़राब होने से पहले सूत्र (8 × 2) + 1 = 17 सक्रिय कनेक्शन देता है। यह आंकड़ा अक्सर आश्चर्यजनक होता है: किसी एप्लिकेशन द्वारा व्यवहार में खोले जाने वाले सैकड़ों कनेक्शनों की तुलना में यह छोटा लगता है। यह बिल्कुल निम्नलिखित पैराग्राफ का विषय है।

The number calculated by the formula measures the concurrency that the CPU and disk can absorb, not the number of client connections your application needs to open. A fleet of 20 application processes, each with its own pool of 10 connections, opens 200 simultaneous connections to Postgres even if only 17 of them are actively working at any given time. Without a pooler, max_connections must cover the 200, not the 17. It is this gap that pushes most architectures to add a pooler in transaction mode, even if it means choosing which one (see our comparison PgBouncer, Supavisor and PgCat).

max_connections हॉट स्वैप नहीं है. यह एक postmaster संदर्भ पैरामीटर है: पोस्टग्रेज़ अपनी साझा मेमोरी को आकार देने के लिए, स्टार्टअप पर इसे एक बार पढ़ता है। कॉन्फ़िगरेशन पुनः लोड (pg_reload_conf() या SIGHUP) पर्याप्त नहीं है, आपको सर्वर को पुनरारंभ करना होगा।

पहले वर्तमान मान और उसके संदर्भ की जाँच करें, यह पुष्टि करने के लिए कि पुनः आरंभ करना आवश्यक होगा:

SHOW max_connections;

SELECT name, setting, context
FROM pg_settings
WHERE name = 'max_connections';

-- context='पोस्टमास्टर' पुष्टि करता है कि रीबूट की आवश्यकता है

फिर नया मान लागू करें, फिर पुनरारंभ करें:

ALTER SYSTEM SET max_connections = '300';

-- Postgresql.auto.conf में लिखा गया है।
-- Postgres पुनः आरंभ होने तक कोई प्रभाव नहीं।

# सिस्टमड के साथ
sudo systemctl restart postgresql

# सिस्टमडी के बिना, सीधे pg_ctl के साथ
pg_ctl restart -D $PGDATA -m fast

max_connections को आकार देना केवल एक सैद्धांतिक अभ्यास नहीं है। यहां बताया गया है कि ऑराबेस अपने प्रबंधित पोस्टग्रेज क्लस्टर पर इसका बजट कैसे बनाता है:

समर्पित क्लस्टर: प्रति प्रोजेक्ट एक पोस्टग्रेज क्लस्टर

इस स्तर पर (हमारी तुलना समर्पित बनाम साझा आधारदेखें), प्रत्येक प्रोजेक्ट को अपना स्वयं का CloudNativePG क्लस्टर और अपना स्वयं का max_connections बजट प्राप्त होता है, जिसका आकार उदाहरण के आकार के साथ होता है:

साझा क्लस्टर: एक संगठन की कई परियोजनाएं, एक साझा बजट

इस दूसरे पथ पर, एक ही संगठन की सभी परियोजनाएँ एक साझा प्राथमिक के सामने एक CNPG पूलर (PgBouncer, transactionमोड) के माध्यम से जुड़ती हैं:

किसी संगठन में सभी परियोजनाएँ एक साझा अनुप्रयोग भूमिका के माध्यम से जुड़ती हैं। max_user_connections इसलिए अकेले कुल सर्वर कनेक्शन को सीमित करता है जिसे यह भूमिका पूरे क्लस्टर में खोल सकती है: यह वास्तविक क्लस्टर-वैश्विक सुरक्षा है, न कि max_client_conn, जो केवल क्लाइंट कनेक्शन को पूलर तक ही सीमित करता है।

हालाँकि, यह पूलर केवल SDK एप्लिकेशन ट्रैफ़िक प्रदान करता है। PostgREST, अपनी ओर से, सीधे प्राथमिक (-rwसेवा) से जुड़ा रहता है: लेनदेन मोड में पूलिंग इसके स्कीमा रीलोडिंग तंत्र को तोड़ देगी, जो pgrstनामक एक समर्पित LISTEN चैनल को सुनता है। इसके स्वयं के कनेक्शन (साझा स्तर पर 2 प्रति प्रतिकृति, समर्पित स्तर पर 10 प्रति प्रतिकृति) इसलिए किसी भी पूलर के बाहर सीधे प्राथमिक के अधिकतम_कनेक्शन बजट में गिने जाते हैं, ठीक उसी प्रकार का "भूल गए" कनेक्शन जो नीचे दी गई प्रक्रिया के चरण 1 में शामिल होना चाहिए।

यह प्रक्रिया किसी विशेष उपकरण पर निर्भर नहीं करती है: यह प्रबंधित या स्व-होस्ट किए गए किसी भी पोस्टग्रेज सर्वर पर लागू होती है।

1. अपने वास्तविक ग्राहक कनेक्शन की गणना करें। एप्लिकेशन प्रक्रियाओं की संख्या उनके आंतरिक पूल के आकार, साथ ही प्रशासन उपकरण, प्रतिकृति और निगरानी से गुणा की जाती है। यह यह संख्या है, सूत्र नहीं, जो अधिकतम_कनेक्शन स्तर निर्धारित करता है।
2. PostgreSQL विकी के सूत्र के साथ अपने हार्डवेयर की आदर्श संगामिति की गणना करें: (भौतिक कोर × 2) + कुशल डिस्क। यह आंकड़ा इंगित करता है कि इनमें से कितने कनेक्शन वास्तव में थ्रूपुट को कम किए बिना समानांतर में काम कर सकते हैं।
3. चरण 1 के लिए वास्तविक आवश्यकता के ऊपर max_connections सेट करें, superuser_reserved_connections के लिए मार्जिन के साथ और किसी भी व्यवस्थापक टूल के लिए जो एप्लिकेशन के बाहर अपने स्वयं के कनेक्शन खोलते हैं।
4. ALTER SYSTEM SET के साथ परिवर्तन लागू करें, फिर सर्वर को पुनरारंभ करें। यह एक पोस्टमास्टर पैरामीटर है: जैसा कि ऊपर बताया गया है, एक साधारण पुनः लोड पर्याप्त नहीं है।
5. समय के साथ pg_stat_activity की निगरानी करें। यदि निष्क्रिय कनेक्शनों की संख्या सक्रिय कनेक्शनों की संख्या से बहुत अधिक है, तो यह max_connections समस्या नहीं है: यह संकेत है कि आपको सर्वर के सामने एक पूलर की आवश्यकता है, न कि अधिक संख्या की।

चरण 5 से निगरानी अनुरोध, सीधे प्रयोग योग्य:

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

जब max_connections अकेले पर्याप्त नहीं रह जाता है, तो तीन सिग्नल व्यवस्थित रूप से वापस आते हैं, चाहे उसका मूल्य कुछ भी हो।

1. FATAL: sorry, too many clients already त्रुटि चरम लोड के दौरान दिखाई देती है, जबकि pg_stat_activity द्वारा प्रदर्शित अधिकांश कनेक्शन निष्क्रिय अवस्था में होते हैं।
2. एप्लिकेशन सर्वर रहित वातावरण में या अल्पकालिक श्रमिकों (एज फ़ंक्शंस, छोटी नौकरियां) के साथ चलता है, जो पोस्टग्रेज़ के प्रक्रिया-प्रति-कनेक्शन मॉडल को समायोजित करने के लिए डिज़ाइन किए गए कनेक्शन की तुलना में बहुत तेज़ी से कनेक्शन खोलता और बंद करता है।
3. उपरोक्त सूत्र और प्रक्रिया पहले ही लागू की जा चुकी है, और क्लाइंट कनेक्शन की वास्तविक आवश्यकता वर्क_मेम या शेयर्ड_बफ़र्स को खतरे में डाले बिना उपलब्ध मेमोरी द्वारा आवंटित की जा सकने वाली क्षमता से अधिक बनी हुई है।

इन तीन मामलों में, सही उत्तर लगभग हमेशा एप्लिकेशन और पोस्टग्रेज़ के बीच स्थित एक पूलर होता है, न कि उच्चतर max_connections। हमारी तुलना PgBouncer, Supavisor और PgCat तीन विकल्पों का विवरण देती है, और लेनदेन मोड के लिए हमारी मार्गदर्शिका पूलर स्थापित होने के बाद सबसे आम समझौते की व्याख्या करती है। कनेक्शन से परे सभी पोस्टग्रेज ट्यूनिंग के लिए, हमारी प्रोडक्शन पोस्टग्रेज ट्यूनिंग चेकलिस्टदेखें।