आपको अपने PostgreSQL परिनियोजन के किन मीट्रिक की निगरानी करनी चाहिए? ब्लॉग पोस्ट की इस श्रृंखला का उद्देश्य आवश्यक निगरानी क्रियाओं का एक न्यूनतम, प्रारंभिक सेट प्रदान करना है जिसे आपको अपने पोस्टग्रेज सर्वर के स्वास्थ्य और स्थिरता को सुनिश्चित करने के लिए लागू करना चाहिए।
यह ब्लॉग श्रृंखला का दूसरा भाग है, और इसमें डेटाबेस-स्तरीय पैरामीटर शामिल हैं। पहला कवर क्लस्टर-स्तरीय पैरामीटर।
भाग 2:डेटाबेस स्तर
इस भाग में, हम मेट्रिक्स और सूचनाओं को देखते हैं जिनकी निगरानी आपके द्वारा उपयोग किए जाने वाले प्रत्येक महत्वपूर्ण डेटाबेस के लिए की जानी चाहिए।
नीचे सूचीबद्ध अधिकांश SQL क्वेरीज़ को विचाराधीन डेटाबेस से कनेक्ट होने के दौरान चलाया जाना चाहिए।
1. जुड़े हुए ग्राहक
कनेक्टेड क्लाइंट OS और सिस्टम संसाधन लेते हैं। Postgres में एक प्रक्रिया-प्रति-क्लाइंटआर्किटेक्चर है, और बहुत से क्लाइंट क्वेरी प्रतिक्रिया समय को हमेशा के लिए धीमा कर सकते हैं। पोस्टग्रेज सर्वर को सेवा देने वाले कनेक्शनों की संख्या को कम करने के लिए PgBouncer orpgpool का उपयोग करने पर विचार करें।
एप्लिकेशन अपडेट के बाद बेसलाइन में होने वाले परिवर्तनों पर नज़र रखें और ट्रैफ़िक में वृद्धि के कारण कनेक्शन में वृद्धि करें।
कार्रवाई:प्रत्येक दिन/सप्ताह में जुड़े ग्राहकों की अधिकतम संख्या की निगरानी करें, प्रवृत्ति में बदलाव की जांच करें।
कैसे करें:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. आकार
डेटाबेस द्वारा उपयोग किए जाने वाले वास्तविक डिस्क आकार की निगरानी की जानी चाहिए। ज्यादातर मामलों में, डेटाबेस का आकार बढ़ता रहता है, इसलिए यह विकास दर है जो अधिक दिलचस्प है। फिर से, नई एप्लिकेशन रिलीज़ के बाद बढ़ी हुई वृद्धि दर से सावधान रहें।
कार्रवाई:प्रत्येक सप्ताह/महीने में डेटाबेस के आकार की वृद्धि की निगरानी करें, रुझानों की जांच करें, पुन:प्रावधान करें।
कैसे करें:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. सभी टेबल पर टेबल ब्लोट
Postgres के MVCC आर्किटेक्चर के कारण, पंक्तियों के पुराने संस्करण प्रत्येक तालिका के लिए भौतिक डेटा फ़ाइलों में मौजूद होते हैं, और इसे bloat कहा जाता है। . अप्रचलित पंक्ति संस्करणों को हटाने के लिए ऑपरेशन को वैक्यूम . कहा जाता है . पोस्टग्रेस ऑटोवैक्यूम . नामक एक पृष्ठभूमि प्रक्रिया चलाता है , जो उम्मीदवार तालिकाओं (कॉन्फ़िगर करने योग्य मापदंडों के आधार पर) को उठाता है और उन्हें आपके लिए खाली कर देता है।
ब्लोट टेबल संचालन को धीमा कर देता है और डिस्क स्थान बर्बाद कर देता है, और ऑटोवैक्यूम के साथ भी भाग सकता है। ब्लोट की निगरानी, बाइट्स की पूर्ण संख्या के साथ-साथ प्रतिशत (कुल डेटा के लिए मृत डेटा) के रूप में, आवश्यक है। यह डेटाबेस स्तर पर सभी तालिकाओं में कुल मिलाकर किया जा सकता है, जिसमें "सबसे फूला हुआ टेबल" में ड्रिल डाउन करने की संभावना है।
कार्रवाई:बाइट्स और प्रतिशत के रूप में कुल ब्लोट की लगातार निगरानी करें, यदि मान एक निर्धारित सीमा से अधिक हो तो अलर्ट करें।
कैसे करें:
ब्लोट अनुमान प्राप्त करने के लिए check_postgres orpgmetrics का उपयोग करें। अधिक जानकारी के लिए thewiki देखें।
4. सभी इंडेक्स में इंडेक्स ब्लोट
ब्लोटेड इंडेक्स इन्सर्ट को धीमा कर सकते हैं और लुकअप परफॉर्मेंस को कम कर सकते हैं। इंडेक्स के ब्लोट को एक निरपेक्ष मान (बाइट्स की संख्या) और प्रतिशत के रूप में मॉनिटर करें। बहुत अधिक फूला हुआ होने पर अनुक्रमणिका को फिर से बनाना होगा।
कार्रवाई:बाइट्स और प्रतिशत के रूप में कुल ब्लोट की लगातार निगरानी करें, यदि मान एक निर्धारित सीमा से अधिक हो तो अलर्ट करें।
कैसे करें:
ब्लोट अनुमान प्राप्त करने के लिए check_postgres orpgmetrics का उपयोग करें। अधिक जानकारी के लिए thewiki देखें।
5. लंबे समय तक चलने वाले लेन-देन
बहुत लंबे समय तक खुला लेनदेन PostgreSQL के लिए अच्छी खबर नहीं है। लंबे समय तक चलने वाले लेन-देन WAL फ़ाइलों के प्रतिधारण का कारण बन सकते हैं, ताले पर लटक सकते हैं और वैक्यूम को रोक सकते हैं। लेन-देन की अवधि को यथासंभव कम रखने के लिए एप्लिकेशन को डिज़ाइन किया जाना चाहिए।
लंबे समय से चल रहे लेन-देन को चलाने वाले बैकएंड को pg_cancel_backend() के साथ मार दिया जा सकता है और pg_terminate_backend() कार्य।
कार्रवाई:एक निर्धारित समय अवधि से अधिक समय से चल रहे लेन-देन की संख्या की लगातार निगरानी करें, यदि मान एक निर्धारित सीमा से अधिक हो तो अलर्ट करें।
कैसे करें:
-- returns the count of transactions that have been running for more than a day
SELECT count(*)
FROM pg_stat_activity
WHERE xact_start < now() - '24 hours'::interval;6. गतिरोध
PostgreSQL में, बैकएंड पंक्तियों और तालिकाओं पर ताले लगाता है क्योंकि यह पंक्तियों को संशोधित करने वाले प्रश्नों को निष्पादित करने के बारे में है। प्रश्न स्पष्ट ताले भी लगा सकते हैं (जैसे चुनें .. अद्यतन के लिए ) बहु-थ्रेडेड प्रोग्रामिंग की तरह, विपरीत क्रम में या तो स्पष्ट रूप से या स्पष्ट रूप से ताले लगाने वाले दो लेन-देन के परिणामस्वरूप गतिरोध हो सकता है।
PostgreSQL गतिरोध का पता लगाएगा और इसमें शामिल लेन-देन में से एक को रोलबैक करेगा (लेन-देन द्वारा आयोजित सभी लॉक तब जारी किए जाते हैं जब इसे प्रतिबद्ध या वापस रोल किया जाता है)। विवरण PostgreSQL लॉगिंग गंतव्य में लॉग किया जाएगा।
गतिरोध की संभावना से बचने के लिए अनुप्रयोगों को डिज़ाइन किया जाना चाहिए। गतिरोध की स्थिति में वे लेन-देन का पुन:प्रयास करने का विकल्प भी चुन सकते हैं।
कार्रवाई:प्रत्येक दिन/सप्ताह में गतिरोध की निगरानी करें, गणना कम करने के लिए एप्लिकेशन को फिर से डिज़ाइन करें, परिवर्तनों की जांच करें।
कैसे करें:
अतिरिक्त जानकारी के साथ गतिरोध की घटनाओं को PostgreSQL लॉग फ़ाइल में लॉग किया जाता है। इस जानकारी को निकालने के लिए pgmetrics, pgbadger या अन्य PostgreSQL-विशिष्ट लॉग प्रोसेसिंग टूल का उपयोग करें।
7. सबसे पुराना वैक्यूम
टेबल की नियमित वैक्यूमिंग, या तो ऑटोवैक्यूम के साथ, या अनुसूचित नौकरियों के साथ, या मैन्युअल रूप से टेबल संचालन को तेज रखने के लिए जरूरी है। हालांकि, लंबे समय तक चलने वाले लेन-देन, निष्क्रिय प्रतिकृति स्लॉट आदि सहित कई कारणों से रिक्तियां विफल हो सकती हैं।
चूंकि पोस्टग्रेज की दुनिया में टेबल की नियमित वैक्यूमिंग काफी महत्वपूर्ण है, इसलिए यह नियमित रूप से जांचना सबसे अच्छा है कि क्या सभी टेबल को कम से कम एक बार एक सेट अंतराल में वैक्यूम किया गया है।
और यद्यपि वे दृष्टि से बाहर और दिमाग से बाहर हो जाते हैं, सिस्टम कैटलॉगटेबल्स को भी वैक्यूम किया जाना चाहिए।
कार्रवाई:लगातार जांचें कि क्या कोई तालिका अंतिम निर्धारित घंटों/दिनों में वैक्यूम नहीं की गई है, यदि कोई हो तो अलर्ट करें।
कैसे करें:
-- returns the top 5 tables vacuumed least recently
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
ORDER BY last_vacuum ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been vacuumed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
WHERE last_vacuum < now() - '7 days'::interval;8. सबसे पुराना विश्लेषण
अपनी SELECT क्वेरीज़ को निष्पादित करने के लिए, क्वेरी प्लानर एकनिष्पादन योजना . तैयार करता है यह वर्णन करता है कि कौन सी अनुक्रमणिका और तालिकाओं को पढ़ना है, और कैसे। एक कुशल निष्पादन योजना के साथ आने के लिए, योजनाकार को मूल्यों के वितरण, टुपल्स के आकार आदि के बारे में आंकड़े होने चाहिए। तालिका में डेटा के बारे में ऐसी सांख्यिकीय जानकारी विश्लेषण . द्वारा एकत्रित और अनुरक्षित की जाती है संचालन। अप-टू-डेट आँकड़ों वाली तालिकाएँ तेज़ क्वेरी और कम I/O का परिणाम देती हैं।
ऊपर उल्लिखित ऑटोवैक्यूम प्रक्रिया आमतौर पर ANALYZE . भी चलती है मेज पर यह इस जानकारी को अद्यतन रखने के लिए रिक्त करता है। हालाँकि, यह अकेले आपकी तालिकाओं के लिए पर्याप्त विश्लेषण कवरेज प्रदान नहीं कर सकता है। आप ANALYZE को शेड्यूल किए गए कार्यों के रूप में चलाकर या महत्वपूर्ण तालिका परिवर्तन के बाद पूरक करना चाहेंगे।
क्वेरी प्रदर्शन के हित में, यह लगातार जांचना सबसे अच्छा है कि क्या सभी तालिकाओं का एक निर्धारित अंतराल में कम से कम एक बार विश्लेषण किया गया है।
कार्रवाई:लगातार जांचें कि क्या किसी तालिका का विश्लेषण पिछले निर्धारित घंटों/दिनों में नहीं किया गया है, यदि कोई हो तो चेतावनी दें।
कैसे करें:
-- returns the top 5 tables analyzed least recently
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
ORDER BY last_analyze ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been analyzed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
WHERE last_analyze < now() - '7 days'::interval;इन मेट्रिक को कलेक्ट करना
उपरोक्त अनुभाग चल रहे Postgres सर्वर से आवश्यक मीट्रिक निकालने के लिए SQL कथन प्रदान करते हैं। यदि आप स्वयं स्क्रिप्ट नहीं लिखना चाहते हैं, तो ओपन सोर्स टूल pgmetrics देखें। यह ऊपर दिए गए मेट्रिक और बहुत कुछ एकत्र कर सकता है, और उन्हें टेक्स्ट और JSON प्रारूपों में रिपोर्ट कर सकता है।
आप सीधे हमारी व्यावसायिक पेशकश, pgDash को pgmetrics रिपोर्ट भेज सकते हैं, जो ग्राफ़ प्रदर्शित करने और अलर्ट करने के लिए इन रिपोर्टों को संग्रहीत और संसाधित करती है।
अगला ऊपर
इस श्रृंखला के अगले भाग में टेबल-लेवल, इंडेक्स-लेवललैंड सिस्टम-लेवल मेट्रिक्स शामिल होंगे। बने रहें!
