PostgreSQL मॉनिटरिंग की मूल बातें। एलेक्सी लेसोव्स्की

मेरा सुझाव है कि आप डेटा एग्रेट "फंडामेंटल्स ऑफ पोस्टग्रेएसक्यूएल मॉनिटरिंग" से एलेक्सी लेसोव्स्की की रिपोर्ट की प्रतिलेख पढ़ें।

इस रिपोर्ट में, एलेक्सी लेसोव्स्की प्रगति के बाद के आँकड़ों के प्रमुख बिंदुओं के बारे में बात करेंगे, उनका क्या मतलब है, और उन्हें निगरानी में क्यों उपस्थित होना चाहिए; मॉनिटरिंग में कौन से ग्राफ़ होने चाहिए, उन्हें कैसे जोड़ा जाए और उनकी व्याख्या कैसे की जाए। रिपोर्ट उन डेटाबेस प्रशासकों, सिस्टम प्रशासकों और डेवलपर्स के लिए उपयोगी होगी जो पोस्टग्रेज समस्या निवारण में रुचि रखते हैं।

मेरा नाम एलेक्सी लेसोव्स्की है, मैं डेटा एग्रेट कंपनी का प्रतिनिधित्व करता हूं।

अपने बारे में कुछ शब्द. मैंने काफी समय पहले एक सिस्टम प्रशासक के रूप में शुरुआत की थी।

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

और अपने पूरे करियर में, मुझे हमेशा सांख्यिकी, निगरानी और टेलीमेट्री के विषयों में रुचि रही है। और जब मैं एक सिस्टम प्रशासक था, मैंने ज़ैबिक्स के साथ बहुत करीब से काम किया। और मैंने स्क्रिप्ट का एक छोटा सा सेट लिखा zabbix-एक्सटेंशन. वह अपने समय में काफी लोकप्रिय थे. और वहां न केवल लिनक्स, बल्कि विभिन्न घटकों, बहुत अलग महत्वपूर्ण चीजों की निगरानी करना संभव था।

अब मैं PostgreSQL पर काम कर रहा हूं। मैं पहले से ही एक और चीज़ लिख रहा हूँ जो आपको PostgreSQL आँकड़ों के साथ काम करने की अनुमति देती है। यह कहा जाता है पीजीसेंटर (हैब्रे पर लेख - प्रगति के बाद के आँकड़े बिना घबराहट और तनाव के).

एक छोटा सा परिचयात्मक नोट. हमारे ग्राहकों, हमारे ग्राहकों की क्या स्थितियाँ हैं? डेटाबेस से संबंधित किसी प्रकार की दुर्घटना हुई है। और जब डेटाबेस पहले ही बहाल हो चुका होता है, तो विभाग का प्रमुख या विकास प्रमुख आता है और कहता है: "दोस्तों, हमें डेटाबेस की निगरानी करने की ज़रूरत है, क्योंकि कुछ बुरा हुआ है और हमें भविष्य में ऐसा होने से रोकने की ज़रूरत है।" और यहां एक निगरानी प्रणाली चुनने या मौजूदा निगरानी प्रणाली को अनुकूलित करने की दिलचस्प प्रक्रिया शुरू होती है ताकि आप अपने डेटाबेस - PostgreSQL, MySQL या कुछ अन्य की निगरानी कर सकें। और सहकर्मी सुझाव देने लगते हैं: “मैंने सुना है कि ऐसा और ऐसा डेटाबेस है। आइए इसका उपयोग करें।" सहकर्मी एक-दूसरे से बहस करने लगते हैं। और अंत में यह पता चलता है कि हम किसी प्रकार का डेटाबेस चुनते हैं, लेकिन PostgreSQL मॉनिटरिंग इसमें खराब तरीके से प्रस्तुत की जाती है और हमें हमेशा कुछ न कुछ जोड़ना पड़ता है। GitHub से कुछ रिपॉजिटरी लें, उन्हें क्लोन करें, स्क्रिप्ट्स को अनुकूलित करें और किसी तरह उन्हें कस्टमाइज़ करें। और अंत में यह किसी प्रकार का मैनुअल काम बन कर रह जाता है।

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

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

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

सबसे पहले, आइए जानें कि निगरानी क्या है। मॉनिटरिंग करना बहुत जरूरी चीज है. ये बात हर कोई समझता है. लेकिन साथ ही, निगरानी किसी व्यावसायिक उत्पाद से संबंधित नहीं होती है और कंपनी के लाभ को सीधे प्रभावित नहीं करती है, इसलिए समय हमेशा अवशिष्ट आधार पर निगरानी के लिए आवंटित किया जाता है। अगर हमारे पास समय है, तो हम मॉनिटरिंग करते हैं; अगर हमारे पास समय नहीं है, तो ठीक है, हम इसे बैकलॉग में डाल देंगे और किसी दिन हम इन कार्यों पर लौट आएंगे।

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

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

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

ये आँकड़े कार्यों और विचारों के एक निश्चित समूह के रूप में प्रस्तुत किए जाते हैं। इन्हें टेबल भी कहा जा सकता है. यानी, एक नियमित psql क्लाइंट का उपयोग करके, आप डेटाबेस से जुड़ सकते हैं, इन फ़ंक्शंस और दृश्यों पर चयन कर सकते हैं, और PostgreSQL सबसिस्टम के संचालन के बारे में कुछ विशिष्ट संख्याएँ प्राप्त कर सकते हैं।

आप इन नंबरों को अपने पसंदीदा मॉनिटरिंग सिस्टम में जोड़ सकते हैं, ग्राफ़ बना सकते हैं, फ़ंक्शन जोड़ सकते हैं और लंबी अवधि में विश्लेषण प्राप्त कर सकते हैं।

लेकिन इस रिपोर्ट में मैं इन सभी कार्यों को पूरी तरह से कवर नहीं करूंगा, क्योंकि इसमें पूरा दिन लग सकता है। मैं वस्तुतः दो, तीन या चार चीजों को संबोधित करूंगा और आपको बताऊंगा कि वे निगरानी को बेहतर बनाने में कैसे मदद करते हैं।

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

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

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

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

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

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

सिस्टम मेट्रिक्स के साथ सब कुछ कमोबेश ठीक है, सभी आधुनिक मॉनिटरिंग सिस्टम पहले से ही इन मेट्रिक्स का समर्थन करते हैं, लेकिन सामान्य तौर पर, कुछ घटक अभी भी पर्याप्त नहीं हैं और कुछ चीजों को जोड़ने की आवश्यकता है। मैं उन पर भी बात करूंगा, उनके बारे में कई स्लाइडें होंगी।

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

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

एक प्रसिद्ध निगरानी प्रणाली का एक उदाहरण. यह बहुत बढ़िया मॉनिटरिंग सिस्टम है. वह बहुत सारा डेटा एकत्र करती है, लेकिन मेरे दृष्टिकोण से, उसके पास डैशबोर्ड की एक अजीब अवधारणा है। "एक डैशबोर्ड बनाएं" के लिए एक लिंक है। लेकिन जब आप एक डैशबोर्ड बनाते हैं, तो आप दो कॉलमों की एक सूची, ग्राफ़ की एक सूची बनाते हैं। और जब आपको कुछ देखने की आवश्यकता होती है, तो आप माउस से क्लिक करना, स्क्रॉल करना, वांछित चार्ट की तलाश करना शुरू कर देते हैं। और इसमें समय लगता है, यानी ऐसे कोई डैशबोर्ड नहीं हैं। केवल चार्ट की सूचियाँ हैं।

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

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

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

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

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

क्या हर कोई समझता है कि कई अनुरोध एक लेनदेन में फिट हो सकते हैं? इसलिए टीपीएस और क्यूपीएस थोड़े अलग हैं।

प्रति सेकंड अनुरोधों की संख्या pg_stat_statements से प्राप्त की जा सकती है और सभी पूर्ण अनुरोधों के योग की गणना की जा सकती है। यह स्पष्ट है कि हम वर्तमान मूल्य की तुलना पिछले मूल्य से करते हैं, इसे घटाते हैं, डेल्टा प्राप्त करते हैं, और मात्रा प्राप्त करते हैं।

यदि आप चाहें तो अतिरिक्त मेट्रिक्स जोड़ सकते हैं, जो हमारे डेटाबेस की उपलब्धता का मूल्यांकन करने और यह निगरानी करने में भी मदद करते हैं कि क्या कोई डाउनटाइम हुआ है।

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

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

आपको इसकी निगरानी करने की आवश्यकता क्यों है? क्योंकि वैक्यूम कभी-कभी बहुत दर्द देता है। इसमें बड़ी मात्रा में संसाधनों की खपत होती है और परिणामस्वरूप क्लाइंट के अनुरोध प्रभावित होने लगते हैं।

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

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

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

कनेक्टेड क्लाइंट्स के बारे में जानकारी महत्वपूर्ण है क्योंकि, PostgreSQL परिप्रेक्ष्य से, क्लाइंट अलग-अलग होते हैं। अच्छे ग्राहक हैं और बुरे ग्राहक भी हैं।

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

ऐसी स्थितियाँ होती हैं जब क्लाइंट कनेक्ट हो जाता है, वह कनेक्शन रखता है, लेकिन कुछ नहीं करता है। यह निष्क्रिय अवस्था में है.

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

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

निगरानी का एक और उदाहरण. और यहां पहले से ही एक अच्छा डैशबोर्ड मौजूद है। ऊपर कनेक्शन के बारे में जानकारी है. डीबी कनेक्शन - 8 टुकड़े। और यह सब है. हमें इस बारे में कोई जानकारी नहीं है कि कौन से ग्राहक सक्रिय हैं, कौन से ग्राहक निष्क्रिय हैं, कुछ नहीं कर रहे हैं। लंबित लेनदेन और लंबित कनेक्शन के बारे में कोई जानकारी नहीं है, यानी यह एक आंकड़ा है जो कनेक्शन की संख्या दिखाता है और बस इतना ही। और फिर आप खुद अंदाजा लगाइये.

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

अगर हमें लंबे लेन-देन दिखें तो हमें उन्हें पहले ही पूरा कर लेना चाहिए। ओएलटीपी लोड के लिए, लंबे लेनदेन पहले से ही 1-2-3 मिनट से अधिक हैं. OLAP कार्यभार के लिए, लंबे लेनदेन सामान्य हैं, लेकिन यदि उन्हें पूरा होने में दो घंटे से अधिक समय लगता है, तो यह भी एक संकेत है कि हमारे पास कहीं न कहीं गड़बड़ी है।

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

यह हमारे कार्यभार का मूल्यांकन करने और मोटे तौर पर यह समझने के लिए आवश्यक है कि कौन सी टेबल हमारे लिए "सबसे गर्म" हैं। उदाहरण के लिए, यह उन स्थितियों में आवश्यक है जहां हम किसी प्रकार के तेज़ एसएसडी स्टोरेज पर "हॉट" टेबल रखना चाहते हैं। उदाहरण के लिए, कुछ संग्रह तालिकाएँ जिन्हें हमने लंबे समय से उपयोग नहीं किया है, उन्हें किसी प्रकार के "ठंडे" संग्रह में, SATA ड्राइव में ले जाया जा सकता है और उन्हें वहां रहने दिया जा सकता है, उन्हें आवश्यकतानुसार एक्सेस किया जाएगा।

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

आप "फ़्लोटिंग" आँकड़ों में विसंगतियों का भी पता लगा सकते हैं। इसका मतलब क्या है? PostgreSQL में एक बहुत मजबूत और बहुत अच्छा क्वेरी प्लानर है। और डेवलपर्स इसके विकास के लिए बहुत समय समर्पित करते हैं। वह कैसे काम करता है? अच्छी योजनाएँ बनाने के लिए, PostgreSQL एक निश्चित समय अंतराल पर और एक निश्चित आवृत्ति के साथ तालिकाओं में डेटा के वितरण पर आंकड़े एकत्र करता है। ये सबसे सामान्य मान हैं: अद्वितीय मानों की संख्या, तालिका में NULL के बारे में जानकारी, बहुत सारी जानकारी।

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

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

और इसे हम मॉनिटरिंग में देख सकते हैं. और पहले से ही इस क्वेरी को देखें, इसके लिए एक व्याख्या चलाएँ, आँकड़े एकत्र करें, एक नया अतिरिक्त सूचकांक बनाएँ। और पहले से ही इस समस्या पर प्रतिक्रिया दें। इसलिए यह महत्वपूर्ण है.

निगरानी का एक और उदाहरण. मुझे लगता है कि बहुत से लोग उसे पहचानते हैं क्योंकि वह बहुत लोकप्रिय है। जो अपने प्रोजेक्ट्स में इसका इस्तेमाल करते हैं प्रोमिथेउस? प्रोमेथियस के साथ इस उत्पाद का उपयोग कौन करता है? तथ्य यह है कि इस निगरानी के मानक भंडार में PostgreSQL के साथ काम करने के लिए एक डैशबोर्ड है - पोस्टग्रेस_निर्यातक प्रोमेथियस। लेकिन एक ख़राब विवरण है.

कई ग्राफ़ हैं. और बाइट्स को एकता के रूप में दर्शाया गया है, यानी 5 ग्राफ़ हैं। ये हैं डेटा डालें, डेटा अपडेट करें, डेटा हटाएं, डेटा फ़ेच करें और डेटा लौटाएं। इकाई माप बाइट्स है. लेकिन बात यह है कि PostgreSQL में आँकड़े टुपल (पंक्तियों) में डेटा लौटाते हैं। और, तदनुसार, ये ग्राफ़ आपके कार्यभार को कई बार, दसियों बार कम आंकने का एक बहुत अच्छा तरीका है, क्योंकि एक टुपल एक बाइट नहीं है, एक टुपल एक स्ट्रिंग है, यह कई बाइट्स है और यह हमेशा परिवर्तनशील लंबाई का होता है। अर्थात्, टुपल्स का उपयोग करके बाइट्स में कार्यभार की गणना करना एक अवास्तविक कार्य या बहुत कठिन है। इसलिए, जब आप डैशबोर्ड या अंतर्निहित मॉनिटरिंग का उपयोग करते हैं, तो यह समझना हमेशा महत्वपूर्ण होता है कि यह सही ढंग से काम करता है और आपको सही ढंग से मूल्यांकन किया गया डेटा लौटाता है।

इन तालिकाओं पर आँकड़े कैसे प्राप्त करें? इस उद्देश्य के लिए, PostgreSQL के पास विचारों का एक निश्चित परिवार है। और मुख्य दृश्य है pg_stat_user_tables. User_tables - इसका मतलब उपयोगकर्ता की ओर से बनाई गई तालिकाएँ हैं। इसके विपरीत, ऐसे सिस्टम दृश्य हैं जिनका उपयोग PostgreSQL द्वारा ही किया जाता है। और एक सारांश तालिका ऑलटेबल्स है, जिसमें सिस्टम और उपयोगकर्ता दोनों शामिल हैं। आप उनमें से किसी से भी शुरुआत कर सकते हैं जो आपको सबसे अच्छा लगे।

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

इस डेटा के आधार पर, हम तथाकथित टॉपएन टेबल बना सकते हैं। उदाहरण के लिए, टॉप-5, टॉप-10। और आप उन हॉट टेबलों को ट्रैक कर सकते हैं जो दूसरों की तुलना में अधिक पुनर्नवीनीकरण की जाती हैं। उदाहरण के लिए, सम्मिलन के लिए 5 "हॉट" टेबल। और इन टॉपएन तालिकाओं का उपयोग करके हम अपने कार्यभार का मूल्यांकन करते हैं और किसी भी रिलीज़, अपडेट और तैनाती के बाद कार्यभार के विस्फोट का मूल्यांकन कर सकते हैं।

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

और अब आपके लिए एक छोटा सा सवाल. जब आप अपने डेटाबेस सर्वर पर लोड देखते हैं तो क्या प्रश्न उठता है? आपका अगला प्रश्न क्या है?

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

तदनुसार, आपको उन क्वेरीज़ को ढूंढना होगा जो सबसे अधिक लोड का कारण बनती हैं, क्योंकि क्वेरीज़ को ट्यून करना, एक नियम के रूप में, PostgreSQL या ऑपरेटिंग सिस्टम कॉन्फ़िगरेशन को ट्यून करने या यहां तक ​​कि हार्डवेयर को ट्यून करने से अधिक लाभ देता है। मेरे अनुमान के अनुसार यह लगभग 80-85-90% है। और यह काम बहुत तेजी से किया जाता है. कॉन्फ़िगरेशन को ठीक करने, पुनरारंभ शेड्यूल करने, विशेष रूप से यदि डेटाबेस को पुनरारंभ नहीं किया जा सकता है, या हार्डवेयर जोड़ने की तुलना में किसी अनुरोध को ठीक करना अधिक तेज़ है। इस क्वेरी से बेहतर परिणाम प्राप्त करने के लिए क्वेरी को कहीं फिर से लिखना या एक इंडेक्स जोड़ना आसान है।

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

और यह जानकारी प्राप्त करने के लिए हम pg_stat_statements मॉड्यूल का उपयोग कर सकते हैं। इसके आधार पर, आप विभिन्न प्रकार के ग्राफ़ बना सकते हैं। उदाहरण के लिए, आप सबसे अधिक बार आने वाली क्वेरी के बारे में जानकारी प्राप्त कर सकते हैं, यानी उन क्वेरी के बारे में जो सबसे अधिक बार निष्पादित होती हैं। हां, तैनाती के बाद इसे देखना और यह समझना भी बहुत उपयोगी है कि क्या अनुरोधों में कोई वृद्धि हुई है।

आप सबसे लंबी क्वेरीज़ की निगरानी कर सकते हैं, यानी वे क्वेरीज़ जिन्हें पूरा होने में सबसे अधिक समय लगता है। वे प्रोसेसर पर चलते हैं, वे I/O का उपभोग करते हैं। हम इसका मूल्यांकन कुल_समय, माध्य_समय, blk_write_time और blk_read_time फ़ील्ड का उपयोग करके भी कर सकते हैं।

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

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

और आप उन क्वेरीज़ की निगरानी भी कर सकते हैं जो अस्थायी फ़ाइलों या अस्थायी तालिकाओं का उपयोग करती हैं।

और हमारे पास अभी भी पृष्ठभूमि प्रक्रियाएं हैं। पृष्ठभूमि प्रक्रियाएं मुख्य रूप से चेकपॉइंट हैं या उन्हें चेकपॉइंट भी कहा जाता है, ये ऑटोवैक्यूम और प्रतिकृति हैं।

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

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

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

तदनुसार, निर्दिष्ट फ़ील्ड का उपयोग करके pg_stat_bgwriter के माध्यम से हम होने वाली चौकियों की संख्या की निगरानी कर सकते हैं। और यदि हमारे पास एक निश्चित अवधि में (10-15-20 मिनट में, आधे घंटे में) बहुत सारी चौकियाँ हैं, उदाहरण के लिए, 3-4-5, तो यह पहले से ही एक समस्या हो सकती है। और आपको पहले से ही डेटाबेस में देखने की जरूरत है, कॉन्फ़िगरेशन में देखें कि इतनी अधिक संख्या में चौकियों का कारण क्या है। हो सकता है कि वहां कोई बड़ी रिकॉर्डिंग चल रही हो. हम पहले से ही कार्यभार का मूल्यांकन कर सकते हैं, क्योंकि हमने पहले ही कार्यभार ग्राफ़ जोड़ दिए हैं। हम पहले से ही चेकपॉइंट मापदंडों में बदलाव कर सकते हैं और सुनिश्चित कर सकते हैं कि वे क्वेरी प्रदर्शन को बहुत अधिक प्रभावित न करें।

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

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

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

आजकल व्यावहारिक रूप से कोई PostgreSQL इंस्टॉलेशन नहीं है जिसमें स्ट्रीमिंग प्रतिकृति न हो। प्रतिकृति डेटा को मास्टर से प्रतिकृति में ले जाने की प्रक्रिया है।

PostgreSQL में प्रतिकृति लेनदेन लॉग के माध्यम से की जाती है। विज़ार्ड एक लेनदेन लॉग उत्पन्न करता है। लेन-देन लॉग नेटवर्क कनेक्शन के माध्यम से प्रतिकृति तक जाता है, और फिर इसे प्रतिकृति पर पुन: प्रस्तुत किया जाता है। यह आसान है।

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

लेकिन फिर भी, प्रतिकृति अंतराल का मूल्यांकन करने के लिए, आपको लेनदेन में लॉग की स्थिति जानने की आवश्यकता है। और ये लेन-देन लॉग स्थितियाँ बिल्कुल pg_stat_replication दृश्य में हैं। तुलनात्मक रूप से कहें तो, हम pg_xlog_location_diff() फ़ंक्शन का उपयोग करके लेनदेन लॉग में दो बिंदु ले सकते हैं। उनके बीच डेल्टा की गणना करें और बाइट्स में प्रतिकृति अंतराल प्राप्त करें। यह बहुत सुविधाजनक और सरल है.

संस्करण 10 में, इस फ़ंक्शन का नाम बदलकर pg_wal_lsn_diff() कर दिया गया। सामान्य तौर पर, सभी कार्यों, दृश्यों और उपयोगिताओं में जहां "xlog" शब्द दिखाई देता है, उसे "wal" मान से बदल दिया गया है। यह दृश्य और फ़ंक्शन दोनों पर लागू होता है। ये एक ऐसा इनोवेशन है.

साथ ही, संस्करण 10 में, पंक्तियाँ जोड़ी गईं जो विशेष रूप से अंतराल दिखाती हैं। ये हैं राइट लैग, फ्लश लैग, रीप्ले लैग। यानी इन चीजों पर नजर रखना जरूरी है. यदि हम देखते हैं कि हमारे पास प्रतिकृति अंतराल है, तो हमें जांच करने की आवश्यकता है कि यह क्यों दिखाई दिया, यह कहां से आया और समस्या को ठीक किया।

सिस्टम मेट्रिक्स के साथ लगभग सब कुछ क्रम में है। जब कोई निगरानी शुरू होती है, तो वह सिस्टम मेट्रिक्स से शुरू होती है। यह प्रोसेसर, मेमोरी, स्वैप, नेटवर्क और डिस्क का निपटान है। हालाँकि, कई पैरामीटर डिफ़ॉल्ट रूप से मौजूद नहीं हैं।

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

इसके अलावा, ये आँकड़े /proc फ़ाइल सिस्टम से भी प्राप्त किए जा सकते हैं, जैसा कि रीसाइक्लिंग प्रोसेसर के लिए किया जाता है। मुझे नहीं पता कि यह जानकारी निगरानी में क्यों नहीं जोड़ी जाती. लेकिन फिर भी आपकी निगरानी में इसका होना जरूरी है.

यही बात नेटवर्क इंटरफेस पर भी लागू होती है। पैकेटों में, बाइट्स में नेटवर्क थ्रूपुट के बारे में जानकारी है, लेकिन फिर भी विलंबता के बारे में कोई जानकारी नहीं है और उपयोग के बारे में कोई जानकारी नहीं है, हालांकि यह भी उपयोगी जानकारी है।

किसी भी निगरानी में कमियां होती हैं. और इससे कोई फर्क नहीं पड़ता कि आप किस प्रकार की निगरानी करते हैं, यह हमेशा कुछ मानदंडों को पूरा नहीं करेगा। लेकिन फिर भी, वे विकसित हो रहे हैं, नई सुविधाएँ और नई चीज़ें जोड़ी जा रही हैं, इसलिए कुछ चुनें और इसे समाप्त करें।

और समाप्त करने के लिए, आपको हमेशा यह पता होना चाहिए कि प्रदान किए गए आँकड़ों का क्या मतलब है और आप समस्याओं को हल करने के लिए उनका उपयोग कैसे कर सकते हैं।

और कुछ मुख्य बिंदु:

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

यदि आप इस विषय में रुचि रखते हैं, तो आप इन लिंक का अनुसरण कर सकते हैं।
http://bit.do/stats_collector - यह सांख्यिकी संग्रहकर्ता का आधिकारिक दस्तावेज़ है। इसमें सभी सांख्यिकीय दृष्टिकोणों का विवरण और सभी क्षेत्रों का विवरण है। आप इन्हें पढ़, समझ और विश्लेषण कर सकते हैं. और उनके आधार पर, अपने ग्राफ़ बनाएं और उन्हें अपनी निगरानी में जोड़ें।

उदाहरण अनुरोध:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

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

सवाल

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

प्रश्न: क्या AWR रिपोर्ट या... एकत्रीकरण का कोई एनालॉग है? क्या आप ऐसी किसी चीज़ के बारे में जानते हैं?
उत्तर: हाँ, मुझे पता है कि AWR क्या है, यह एक अच्छी चीज़ है। फिलहाल विभिन्न प्रकार की साइकिलें हैं जो लगभग निम्नलिखित मॉडल को लागू करती हैं। कुछ समय के अंतराल पर, कुछ बेसलाइन एक ही PostgreSQL या एक अलग स्टोरेज पर लिखी जाती हैं। आप उन्हें इंटरनेट पर गूगल कर सकते हैं, वे वहां मौजूद हैं। ऐसी चीज़ के डेवलपर्स में से एक PostgreSQL थ्रेड में sql.ru फोरम पर बैठा है। आप उसे वहां पकड़ सकते हैं. हाँ, ऐसी चीजें हैं, उनका उपयोग किया जा सकता है। प्लस इसके में पीजीसेंटर मैं एक ऐसी चीज़ भी लिख रहा हूँ जो आपको वही चीज़ करने की अनुमति देती है।

PS1 यदि आप postgres_exporter का उपयोग कर रहे हैं, तो आप किस डैशबोर्ड का उपयोग कर रहे हैं? उनमें से कई हैं. वे पहले ही पुराने हो चुके हैं. शायद समुदाय एक अद्यतन टेम्पलेट बनाएगा?

PS2 ने pganalyze को हटा दिया क्योंकि यह एक मालिकाना SaaS पेशकश है जो प्रदर्शन निगरानी और स्वचालित ट्यूनिंग सुझावों पर केंद्रित है।

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

आप किस स्व-होस्टेड पोस्टग्रेस्क्ल मॉनिटरिंग (डैशबोर्ड के साथ) को सबसे अच्छा मानते हैं?

• 30,0% तक ज़ैबिक्स + एलेक्सी लेसोव्स्की से अतिरिक्त या ज़ैबिक्स 4.4 या libzbxpgsql + ज़ैबिक्स libzbxpgsql + ज़ैबिक्स3

• 0,0% तक https://github.com/lesovsky/pgcenter0

• 0,0% तक https://github.com/pg-monz/pg_monz0

• 20,0% तक https://github.com/cybertec-postgresql/pgwatch22

• 20,0% तक https://github.com/postgrespro/mamonsu2

• 0,0% तक https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0% तक pganalyze एक मालिकाना SaaS है - मैं इसे हटा नहीं सकता1

• 10,0% तक https://github.com/powa-team/powa1

• 0,0% तक https://github.com/darold/pgbadger0

• 0,0% तक https://github.com/darold/pgcluu0

• 0,0% तक https://github.com/zalando/PGObserver0

• 10,0% तक https://github.com/spotify/postgresql-metrics1

10 उपयोगकर्ताओं ने मतदान किया। 26 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com