📑 🔣 👨🏽‍💻 PostgreSQL सेटिंग्स ट्यूनिंग प्रदर्शन का अनुकूलन करने के लिए 🧝🏾 🤴🏽 💃🏻

डिफ़ॉल्ट रूप से, PostgreSQL कार्यभार के लिए कॉन्फ़िगर नहीं किया गया है। डिफ़ॉल्ट मान यह सुनिश्चित करने के लिए सेट किए गए हैं कि पोस्टग्रैसक्यू कम से कम संसाधनों के साथ हर जगह कार्यात्मक है। सभी डेटाबेस सेटिंग्स के लिए डिफ़ॉल्ट सेटिंग्स हैं। डेटाबेस व्यवस्थापक या डेवलपर की प्राथमिक जिम्मेदारी अपने सिस्टम लोड को फिट करने के लिए PostgreSQL को कॉन्फ़िगर करना है। इस ब्लॉग में, हम वर्कलोड के अनुसार डेटाबेस प्रदर्शन को बेहतर बनाने के लिए पोस्टग्रेजेक्यूएल डेटाबेस सेटिंग्स को ट्यून करने के लिए बुनियादी सिफारिशों को रेखांकित करेंगे।

ध्यान रखें कि आपके PostgreSQL सर्वर कॉन्फ़िगरेशन को बेहतर बनाने के दौरान प्रदर्शन में सुधार होता है, डेटाबेस डिज़ाइनर को प्रश्न लिखते समय भी सावधानी बरतनी चाहिए। यदि क्वेरी एक पूर्ण तालिका स्कैन करते हैं, जहां एक सूचकांक का उपयोग किया जा सकता है, या भारी जुड़ाव या महंगे एकत्रीकरण ऑपरेशन कर सकते हैं, तो सिस्टम अभी भी खराब काम कर सकता है, भले ही डेटाबेस सेटिंग्स सही तरीके से कॉन्फ़िगर की गई हों। डेटाबेस क्वेरी लिखते समय, प्रदर्शन पर ध्यान देना महत्वपूर्ण है।

हालांकि, डेटाबेस पैरामीटर भी बहुत महत्वपूर्ण हैं, तो आइए उन आठ को देखें जो प्रदर्शन में सुधार की सबसे बड़ी क्षमता रखते हैं।

कस्टम PostgreSQL विकल्प

PostgreSQL अपने स्वयं के बफर का उपयोग करता है, और एक बफर कर्नेल IO का भी उपयोग करता है। इसका अर्थ है कि डेटा को दो बार मेमोरी में संग्रहीत किया जाता है, पहले PostgreSQL बफर में, और फिर कर्नेल बफर में। अन्य डेटाबेस के विपरीत, PostgreSQL प्रत्यक्ष I / O प्रदान नहीं करता है। इसे डबल बफरिंग कहा जाता है। PostgreSQL बफर को share_buffer कहा जाता है, जो अधिकांश ऑपरेटिंग सिस्टम के लिए सबसे कुशल कस्टम पैरामीटर है। यह पैरामीटर सेट करता है कि कैशिंग के लिए कितनी मेमोरी आवंटित की जाएगी

शेयर्ड_ बफ़र के लिए डिफ़ॉल्ट मान बहुत कम सेट किया गया है और आपको इसका अधिक लाभ नहीं मिलेगा। ऐसा इसलिए है क्योंकि कुछ मशीनें और ऑपरेटिंग सिस्टम उच्च मूल्यों का समर्थन नहीं करते हैं। लेकिन अधिकांश आधुनिक मशीनों में आपको इष्टतम प्रदर्शन के लिए इस मूल्य को बढ़ाने की आवश्यकता होती है।

अनुशंसित मान कंप्यूटर की कुल रैम का 25% है। आपको कुछ निचले और उच्च मूल्यों की कोशिश करनी चाहिए, क्योंकि कुछ मामलों में आप 25% से अधिक की सेटिंग के साथ अच्छा प्रदर्शन प्राप्त कर सकते हैं। लेकिन वास्तविक कॉन्फ़िगरेशन आपकी मशीन और काम कर रहे डेटासेट पर निर्भर करता है। यदि आपका कामकाजी डेटासेट आपके रैम में आसानी से फिट हो सकता है, तो आप साझा_बफ़र का मान बढ़ा सकते हैं ताकि इसमें आपका पूरा डेटाबेस शामिल हो और संपूर्ण कामकाजी डेटासेट कैश में हो सके। हालाँकि, आप स्पष्ट रूप से PostgreSQL के लिए सभी रैम आरक्षित नहीं करना चाहते हैं।

यह देखा गया है कि उत्पादन के माहौल में, अच्छा प्रदर्शन वास्तव में शेयर्ड_ बफ़र को बहुत महत्व देता है, हालांकि सही संतुलन प्राप्त करने के लिए परीक्षण हमेशा किए जाने चाहिए।

^{Share_buffer का मान जाँच रहा है}

testdb=# SHOW shared_buffers; shared_buffers ---------------- 128MB (1 row)

_{नोट : सावधान रहें, क्योंकि कुछ गुठली बड़े मूल्य का समर्थन नहीं करती हैं , खासकर विंडोज पर।}

wal_buffers

PostgreSQL पहले बफ़र्स के लिए वाल (prerecord लॉग) में प्रविष्टियों को लिखता है, और फिर इन बफ़र्स को डिस्क में फ्लश किया जाता है। Wal_buffers द्वारा परिभाषित डिफ़ॉल्ट बफर आकार 16 एमबी है। लेकिन अगर आपके पास कई समवर्ती कनेक्शन हैं, तो एक उच्च मूल्य प्रदर्शन में सुधार कर सकता है।

effective_cache_size

effective_cache_size डिस्क कैशिंग के लिए उपलब्ध मेमोरी का एक अनुमान प्रदान करता है। यह केवल एक दिशानिर्देश है, आवंटित स्मृति या कैश की सटीक मात्रा नहीं है। यह वास्तविक मेमोरी को आवंटित नहीं करता है, लेकिन ऑप्टिमाइज़र को कर्नेल में उपलब्ध कैश की मात्रा बताता है। यदि यह पैरामीटर बहुत कम सेट है, तो क्वेरी प्लानर कुछ इंडेक्स का उपयोग न करने का निर्णय ले सकता है, भले ही वे उपयोगी हों। इसलिए, एक बड़ा मूल्य सेट करना हमेशा समझ में आता है।

work_mem

इस सेटिंग का उपयोग जटिल छँटाई के लिए किया जाता है। यदि आपको जटिल छंटाई करने की आवश्यकता है, तो अच्छे परिणाम प्राप्त करने के लिए work_mem का मान बढ़ाएँ । डिस्क पर डेटा सॉर्ट करने की तुलना में मेमोरी में छंटनी बहुत तेज है। इसे बहुत अधिक मूल्य पर सेट करने से आपके वातावरण के लिए मेमोरी टोंटी का कारण बन सकता है, क्योंकि यह विकल्प उपयोगकर्ता के प्रकार के ऑपरेशन से संबंधित है। इसलिए, यदि आपके पास कई उपयोगकर्ता हैं जो छंटनी के संचालन को करने की कोशिश कर रहे हैं, तो सिस्टम हाइलाइट करेगा:

 work_mem * total sort operations

सभी उपयोगकर्ताओं के लिए। इस पैरामीटर को विश्व स्तर पर सेट करने से बहुत अधिक मेमोरी उपयोग हो सकता है। इसलिए, यह अत्यधिक अनुशंसा की जाती है कि आप इसे सत्र स्तर पर बदल दें।

^{वर्क_म = 2 एमबी}

 testdb=# SET work_mem TO "2MB"; testdb=# EXPLAIN SELECT * FROM bar ORDER BY bar.b; QUERY PLAN ----------------------------------------------------------------------------------- Gather Merge (cost=509181.84..1706542.14 rows=10000116 width=24) Workers Planned: 4 -> Sort (cost=508181.79..514431.86 rows=2500029 width=24) Sort Key: b -> Parallel Seq Scan on bar (cost=0.00..88695.29 rows=2500029 width=24) (5 rows)

प्रारंभिक अनुरोध सॉर्टिंग नोड का मूल्यांकन 514431.86 पर किया जाता है। लागत एक मनमानी गणना इकाई है। उपरोक्त अनुरोध के लिए, हमारे पास केवल 2 MB का वर्क_म है। परीक्षण उद्देश्यों के लिए, आइए इस मान को 256 एमबी तक बढ़ाएं और देखें कि क्या यह लागत को प्रभावित करता है।

^{वर्क_म = 256 एमबी}

 testdb=# SET work_mem TO "256MB"; testdb=# EXPLAIN SELECT * FROM bar ORDER BY bar.b; QUERY PLAN ----------------------------------------------------------------------------------- Gather Merge (cost=355367.34..1552727.64 rows=10000116 width=24) Workers Planned: 4 -> Sort (cost=354367.29..360617.36 rows=2500029 width=24) Sort Key: b -> Parallel Seq Scan on bar (cost=0.00..88695.29 rows=2500029 width=24)

अनुरोध लागत 514431.86 से घटकर 360617.36 हो गई, यानी 30% की कमी आई।

maintenance_work_mem

मेन्टेनेंस_वर्क_मेम एक मेमोरी पैरामीटर है जिसका उपयोग रखरखाव कार्यों के लिए किया जाता है। डिफ़ॉल्ट मान 64 एमबी है। एक बड़ा मान सेट करने से VACUUM, RESTORE, CREATE INDEX, ADD FOREIGN KEY और ALTER TABLE जैसे कार्यों में मदद मिलती है।

^{रखरखाव_कार_म = १० एमबी}

 postgres=# CHECKPOINT; postgres=# SET maintenance_work_mem to '10MB'; postgres=# CREATE INDEX foo_idx ON foo (c); CREATE INDEX Time: 170091.371 ms (02:50.091)

^{मेन्टेनेंस_वर्क_मेम = 256 एमबी}

 postgres=# CHECKPOINT; postgres=# set maintenance_work_mem to '256MB'; postgres=# CREATE INDEX foo_idx ON foo (c); CREATE INDEX Time: 111274.903 ms (01:51.275)

अनुक्रमणिका निर्माण का समय 170091.371 एमएस है अगर मेंटेनेंस_वर्क_मम पैरामीटर केवल 10 एमबी पर सेट है, लेकिन यह घटकर 111274.903 एमएस हो जाता है जब हम मेंटेनेंस_वर्क_ एमएम पैरामीटर को बढ़ाकर 256 एमबी कर देते हैं।

synchronous_commit

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

checkpoint_timeout, checkpoint_completion_target

PostgreSQL वाल में परिवर्तन लिखता है। चेकपॉइंट प्रक्रिया डेटा को फ़ाइलों में फ़्लश करती है। यह क्रिया तब की जाती है जब एक ब्रेकपॉइंट (CHECKPOINT) होता है। यह एक महंगा ऑपरेशन है और इससे बड़ी संख्या में IO ऑपरेशन हो सकते हैं। इस पूरी प्रक्रिया में डिस्क में महंगे रीड / राइट ऑपरेशन शामिल हैं। उपयोगकर्ता हमेशा आवश्यक होने पर चेकपॉइंट कार्य (CHECKPOINT) शुरू कर सकते हैं या चेकपॉइंट_टाइम और चेकपॉइंट_completion_target पैरामीटर का उपयोग करके प्रारंभ को स्वचालित कर सकते हैं।

चेकपॉइंट_टाइमआउट पैरामीटर का उपयोग वाल ब्रेकपॉइंट्स के बीच समय निर्धारित करने के लिए किया जाता है। इसे बहुत कम सेट करना किसी क्रैश के बाद पुनर्प्राप्ति समय को कम कर देता है क्योंकि डिस्क पर अधिक डेटा लिखा जा रहा है, लेकिन यह प्रदर्शन को भी कम करता है क्योंकि प्रत्येक चेकपॉइंट अंततः मूल्यवान सिस्टम संसाधनों का उपभोग करता है।

checkpoint_completion_target चेकपॉइंट पूरा करने के लिए चौकियों के बीच के समय का अंश है। उच्च आवृत्ति चौकियां प्रदर्शन को प्रभावित कर सकती हैं। चेकपॉइंट कार्य को आसानी से पूरा करने के लिए, चेकपॉइंट_ टाइमआउट कम होना चाहिए। अन्यथा, ओएस सभी गंदे पन्नों को जमा करेगा जब तक कि अनुपात नहीं देखा जाता है, और फिर एक बड़े रीसेट का उत्पादन करता है।

निष्कर्ष

अधिक विकल्प हैं जो आप बेहतर प्रदर्शन प्राप्त करने के लिए ट्वीक कर सकते हैं, लेकिन उनके पास यहां हाइलाइट किए गए लोगों की तुलना में कम प्रभाव है। अंत में, हमें हमेशा याद रखना चाहिए कि सभी प्रकार के अनुप्रयोगों के लिए सभी पैरामीटर प्रासंगिक नहीं हैं। कुछ एप्लिकेशन विकल्प सेट करते समय बेहतर काम करते हैं, और कुछ नहीं करते हैं। PostgreSQL डेटाबेस सेटिंग्स को एप्लिकेशन और ऑपरेटिंग सिस्टम की विशिष्ट आवश्यकताओं के अनुरूप होना चाहिए, जिसमें यह चलता है।

PostgreSQL सेटिंग्स ट्यूनिंग प्रदर्शन का अनुकूलन करने के लिए