PostgreSQL दस्तावेज़ीकरण के अधिक उपयोगी बिट्स में से एक, जिस पर मैंने कभी काम किया है, वह है अपने PostgreSQL को ट्यून करना
सर्वर। जब यह 2008 की गर्मियों में लिखा गया था, पोस्टग्रेएसक्यूएल 8.3 के
रिलीज के कुछ महीनों बाद, किसी भी समान मार्गदर्शिका को खोजना मुश्किल था जो
दोनों (अपेक्षाकृत) संक्षिप्त और वर्तमान थी। तब से, मैंने और
कई अन्य PostgreSQL योगदानकर्ताओं ने उस दस्तावेज़ को अद्यतित रखने में मदद की है
जब तक PostgreSQL में परिवर्तन किए गए थे।
दिलचस्प और उपयोगी प्रवृत्ति
उस अवधि के दौरान यह है कि पैरामीटर सेट से गायब रहते हैं
जिनकी आपको चिंता करने की आवश्यकता है। PostgreSQL 8.2 में, पोस्टग्रेएसक्यूएल सर्वर पर
अच्छे प्रदर्शन के लिए समायोजित करने के लिए आवश्यक पैरामीटरों की एक लंबी सूची थी
:shared_buffers, effect_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers, और (यदि
विभाजन का उपयोग कर रहे हैं) Constraint_exclusion.
8.3 ने ऑटोवैक्यूम को डिफ़ॉल्ट बना दिया
उचित व्यवहार के साथ चालू किया, साथ ही कुछ को हटा दिया
पृष्ठभूमि लेखक पैरामीटर जिनके कारण परेशानी के अलावा और कुछ नहीं हुआ (उन्होंने
इसे कभी सूची में नहीं बनाया)। 8.4 ने दो
max_fsm_* पैरामीटर की आवश्यकता को हटा दिया, default_statistics_target को बहुत अधिक
बेहतर प्रारंभिक मान तक बढ़ा दिया, और सबसे सामान्य मामलों में सेटिंग Constraint_exclusion
अनावश्यक बना दिया। ये छह कम पैरामीटर हैं
जिन्हें आपको समायोजित करने की आवश्यकता हो सकती है।
दुर्भाग्य से केवल संस्करण 9.0 को ही बनाया गया
सर्वर कॉन्फ़िगरेशन अधिक जटिल है। और नए Linux कर्नेल ने भी
डिफ़ॉल्ट व्यवहार को पीछे की ओर धकेल दिया। Linux कर्नेल से प्रारंभ करते हुए
2.6.33, wal_sync_method के लिए चुना गया डिफ़ॉल्ट मान
open_datasync में बदल गया। यह खराब प्रदर्शन के रूप में सामने आता है
PostgreSQL के लिए निहितार्थ, विशेष रूप से जब सर्वर में wal_buffers के लिए कम
डिफ़ॉल्ट सेटिंग के साथ जोड़ा जाता है।
लेकिन बेहतर डिफॉल्ट की ओर बढ़ना
व्यवहार हाल ही में फिर से शुरू हुआ है जो अंततः होने की योजना है
पोस्टग्रेएसक्यूएल 9.1. पिछले कमिटफेस्ट के दौरान, मार्टी की उत्पत्ति हुई एक पैच
वाल_सिंक_मेथोड समस्या को ठीक करने के लिए राउडसेप को प्रतिबद्ध किया गया था
उस परिवर्तन को किस रूप में लेना चाहिए, इस पर कुछ भारी तर्कों के बाद।
यह पता चलता है कि इस व्यवहार परिवर्तन ने PostgreSQL को पूरी तरह से तोड़ दिया
br />जब "data=journal" विकल्प के साथ ext4 पर चलने से मदद मिली
डिफ़ॉल्ट रूप से यहां करने के लिए सही काम करें।
दो पैरामीटर जिनकी मैं अनुशंसा नहीं करता
ज्यादातर मामलों में कमिट_सिब्लिंग्स और कमिट_डेले को छूना,
धीमे प्रतिबद्ध समय के साथ सिस्टम पर प्रदर्शन में सुधार करने के पुराने प्रयास की कलाकृतियां (जिसमें अधिकांश सिस्टम शामिल हैं जिनके पास उस क्षेत्र को तेज करने के लिए बैटरी-समर्थित लेखन कैश नहीं है)। आजकल
8.3 में पेश किए गए तुल्यकालिक_कमिट पैरामीटर को बंद करने से
यहां मदद मिलने की बहुत अधिक संभावना है। हालांकि इनसे
प्रदर्शन में सुधार होने की संभावना नहीं है, जो लोग उन्हें सेट करने का प्रयास करते हैं, उन्हें उस निर्णय के नुकसान से
आवश्यकता से अधिक नुकसान हुआ है। सबसे खराब स्थिति
यहाँ के व्यवहार में काफ़ी सुधार किया गया था, जिसे मैंने अनुकूलित करने के लिए लिखा था कि वे पैरामीटर किस तरह से तर्क को नियंत्रित करते हैं।
और इस सप्ताह अधिकांश मामलों में
प्रभावी ढंग से समाप्त होने वाला नवीनतम पैरामीटर wal_buffers है। मेरे द्वारा
सुझाया गया एक परिवर्तन इसे स्वचालित रूप से आकार के प्रतिशत (लगभग 3%) के रूप में सेट करने के लिए प्रतिबद्ध था
सामान्य रूप से बहुत बड़े साझा_बफ़र्स पैरामीटर के लिए आवंटित किया गया था।
यह wal_buffers का मान सेट करता है एक बार जब आप
shared_buffers को कम से कम 512MB आवंटित कर देते हैं, तो इसकी
प्रभावी सीमा, 16MB की सामान्य ऊपरी सीमा। और अगर आपने शेयर्ड_बफ़र्स को उसके छोटे
डिफ़ॉल्ट से बढ़ा दिया है, तो आपको इस
महत्वपूर्ण प्रतिबद्ध प्रदर्शन पैरामीटर में एक समान सुधार मिलेगा। आपको इस पैरामीटर की सेटिंग को तोड़ने के लिए
अपने रास्ते से बाहर जाना होगा
पिछले संस्करणों में संभावित स्थितियों को खराब करने के लिए
।
कॉन्फ़िगरेशन की मात्रा होने पर
डिफॉल्ट रूप से सर्वर को कम जटिल होने की आवश्यकता होती है
सार्थक, और महत्वपूर्ण सूची के रूप में पैरामीटर गायब होते देखना
एक स्वागत योग्य परिवर्तन है। आगे क्या होगा? UNIX-व्युत्पन्न ऑपरेटिंग सिस्टम, विशेष रूप से Linux पर
साझा स्मृति आवंटित करने के साथ मुख्य मुद्दे,
shared_buffers को समाप्त करना बहुत कठिन बनाते हैं। और चिंता
सिस्टम को संभालने वाले सर्वर पर पूरी तरह से क्षमता को सीमित कर देता है
work_mem जैसे मापदंडों को स्वचालित रूप से सही सीमा पर सेट करने के लिए।
कार्यशील मेमोरी पूल को बेहतर ढंग से प्रबंधित करने के लिए कुछ प्रस्ताव दिए गए हैं
सुझाव दिया, ताकि किसी को कुछ सुधार दिखाई दे।
अगले पैरामीटर पर मेरी नजर है
checkpoint_segments.
पिछले CommitFest में इस क्षेत्र में बस अतिरिक्त लॉगिंग जोड़ने के बाद, इस क्षेत्र में कुछ सुधार होने वाले हैं
वास्तव में चेकपॉइंट व्यवहार में सुधार करने के लिए अभी प्रतिबद्ध हैं। मुझे उम्मीद है कि
आखिरकार चेकपॉइंट ट्यूनिंग को सख्ती से नियंत्रित करने के लिए
समय-उन्मुख मापदंडों के माध्यम से स्विच करना होगा, बजाय इसके कि उपयोगकर्ताओं को
यह समझने की आवश्यकता हो कि राइट-फ़ॉरवर्ड लॉग कैसे ट्यून करने के लिए काम करता है
बीआर />सिस्टम। यहां अभी भी बहुत सी बदसूरत स्थितियां संभव हैं
कि समय में 9.1 के लिए, लेकिन सेगमेंट की गणना स्वचालित रूप से सेट करना
9.2 के लिए लक्षित करना संभव है।
