आपके PostgreSQL परिनियोजन की थोड़ी सी देखभाल और संवारने से प्रदर्शन को सुनिश्चित करने, अप्रिय खोजों से बचने और आत्मविश्वास से भरी भविष्यवाणी स्थापित करने में बहुत मदद मिलती है। यहां 7 चीजें हैं जिन पर आपको नजर रखनी चाहिए।
टेबल ब्लोट
PostgreSQL एमवीसीसी नामक तकनीक का उपयोग करके लेनदेन को लागू करता है। एमवीसीसी बहुत लंबा है और इसमें विस्तार से चर्चा करने के लिए एक विषय शामिल है, लेकिन तीन हैं चीजें जो आपको जरूरी इसके बारे में जानें:
- पंक्ति को हटाना केवल भविष्य के लेन-देन के लिए "अदृश्य" के रूप में चिह्नित करता है।
- पंक्ति को अपडेट करने से पंक्ति का एक नया संस्करण बन जाता है। पुराने संस्करण को भविष्य के लेन-देन के लिए अदृश्य के रूप में चिह्नित किया गया है, और नए संस्करण को दृश्यमान के रूप में चिह्नित किया गया है।
- समय-समय पर, किसी को वर्तमान में चल रहे सभी लेन-देन को देखने और कहने की आवश्यकता होती है:ठीक है, यहां सबसे पुराना लेनदेन #42 है, इसलिए प्रत्येक पंक्ति संस्करण जो #42 के लिए अदृश्य है, डेटा स्थिरता को नुकसान पहुंचाए बिना भौतिक रूप से हटाया जा सकता है।
इस प्रकार एमवीसीसी काम करता है (अनिवार्य रूप से), और इसका निहितार्थ यह है कि अपडेट होगा अपना भौतिक डेटाबेस संग्रहण फ़ुटप्रिंट बढ़ाएं, और हटाता है नहीं कम करना एमवीसीसी चीजों को करने के लिए एक आलसी तरीका की तरह लगता है, लेकिन यह लोकप्रिय है क्योंकि यह स्थिरता और प्रदर्शन दोनों प्रदान करता है।
तालिका में अवांछित, अप्रचलित पंक्ति संस्करणों को bloat . कहा जाता है (या डेड्रो ) ब्लोट को साफ करने वाली प्रक्रिया को वैक्यूम . कहा जाता है . PostgreSQL में ऑटोवैक्यूम नामक ट्यून करने योग्य थ्रेशोल्ड और निश्चित रूप से VACUUM कमांड के साथ एक स्वचालित रूप से ट्रिगर वैक्यूम प्रक्रिया है।
सामान्य तौर पर, ब्लोट गलत दृश्यता मानचित्रों और व्यर्थ डिस्क I/O के कारण प्रश्नों को धीमा कर सकता है।
इस वजह से, आपको नियमित रूप से:
- डेटाबेस में ब्लोट की मात्रा की निगरानी करें
- वैक्यूम को नियमित रूप से चलाएं
- निगरानी करें कि क्या सभी टेबलों के लिए वैक्यूम नियमित रूप से चलाया जा रहा है
प्रति-तालिका ब्लोट अनुमान प्रदान करने के लिए कुछ SQL क्वेरी हैं। ओपन सोर्स टूलपीजीमेट्रिक्स ब्लोट अनुमानों के साथ-साथ मैनुअल और स्वचालित वैक्यूम के अंतिम रन टाइम प्रदान करता है।
इंडेक्स ब्लोट
इंडेक्स भी फूल सकते हैं। हालांकि इंडेक्स की आंतरिक संरचना SQL उपयोगकर्ता के लिए अपारदर्शी है और इंडेक्स प्रकार (बीट्री, हैश, जीआईएन, जीआईएसटी, आदि) से भिन्न होती है, सामान्य विचार यह रहता है कि जब इंडेक्स द्वारा संदर्भित पंक्तियों को हटा दिया जाता है, तो संबंधित जानकारी द्वारा कब्जा कर लिया गया स्थान इंडेक्स के अंदर केवल तार्किक रूप से हटा दिया जाता है और फाइल सिस्टम पर वापस नहीं छोड़ा जाता है। तार्किक रूप से हटाए गए स्थान को बाद में अनुक्रमणिका द्वारा पुन:उपयोग किया जा सकता है।
इंडेक्स के भौतिक आकार को छोटा करने के लिए Postgres प्राप्त करने के दो तरीके हैं:
- वैक्यूम कमांड का पूर्ण संस्करण
- रीइंडेक्स
इंडेक्स ब्लोट की निगरानी की जानी चाहिए, ताकि आप कम से कम अप्रयुक्त शेष स्थान की मात्रा से अवगत रहें। उच्च पंक्ति मंथन वाली तालिकाओं में नियमित अनुक्रमणिका पुनर्निर्माण कार्य सेट करना असामान्य नहीं है।
इंडेक्स ब्लोट भी पहले की तरह ही प्रश्नों द्वारा और pgmetrics के माध्यम से भी प्राप्त किया जा सकता है।
लंबे समय तक चलने वाले लेन-देन
लेन-देन को यथासंभव छोटा रखा जाना चाहिए, विशेष रूप से MVCC सिस्टम में।
कल्पना कीजिए कि कल एक लेन-देन शुरू हुआ और उसके ठीक बाद एक शून्य चल रहा था। अब जब तक यह लेन-देन खुला है, तब तक और रिक्तियाँ बेकार हैं, क्योंकि परिभाषा के अनुसार हमारे लेन-देन को सभी तालिकाओं की सभी पंक्तियों को देखने की आवश्यकता होगी क्योंकि वे तब थे जब हमारा लेन-देन कल शुरू हुआ था। भले ही हमारा लेन-देन केवल पढ़ने के लिए हो, फिर भी ऐसा ही होता है।
नतीजतन, लंबे समय तक चलने वाले लेन-देन ब्लोट बनाते हैं। वे सिस्टम संसाधनों पर भी लटके रहते हैं, असंबंधित ताले धारण करते हैं और गतिरोध की संभावना बढ़ाते हैं।
लंबे समय तक चलने वाले लेन-देन पर नज़र रखने का सबसे अच्छा तरीका एक निश्चित अवधि से अधिक समय से चल रहे लेनदेन की संख्या के लिए अलर्ट सेट करना है। आप इसे सांख्यिकी दृश्य से प्राप्त कर सकते हैंpg_stat_activity , इस तरह:
-- number of transactions that have been open for
-- more than 1 hour
SELECT count(*) FROM pg_stat_activity WHERE xact_start < now()-'1 hour'::interval;प्रतिकृति अंतराल
जब स्ट्रीमिंग प्रतिकृति का उपयोग प्राथमिक पोस्टग्रेएसक्यूएल सर्वर से हॉट स्टैंडबाय (उर्फ रीड रेप्लिका) में सभी परिवर्तनों को दोहराने के लिए किया जाता है, तो उस समय के बीच आमतौर पर थोड़ी देरी होती है जब प्राथमिक पर पंक्ति अपडेट होते हैं और जब परिवर्तन स्टैंडबाय से जुड़े अनुप्रयोगों के लिए दिखाई देते हैं। ।
हालांकि, ऐसे मामले हैं जब यह अंतराल बढ़ सकता है:
- स्टैंडबाय सिस्टम प्राथमिक फास्ट से परिवर्तनों को प्राप्त करने और लागू करने में असमर्थ है, आमतौर पर उच्च भार या कम प्रावधान के कारण इसके साथ बने रहने के लिए
- एक ख़राब नेटवर्क या डिस्क
- क्वेरी विरोध
एक उच्च या उससे भी बदतर, बढ़ते, प्रतिकृति अंतराल के साथ एक स्टैंडबाय के परिणामस्वरूप स्टैंडबाय लौटाने वाले पुराने डेटा पर पूछताछ हो सकती है, और एक स्टैंडबाय जो विफलता के लिए अनुपयुक्त है।
यदि आपके पास एक स्ट्रीमिंग प्रतिकृति सेटअप है, तो प्रत्येक प्राथमिक-स्टैंडबाय जोड़ी के बीच प्रतिकृति अंतराल की निगरानी बहुत महत्वपूर्ण है, और आप यह जांचने के लिए upalerts सेट करना चाहेंगे कि क्या प्रतिकृति अंतराल एक मिनट से अधिक है, या जो भी सीमा आपके सेटअप के लिए उपयुक्त है।
इस पोस्ट में प्राथमिक और स्टैंडबाय दोनों छोरों से प्रतिकृति अंतराल को मापने और मॉनिटर करने के तरीके के बारे में बहुत कुछ है।
निष्क्रिय प्रतिकृति स्लॉट
PostgreSQL 9.4 में पेश किए गए प्रतिकृति स्लॉट का उपयोग, स्ट्रीमिंग प्रतिकृति को अधिक मजबूत और कुशल बनाता है। अनिवार्य रूप से, स्टैंडबाय प्राथमिक को इसकी प्रतिकृति प्रगति की रिपोर्ट करता है, जो इस जानकारी को "प्रतिकृति स्लॉट" में संग्रहीत करता है।
इस वजह से, प्राइमरी को अब हर समय पता चलता है कि स्टैंडबाय से कितना पीछे है। यह प्राथमिक को स्टैंडबाय के ऑफ़लाइन होने पर WAL फ़ाइलों (जो प्रतिकृति को फिर से शुरू करने के लिए आवश्यक हैं) का पर्याप्त बैकलॉग बनाए रखने की अनुमति देता है। इस प्रकार जब स्टैंडबाय वापस आता है, लंबे समय के बाद भी, प्राथमिक अभी भी गारंटी दे सकता है कि प्रतिकृति फिर से शुरू की जा सकती है।
प्रतिकृति स्लॉट से पहले, प्राथमिक पुरानी WAL फ़ाइलों को साफ़ कर सकता है, क्योंकि उसे यह जानने का कोई रास्ता नहीं था कि उसे स्टैंडबाय की आवश्यकता है या नहीं। यदि स्टैंडबाय द्वारा आवश्यक WAL फ़ाइल को हटा दिया जाता है, तो प्रतिकृति को फिर से शुरू करने का कोई तरीका नहीं है; इसे नए सिरे से फिर से सेट करना होगा।
हालाँकि, WAL फ़ाइलों को अनिश्चित काल तक बनाए रखने का प्राथमिक व्यवहार एक और समस्या की ओर ले जाता है। यदि एक स्टैंडबाय को बंद कर दिया गया था और संबंधित प्रतिकृति स्लॉट को हटाया नहीं गया था, तो WAL फाइलें हमेशा के लिए बरकरार रखी जाएंगी। इस कारण से रखी गई WAL फाइलें max_wal_size . द्वारा निर्धारित सीमाओं के अधीन नहीं हैं और अन्य विन्यास विकल्प।
यह स्थिति तब तक बनी रहेगी जब तक कि WAL फ़ाइलें पूरे डिस्क स्थान को खा न लें, यहां तक कि PostgreSQL लॉग फ़ाइलों में कोई चेतावनी भी नहीं है।
कहने की जरूरत नहीं है, निष्क्रिय प्रतिकृति स्लॉट का पता चलने पर उन्हें निपटाया जाना चाहिए। निम्न का उपयोग करके अपने निष्क्रिय प्रतिकृति स्लॉट खोजें:
SELECT slot_name FROM pg_replication_slots WHERE NOT active;स्थिति का विश्लेषण करें
तालिका की सामग्री के बारे में सांख्यिकीय जानकारी एकत्र करने और अद्यतन करने के लिए ANALYZE को तालिकाओं पर चलाया जाता है। इस जानकारी का उपयोग क्वेरी प्लानर द्वारा प्रत्येक SQL क्वेरी के लिए निष्पादन योजना तैयार करने के लिए किया जाता है। तालिका सामग्री के बारे में अप-टू-डेट आँकड़े बेहतर निष्पादन योजना का परिणाम देते हैं, जिसके परिणामस्वरूप एक तेज़ क्वेरी होती है।
ऑटोवैक्यूम डेमॉन आमतौर पर VACUUM के बाद ANALYZE चलाता है। हालांकि यह विश्लेषण के लिए पर्याप्त नहीं हो सकता है। अगर वितरण डेटा में अक्सर परिवर्तन करने योग्य परिवर्तन होते हैं, आपको अधिक बार ANALYZE चलाना चाहिए।
आमतौर पर ANALYZE काफी अच्छी तरह से व्यवहार किया जाता है - इसे केवल रीड लॉक की आवश्यकता होती है, किसी भी संसाधन का बहुत अधिक उपयोग नहीं करता है और उचित समय में पूरा करता है। इसे अधिक बार चलाने के पक्ष में यह सुरक्षित है।
उन तालिकाओं पर नज़र रखना जिनका विश्लेषण कुछ समय से नहीं किया गया है, एक अच्छा विचार है। पता लगाएं कि पिछली बार आपकी तालिकाओं का क्वेरी के साथ विश्लेषण कब किया गया था (स्वतः-):
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;संसाधन उपयोग
सीपीयू लोड, मेमोरी और डिस्क उपयोग की निगरानी यह सुनिश्चित करने में एक लंबा रास्ता तय करती है कि आपके पास अपने डेटाबेस का उपयोग करके एप्लिकेशन की बढ़ती जरूरतों को पूरा करने के लिए पर्याप्त क्षमता है।
PostgreSQL एक कनेक्शन को संभालने के लिए एक प्रक्रिया को जन्म देता है। हालांकि यह आजकल सबसे अधिक स्केलेबल आर्किटेक्चर नहीं हो सकता है, लेकिन यह स्थिरता के मोर्चे पर बहुत योगदान देता है। यह OS लोड औसत को अधिक सार्थक भी बनाता है। जैसा कि आमतौर पर पोस्टग्रेएसक्यूएलबॉक्स केवल पोस्टग्रेएसक्यूएल चलाते हैं, 3 का लोड औसत आमतौर पर इसका मतलब है कि सीपीयू कोर के उपलब्ध होने की प्रतीक्षा में 3 कनेक्शन हैं ताकि वे निर्धारित किए जा सकें। एक सामान्य दिन या सप्ताह के दौरान अपने अधिकतम लोड औसत की निगरानी से यह अनुमान लगाया जा सकता है कि आपका बॉक्स CPU के मोर्चे पर कितना अधिक या कम प्रावधानित है।
मेमोरी और फ्री डिस्क स्पेस निश्चित रूप से मॉनिटर करने के लिए मानक चीजें हैं। अधिक कनेक्शन और लंबे समय तक चलने वाले लेन-देन स्मृति पर अधिक मांग रखते हैं। डिस्क मुक्त स्थान की निगरानी करते समय, इसे प्रति टेबल स्पेस ट्रैक करना याद रखें।
