आवश्यक PostgreSQL निगरानी - भाग 3

आपको अपने PostgreSQL परिनियोजन के किन मीट्रिक की निगरानी करनी चाहिए? ब्लॉग पोस्ट की इस श्रृंखला का उद्देश्य आवश्यक निगरानी क्रियाओं का एक न्यूनतम, प्रारंभिक सेट प्रदान करना है जिसे आपको अपने पोस्टग्रेज सर्वर के स्वास्थ्य और स्थिरता को सुनिश्चित करने के लिए लागू करना चाहिए।

यह ब्लॉग श्रृंखला का तीसरा और अंतिम भाग है, और इसमें तालिका-, अनुक्रमणिका- और सिस्टम-स्तरीय मीट्रिक शामिल हैं। पहला एक कवर किया गया क्लस्टर-स्तरीय मीट्रिक और दूसरा एक कवर किया गया डेटाबेस-स्तरीय मीट्रिक।

टेबल लेवल

आमतौर पर, डेटाबेस में डेटा 80-20 नियम का पालन करता है। 20% तालिकाओं में अधिकांश डेटा होता है और इन्हें सबसे अधिक एक्सेस या उत्परिवर्तित किया जाता है। केवल इन तालिकाओं के लिए अतिरिक्त निगरानी स्थापित करने से ऐसी जानकारी मिल सकती है जो महत्वपूर्ण होने के बावजूद कम मात्रा में होती है।

यहां कुछ तालिका-स्तरीय मीट्रिक देखने लायक हैं:

1. टेबल का आकार

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

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

कार्रवाई:प्रत्येक सप्ताह/महीने में तालिका के आकार में वृद्धि की निगरानी करें, अचानक परिवर्तनों की जांच करें।

कैसे करें:

-- returns the size for each table
SELECT schemaname || '.' || relname,
       pg_size_pretty(pg_table_size(schemaname || '.' || relname))
  FROM pg_stat_user_tables;

2. टेबल ब्लोट

Postgres के MVCC आर्किटेक्चर के कारण, पंक्तियों के पुराने संस्करण प्रत्येक तालिका के लिए भौतिक डेटा फ़ाइलों में मौजूद होते हैं, और इसे bloat कहा जाता है। . अप्रचलित पंक्ति संस्करणों को हटाने के लिए ऑपरेशन को वैक्यूम . कहा जाता है . पोस्टग्रेस ऑटोवैक्यूम . नामक एक पृष्ठभूमि प्रक्रिया चलाता है , जो उम्मीदवार तालिकाओं (कॉन्फ़िगर करने योग्य मापदंडों के आधार पर) को उठाता है और उन्हें आपके लिए खाली कर देता है।

ब्लोट टेबल संचालन को धीमा कर देता है और डिस्क स्थान बर्बाद कर देता है, और ऑटोवैक्यूम के साथ भी भाग सकता है। ब्लोट की निगरानी, ​​बाइट्स की निरपेक्ष संख्या के साथ-साथ प्रतिशत (कुल डेटा के लिए मृत डेटा का) के रूप में आवश्यक है।

इस मीट्रिक की निगरानी या तो व्यक्तिगत तालिका स्तर पर, या चयनित तालिकाओं में समग्र रूप में या डेटाबेस स्तर पर की जा सकती है।

कार्रवाई:टेबल ब्लोट को बाइट्स और प्रतिशत के रूप में लगातार मॉनिटर करें, यदि मान एक सेट थ्रेशोल्ड से अधिक है, तो अलर्ट करें, आवश्यकतानुसार VACUUM करें।

कैसे करें:

ब्लोट अनुमान प्राप्त करने के लिए check_postgres orpgmetrics का उपयोग करें। अधिक जानकारी के लिए thewiki देखें।

3. अनुक्रमिक स्कैन

जब क्वेरी निष्पादित की जाती हैं जो उपलब्ध इंडेक्स का बेहतर उपयोग नहीं करती हैं, या यदि तालिका से जुड़ी सांख्यिकीय जानकारी बहुत पुरानी है, तो पोस्टग्रेज़ को तालिका की प्रत्येक पंक्ति से गुजरना पड़ सकता है। इसे अनुक्रमिक स्कैन . कहा जाता है , और सामान्य मामले में बहुत वांछनीय नहीं है। इंडेक्स स्कैन . करना बेहतर होगा , जहां तालिका की पंक्तियों को इंडेक्स लुकअप के माध्यम से अप्रत्यक्ष रूप से एक्सेस किया जाता है।

PostgreSQL आपको बता सकता है कि कितनी बार एक टेबल को क्रमिक रूप से स्कैन किया गया था, और कितनी बार एक इंडेक्स का उपयोग किया गया था। आप इसका उपयोग या तो अनुक्रमिक स्कैन की संख्या की निगरानी के लिए कर सकते हैं (यदि आप उन्हें पूरी तरह से टालना चाहते हैं) या कुल स्कैन के प्रतिशत के रूप में।

कार्रवाई:seq की लगातार निगरानी करें। स्कैन गिनती या प्रतिशत, अलर्ट यदि मान एक निर्धारित सीमा से अधिक है।

कैसे करें:

-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
        seq_scan,
        round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
 FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;

सूचकांक स्तर

1. अनुक्रमणिका आकार

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

अनुचित रूप से बड़ी अनुक्रमणिका ब्लोट, या केवल एक बुरी तरह से डिज़ाइन किए गए अनुक्रमणिका के कारण हो सकती है। किसी भी मामले में कारण को ठीक करना (या तो अनुक्रमणिका का पुनर्निर्माण करके या क्वेरी/अनुक्रमणिका को पुन:सक्रिय करके) तेजी से क्वेरी समय प्राप्त कर सकता है, इसलिए यह बड़ी अनुक्रमणिका की जांच करने योग्य है।

कार्रवाई:प्रत्येक सप्ताह/महीने में दिलचस्प अनुक्रमणिका के कुल आकार की निगरानी करें, जब अनुचित रूप से बड़ा हो तो जांच करें।

कैसे करें:

-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
       pg_size_pretty(pg_total_relation_size(indexrelid))
  FROM pg_stat_user_indexes;

2. इंडेक्स ब्लोट

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

कार्रवाई:इंडेक्स ब्लोट को बाइट्स और प्रतिशत के रूप में लगातार मॉनिटर करें, अगर मान एक सेट थ्रेशोल्ड से अधिक हो तो अलर्ट करें।

कैसे करें:

ब्लोट अनुमान प्राप्त करने के लिए check_postgres orpgmetrics का उपयोग करें। अधिक जानकारी के लिए thewiki देखें।

3. कैश हिट अनुपात

PostgreSQL मेमोरी में इंडेक्स (और टेबल भी) के अक्सर एक्सेस किए गए क्षेत्रों को कैश करता है। यदि आपने पंक्तियों को पुनः प्राप्त करने के अलावा तालिकाओं को स्पर्श न करने के लिए अपने प्रश्नों को ट्यून किया है, तो अगला चरण उन महत्वपूर्ण अनुक्रमणिकाओं के लिए अधिकतम कैश निवास सुनिश्चित करना है जो वास्तव में आपके प्रश्नों को गति दे रहे हैं।

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

कार्रवाई:कैश हिट अनुपात प्रतिशत की लगातार निगरानी करें, यदि मान एक निर्धारित सीमा से नीचे आता है तो अलर्ट करें। महत्वपूर्ण अनुक्रमणिका के लिए निम्न मानों की जाँच करें।

कैसे करें:

-- returns the cache hit ratio as a percentage, for each index
  SELECT schemaname || '.' || indexrelname AS index_name,
           round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 / 
         pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
    FROM pg_stat_user_indexes
   WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;

सिस्टम स्तर

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

1. प्रयुक्त मेमोरी

आधुनिक लिनक्स सिस्टम में जटिल मेमोरी अकाउंटिंग होती है। हम "उपयोग की गई मेमोरी" की निगरानी करने की सलाह देते हैं, जो कि स्मृति के लिए लेखांकन के बाद बची हुई मेमोरी है जिसेमुक्त . के रूप में चिह्नित किया गया है , बफ़र्स . के रूप में , संचित . के रूप में , और स्लैब . के रूप में . बफर और कैश दबाव में छूट देंगे, और इसलिए अधिकांश (आमतौर पर 95% से अधिक) स्लैब होंगे।

हालाँकि, उपयोग की गई मेमोरी को एक उपयुक्त लंबी अवधि में मापा जाना चाहिए। यदि आपके पास बैच की नौकरियां, रिपोर्ट, ईटीएल इत्यादि हैं जो सप्ताहांत पर चलती हैं, तो अवधि एक सप्ताह होगी। वास्तविक मीट्रिक जिसकी आपको निगरानी करने की आवश्यकता होगी, वह है इस अवधि में अधिकतम उपयोग की गई मेमोरी।

आमतौर पर, जैसे-जैसे आपके डेटाबेस का आकार बढ़ता है, यह मान रेंगने लगता है। आपको यह सुनिश्चित करना होगा कि अधिकतम मेमोरी उपयोग उपलब्ध मेमोरी की आरामदायक सीमा के भीतर हो, जैसे कि 60-80%। इसकी उपेक्षा करने से स्मृति की कमी के कारण आपका विश्लेषण/OLAP कार्यभार विफल हो जाएगा।

कार्रवाई:एक सप्ताह/पखवाड़े में अधिकतम उपयोग की गई मेमोरी की निगरानी करें, अगर यह एक निर्धारित सीमा से अधिक है, तो अलर्ट करें।

कैसे करें :

उपयोग की गई मेमोरी MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab द्वारा दी गई है। ,जहां Mem* फ़ील्ड /proc/meminfo . से हैं . अधिक जानकारी के लिए, RedHat का यह लेख देखें।

2. औसत लोड करें

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

किसी दिए गए पोस्टग्रेज सर्वर के लिए, लोड औसत एक व्यावसायिक चक्र (जैसे एक सप्ताह, बैच जॉब रन सहित) पर एक उचित सीमा के भीतर रहना चाहिए।

कार्रवाई:प्रत्येक दिन/सप्ताह में अधिकतम लोड औसत की निगरानी करें, बढ़ते रुझानों की जांच करें।

कैसे करें :

1 मिनट, 5 मिनट और 15 मिनट का लोड औसत /proc/loadavg फ़ाइल में पहली पंक्ति के पहले 3 फ़ील्ड हैं ।

3. खाली डिस्क स्थान

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

कार्रवाई:सभी प्रासंगिक फाइल सिस्टम पर लगातार खाली डिस्क स्थान और इनोड उपयोग की निगरानी करें, अगर मान एक निर्धारित सीमा से नीचे आते हैं तो अलर्ट करें।

कैसे करें :

फ़ाइल सिस्टम में खाली डिस्क स्थान /proc . में किसी भी फ़ाइल को पढ़कर सीधे पुनर्प्राप्त करने योग्य नहीं है . आप stat -f /path/to/mount . का उपयोग कर सकते हैं या यहां तक ​​कि df एक विशिष्ट, माउंटेड फाइल सिस्टम के लिए प्रयुक्त, खाली और आरक्षित डिस्क स्थान का पता लगाने के लिए।

त्वरित संदर्भ

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

क्लस्टर लेवल

• लेन-देन आईडी श्रेणी
• बैकएंड की संख्या
• निष्क्रिय प्रतिकृति स्लॉट
• बैकएंड वेटिंग ऑन लॉक्स
• लेन-देन में निष्क्रिय बैकएंड्स
• सक्रिय कनेक्शन के लिए प्रतिकृति अंतराल
• प्रतिकृति स्लॉट के लिए प्रतिकृति अंतराल
• वाल फ़ाइल गणना
• रेडी-टू-संग्रह WAL फ़ाइल गणना

डेटाबेस स्तर

• कनेक्टेड क्लाइंट
• आकार
• सभी टेबल पर टेबल ब्लोट
• सभी इंडेक्स में इंडेक्स ब्लोट
• लंबे समय तक चलने वाले लेन-देन
• गतिरोध
• सबसे पुराना वैक्यूम
• सबसे पुराना विश्लेषण

टेबल लेवल

• टेबल का आकार
• टेबल ब्लोट
• अनुक्रमिक स्कैन

सूचकांक स्तर

• सूचकांक आकार
• इंडेक्स ब्लोट
• कैश हिट अनुपात

सिस्टम-स्तर

• प्रयुक्त मेमोरी
• लोड औसत
• निःशुल्क डिस्क स्थान

इन मेट्रिक को कलेक्ट करना

उपरोक्त अनुभाग चल रहे Postgres सर्वर से आवश्यक मीट्रिक निकालने के लिए SQL कथन प्रदान करते हैं। यदि आप स्वयं स्क्रिप्ट नहीं लिखना चाहते हैं, तो ओपन सोर्स टूल pgmetrics देखें। यह ऊपर दिए गए मेट्रिक और बहुत कुछ एकत्र कर सकता है, और उन्हें टेक्स्ट और JSON प्रारूपों में रिपोर्ट कर सकता है।

आप सीधे हमारी व्यावसायिक पेशकश, pgDash को pgmetrics रिपोर्ट भेज सकते हैं, जो ग्राफ़ प्रदर्शित करने और अलर्ट करने के लिए इन रिपोर्टों को संग्रहीत और संसाधित करती है।