तेजी से परीक्षण के लिए PostgreSQL का अनुकूलन करें

सबसे पहले, हमेशा PostgreSQL के नवीनतम संस्करण का उपयोग करें। प्रदर्शन सुधार हमेशा आ रहे हैं, इसलिए यदि आप किसी पुराने संस्करण को ट्यून कर रहे हैं तो आप शायद अपना समय बर्बाद कर रहे हैं। उदाहरण के लिए, PostgreSQL 9.2 TRUNCATE . की गति में उल्लेखनीय रूप से सुधार करता है और निश्चित रूप से इंडेक्स-ओनली स्कैन जोड़ता है। यहां तक ​​कि छोटी-छोटी विज्ञप्तियों का भी हमेशा पालन किया जाना चाहिए; संस्करण नीति देखें।

नहीं करें

करें नहीं रैमडिस्क या अन्य गैर-टिकाऊ भंडारण पर एक टेबलस्पेस लगाएं।

यदि आप एक टेबलस्पेस खो देते हैं तो पूरा डेटाबेस क्षतिग्रस्त हो सकता है और बिना किसी महत्वपूर्ण कार्य के उपयोग करना मुश्किल हो सकता है। इसका केवल UNLOGGED . का उपयोग करने की तुलना में बहुत कम लाभ है टेबल और वैसे भी कैश के लिए बहुत सारी RAM होना।

यदि आप वास्तव में रैमडिस्क आधारित प्रणाली चाहते हैं, initdb initdb . द्वारा रैमडिस्क पर एक नया क्लस्टर रैमडिस्क पर एक नया पोस्टग्रेएसक्यूएल इंस्टेंस डालें, ताकि आपके पास पूरी तरह से डिस्पोजेबल पोस्टग्रेएसक्यूएल इंस्टेंस हो।

PostgreSQL सर्वर कॉन्फ़िगरेशन

परीक्षण करते समय, आप अपने सर्वर को गैर-टिकाऊ लेकिन तेज़ संचालन के लिए कॉन्फ़िगर कर सकते हैं।

यह fsync=off . के लिए एकमात्र स्वीकार्य उपयोगों में से एक है PostgreSQL में सेटिंग। यह सेटिंग काफी हद तक PostgreSQL को आदेशित लिखने या उस अन्य खराब डेटा-अखंडता-सुरक्षा और क्रैश-सुरक्षा सामग्री से परेशान नहीं होने के लिए कहती है, अगर आप बिजली खो देते हैं या ओएस क्रैश हो जाते हैं तो इसे आपके डेटा को पूरी तरह से मिटाने की अनुमति देता है।

कहने की जरूरत नहीं है, आपको कभी भी fsync=off को सक्षम नहीं करना चाहिए उत्पादन में जब तक आप डेटा के लिए अस्थायी डेटाबेस के रूप में पीजी का उपयोग नहीं कर रहे हैं, आप कहीं और से पुन:उत्पन्न कर सकते हैं। अगर और केवल अगर आप fsync को बंद करने के लिए कर रहे हैं तो full_page_writes को भी बंद कर सकते हैं बंद, क्योंकि यह अब कोई अच्छा काम नहीं करता है। सावधान रहें कि fsync=off और full_page_writes क्लस्टर . पर आवेदन करें स्तर, इसलिए वे सभी . को प्रभावित करते हैं आपके PostgreSQL उदाहरण में डेटाबेस।

उत्पादन के उपयोग के लिए आप संभवतः synchronous_commit=off . का उपयोग कर सकते हैं और एक commit_delay सेट करें , जैसा कि आपको fsync=off . के समान कई लाभ प्राप्त होंगे विशाल डेटा भ्रष्टाचार जोखिम के बिना। यदि आप async कमिट को सक्षम करते हैं तो आपके पास हाल के डेटा के नुकसान की एक छोटी सी खिड़की है - लेकिन बस इतना ही।

यदि आपके पास डीडीएल को थोड़ा बदलने का विकल्प है, तो आप UNLOGGED का भी उपयोग कर सकते हैं। Pg 9.1+ में टेबल WAL लॉगिंग से पूरी तरह से बचने के लिए और सर्वर क्रैश होने पर टेबल को मिटाने की कीमत पर वास्तविक गति को बढ़ावा देने के लिए। सभी तालिकाओं को अनलॉग करने के लिए कोई कॉन्फ़िगरेशन विकल्प नहीं है, इसे CREATE TABLE के दौरान सेट किया जाना चाहिए . परीक्षण के लिए अच्छा होने के अलावा यह आसान है यदि आपके पास डेटाबेस में जेनरेट या महत्वहीन डेटा से भरा टेबल है जिसमें अन्यथा सामान शामिल है जिसे आपको सुरक्षित रहने की आवश्यकता है।

अपने लॉग की जाँच करें और देखें कि क्या आपको बहुत अधिक चौकियों के बारे में चेतावनियाँ मिल रही हैं। यदि आप हैं, तो आपको अपना चेकपॉइंट_सेगमेंट बढ़ाना चाहिए। आप आसानी से लिखने के लिए अपने checkpoint_completion_target को ट्यून करना चाह सकते हैं।

ट्यून shared_buffers अपने कार्यभार को फिट करने के लिए। यह ओएस-निर्भर है, इस पर निर्भर करता है कि आपकी मशीन के साथ और क्या हो रहा है, और इसके लिए कुछ परीक्षण और त्रुटि की आवश्यकता है। चूक अत्यंत रूढ़िवादी हैं। यदि आप shared_buffers बढ़ाते हैं, तो आपको OS की अधिकतम साझा मेमोरी सीमा बढ़ाने की आवश्यकता हो सकती है PostgreSQL 9.2 और नीचे पर; 9.3 और इसके बाद के संस्करण ने इससे बचने के लिए साझा स्मृति का उपयोग करने का तरीका बदल दिया।

यदि आप कुछ ऐसे कनेक्शन का उपयोग कर रहे हैं जो बहुत काम करते हैं, तो work_mem बढ़ाएं उन्हें खेलने के लिए अधिक रैम देने के लिए इत्यादि। सावधान रहें कि बहुत अधिक work_mem सेटिंग आउट-ऑफ-मेमोरी समस्याओं का कारण बन सकती है क्योंकि यह प्रति-प्रकार प्रति-कनेक्शन नहीं है, इसलिए एक क्वेरी में कई नेस्टेड प्रकार हो सकते हैं। आप केवल वास्तव में work_mem बढ़ाना होगा यदि आप EXPLAIN . में डिस्क पर छलकते हुए प्रकार देख सकते हैं या log_temp_files . के साथ लॉग इन किया है सेटिंग (अनुशंसित), लेकिन एक उच्च मान भी Pg को बेहतर योजनाएँ चुनने दे सकता है।

जैसा कि यहां एक अन्य पोस्टर द्वारा कहा गया है, यदि संभव हो तो अलग-अलग एचडीडी पर एक्सलॉग और मुख्य टेबल/इंडेक्स को रखना बुद्धिमानी है। अलग विभाजन बहुत व्यर्थ है, आप वास्तव में अलग ड्राइव चाहते हैं। यदि आप fsync=off . के साथ चल रहे हैं तो इस पृथक्करण का बहुत कम लाभ है और लगभग कोई नहीं यदि आप UNLOGGED . का उपयोग कर रहे हैं टेबल.

अंत में, अपने प्रश्नों को ट्यून करें। सुनिश्चित करें कि आपकी random_page_cost और seq_page_cost अपने सिस्टम के प्रदर्शन को प्रतिबिंबित करें, सुनिश्चित करें कि आपका effective_cache_size सही है, आदि। EXPLAIN (BUFFERS, ANALYZE) . का उपयोग करें अलग-अलग क्वेरी योजनाओं की जांच करने के लिए, और auto_explain . को चालू करें सभी धीमे प्रश्नों की रिपोर्ट करने के लिए मॉड्यूल चालू करें। आप अक्सर केवल एक उपयुक्त अनुक्रमणिका बनाकर या लागत मापदंडों में बदलाव करके क्वेरी के प्रदर्शन में नाटकीय रूप से सुधार कर सकते हैं।

AFAIK पूरे डेटाबेस या क्लस्टर को UNLOGGED के रूप में सेट करने का कोई तरीका नहीं है . ऐसा करने में सक्षम होना दिलचस्प होगा। PostgreSQL मेलिंग सूची पर पूछने पर विचार करें।

होस्ट OS ट्यूनिंग

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

लिनक्स में आप इसे वर्चुअल मेमोरी सबसिस्टम के dirty_* . से नियंत्रित कर सकते हैं सेटिंग, जैसे dirty_writeback_centisecs ।

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

इस ट्यूनिंग को वास्तव में सेटिंग्स के साथ खेलने की आवश्यकता है ताकि यह देखा जा सके कि आपके कार्यभार के लिए सबसे अच्छा क्या काम करता है।

नए कर्नेल पर, आप यह सुनिश्चित करना चाहेंगे कि vm.zone_reclaim_mode शून्य पर सेट है, क्योंकि यह NUMA सिस्टम (आजकल अधिकांश सिस्टम) के साथ गंभीर प्रदर्शन समस्याओं का कारण बन सकता है क्योंकि PostgreSQL shared_buffers को कैसे प्रबंधित करता है ।

क्वेरी और वर्कलोड ट्यूनिंग

ये ऐसी चीजें हैं जिनके लिए कोड परिवर्तन की आवश्यकता होती है; हो सकता है कि वे आपको सूट न करें। कुछ ऐसी चीजें हैं जिन्हें आप लागू कर सकते हैं।

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

जब भी संभव हो अस्थायी तालिकाओं का उपयोग करें। वे WAL ट्रैफ़िक उत्पन्न नहीं करते हैं, इसलिए वे आवेषण और अपडेट के लिए बहुत तेज़ हैं। कभी-कभी यह एक अस्थायी तालिका में डेटा के एक समूह को घिसने के लायक है, इसमें हेरफेर करना, हालांकि आपको इसकी आवश्यकता है, फिर एक INSERT INTO ... SELECT ... करना। इसे अंतिम तालिका में कॉपी करने के लिए। ध्यान दें कि अस्थायी टेबल प्रति-सत्र हैं; यदि आपका सत्र समाप्त हो जाता है या आप अपना कनेक्शन खो देते हैं तो अस्थायी तालिका चली जाती है, और कोई अन्य कनेक्शन सत्र की अस्थायी तालिका (तालिकाओं) की सामग्री को नहीं देख सकता है।

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

सामान्य तौर पर, DELETE FROM blah; . TRUNCATE TABLE blah; . का उपयोग करें बजाय; जब आप किसी तालिका में सभी पंक्तियों को डंप कर रहे होते हैं तो यह बहुत तेज़ होता है। कई तालिकाओं को एक TRUNCATE . में काटें हो सके तो कॉल करें। यदि आप बहुत सारे TRUNCATES कर रहे हैं तो एक चेतावनी है हालांकि, बार-बार छोटी तालिकाओं का; देखें:Postgresql ट्रंकेशन स्पीड

यदि आपके पास विदेशी कुंजियों पर अनुक्रमणिका नहीं है, DELETE उन विदेशी चाबियों द्वारा संदर्भित प्राथमिक कुंजी शामिल करना बहुत धीमा होगा। यदि आप कभी भी DELETE . की अपेक्षा करते हैं तो ऐसी अनुक्रमणिका बनाना सुनिश्चित करें संदर्भित तालिका (ओं) से। TRUNCATE . के लिए अनुक्रमणिका की आवश्यकता नहीं है ।

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

हार्डवेयर

यदि आप इसे प्रबंधित कर सकते हैं तो संपूर्ण डेटाबेस को धारण करने के लिए पर्याप्त RAM होना एक बड़ी जीत है।

यदि आपके पास पर्याप्त RAM नहीं है, तो आप जितनी तेज़ मेमोरी प्राप्त कर सकते हैं, उतना बेहतर होगा। यहां तक ​​​​कि एक सस्ता एसएसडी भी कताई जंग पर भारी अंतर डालता है। उत्पादन के लिए सस्ते एसएसडी पर भरोसा न करें, हालांकि, वे अक्सर दुर्घटनाग्रस्त नहीं होते हैं और आपका डेटा खा सकते हैं।

सीखना

ग्रेग स्मिथ की पुस्तक, पोस्टग्रेएसक्यूएल 9.0 उच्च प्रदर्शन कुछ पुराने संस्करण का जिक्र करने के बावजूद प्रासंगिक बनी हुई है। यह एक उपयोगी संदर्भ होना चाहिए।

PostgreSQL सामान्य मेलिंग सूची में शामिल हों और उसका अनुसरण करें।

पढ़ना:

• अपने PostgreSQL सर्वर को ट्यून करना - PostgreSQL विकी
• डेटाबेस कनेक्शन की संख्या - PostgreSQL विकी