PostgreSQL Antipatterns: सिर के आसपास के आँकड़े

PostgreSQL सबसे कुशल क्वेरी निष्पादन योजना का चयन करने के लिए लक्ष्य तालिकाओं में डेटा मानों के वितरण पर संचित आँकड़ों का उपयोग करता है ।

यह स्पष्ट रूप से ANALYZE और VACUUM ANALYZE कमांड चलाकर या ऑटोवैक्युम / ऑटोअनलेज़ प्रक्रिया द्वारा पृष्ठभूमि में अपडेट किया जाता है । लेकिन अगर आँकड़ों को अपडेट करने का समय नहीं है - तो परेशानी हो सकती है।

ऐसी समस्या का पता कैसे लगाएं और ठीक करें?

ऐसी स्थिति होने पर मुख्य विकल्प यह है कि यदि तालिका में डेटा सेट नाटकीय रूप से बदल गया है। यही है, इसने बड़ी संख्या में INSERT / UPDATE / DELETE को इस पर निकाल दिया या डेटा को एक खाली तालिका में "डाला" - उदाहरण के लिए, जब एक बैकअप से पुनर्स्थापित किया जाता है ।

मानक पुनर्प्राप्ति उपयोगिता pg_restore के लिए सहायता भी स्पष्ट रूप से कहती है:

पुनर्प्राप्ति के बाद, यह प्रत्येक बहाल तालिका के लिए ANALYZE चलाने के लिए समझ में आता है ताकि ऑप्टिमाइज़र को अद्यतित आंकड़े प्राप्त हों।

इसलिए, यदि आप डेटाबेस के साथ कुछ समान कर रहे हैं - आलसी मत बनो, तुरंत सबसे "बोल्ड" तालिकाओं के लिए या पूरे डेटाबेस के लिए ANALYZE चलाएं।

हम एक समस्या की उपस्थिति का निर्धारण करते हैं

"सभी खराब" स्थिति वास्तव में किस वजह से दिखती है? आमतौर पर कुछ इस तरह:


अनुपात स्तंभ आंकड़ों के आधार पर योजनाबद्ध रिकॉर्ड की संख्या और वास्तव में पढ़ी गई संख्या के बीच "संबंध समय" को दर्शाता है:

Bitmap Heap Scan on ... (... rows=14831 ...) (actual ... rows=9 ...) 

यह मान जितना अधिक होगा, आंकड़े उतने ही खराब होंगे, जो आपकी तालिका की वास्तविक स्थिति को दर्शाते हैं। आम तौर पर, यह आमतौर पर सैकड़ों से अधिक नहीं होता है, इस उदाहरण में, डेढ़ हजार बार ।

यह एक अप्रभावी योजना की पसंद की ओर जाता है और, परिणामस्वरूप, आधार पर बेतहाशा लोड । इसे जल्दी से हटाने के लिए, आपको बस मैनुअल की सिफारिशों को सुनने और मुख्य तालिकाओं पर ANALYZE के माध्यम से जाने की आवश्यकता है।

ऊपर दिए गए उदाहरण के लिए इस ऑपरेशन से पहले और बाद में डेटाबेस सर्वर पर सीपीयू लोड है:

अक्सर अद्यतन तालिका

लेकिन क्या होगा अगर तालिका वास्तव में बड़ी संख्या में रिकॉर्ड बदलती है? उदाहरण के लिए, यह किसी प्रकार की बफर या प्रोसेसिंग कतार है जहां नए रिकॉर्ड लगातार जोड़े जाते हैं और पुराने हटा दिए जाते हैं।

इस स्थिति में, निम्न कॉन्फ़िगरेशन पैरामीटर हमारी मदद करेंगे:

ऑटोवैक्यूम_नपटाइम (पूर्णांक)
एकल डेटाबेस के लिए दो ऑटो-क्लीन रन के बीच न्यूनतम विलंब सेट करता है। ऑटो-क्लीनिंग डेमॉन डेटाबेस को निर्दिष्ट समय अंतराल पर स्कैन करता है और इस डेटाबेस में तालिकाओं के लिए आवश्यक होने पर VACUUM और ANALYZE कमांड जारी करता है। यदि यह मान इकाइयों के बिना निर्दिष्ट किया जाता है, तो इसे सेकंड में सेट माना जाता है। डिफ़ॉल्ट रूप से, देरी एक मिनट (1 मिनट) है। यह पैरामीटर केवल postgresql.conf में या कमांड लाइन पर सर्वर शुरू होने पर सेट किया जा सकता है।

ऑटोवैकुम_यानालीज़_थ्रेशोल्ड (पूर्णांक)
जोड़े गए, संशोधित या हटाए गए टुपल्स की न्यूनतम संख्या सेट करता है, जिस पर ANALYZE को एक ही तालिका के लिए निष्पादित किया जाएगा। डिफ़ॉल्ट मान 50 tuples है। यह पैरामीटर केवल postgresql.conf में या कमांड लाइन पर सर्वर शुरू होने पर सेट किया जा सकता है। हालांकि, इस मान को उनकी संग्रहण सेटिंग में परिवर्तन करके चयनित तालिकाओं के लिए ओवरराइड किया जा सकता है ।

ऑटोवैक्यूम_अनलीज़_सेले_फैक्टर (फ्लोटिंग पॉइंट)
तालिका का आकार निर्दिष्ट करता है जब ANALYZE कमांड थ्रेशोल्ड चयनित होने पर autovacuum_analyze_threshold में जोड़ा जाएगा। डिफ़ॉल्ट मान 0.1 (तालिका आकार का 10%) है। सर्वर शुरू होने पर आप इस पैरामीटर को केवल postgresql.conf या कमांड लाइन पर सेट कर सकते हैं। हालांकि, इस मान को उनकी संग्रहण सेटिंग में परिवर्तन करके चयनित तालिकाओं के लिए ओवरराइड किया जा सकता है ।

SSZB

कभी-कभी सर्वर सेट करते समय, ऑटोवैक्यूम_नैप्टाइम को "दिन में एक बार" (1 डी) " कुचल " दिया जाता है ताकि ऑटोवैक्यूम्स डेटाबेस के आसपास कम बार जाएं और कम संसाधन खाएं।

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

क्योंकि पूरी सूची से बहुत विशिष्ट परिभाषा को संसाधित करने की आवश्यकता है, ऑटोकैसम प्रक्रिया के आरंभ के दौरान, यह संसाधनों का काफी हिस्सा ले सकता है और सर्वर को धीमा कर सकता है ।

बस इस मामले में, आपको बार-बार संशोधित तालिका के साथ समस्याएं होंगी।

यहाँ - या तो अधिक पर्याप्त लॉन्च अंतराल सेट करें, या कुछ लागू कारणों (उदाहरण के लिए, बाहरी टाइमर या कतार प्रसंस्करण के अगले चरण के अंत के बाद) में ऐसी तालिका के अनुसार "मैनुअल" मोड में ANALYZE का पीछा करें।

कॉमरेड, आंकड़ों को अपडेट रखें!