PostgreSQL कार्यप्रदर्शन सुधारण्याच्या पद्धतींपैकी एक म्हणून संश्लेषण

तात्विक परिचय

आपल्याला माहिती आहे की, समस्या सोडवण्यासाठी फक्त दोन पद्धती आहेत:

1. विश्लेषणाची पद्धत किंवा वजावटीची पद्धत किंवा सामान्य ते विशिष्ट.
2. संश्लेषणाची पद्धत किंवा प्रेरणाची पद्धत, किंवा विशिष्ट ते सामान्य.

"डेटाबेस कार्यप्रदर्शन सुधारण्यासाठी" समस्येचे निराकरण करण्यासाठी, ते यासारखे दिसू शकते.

अॅनालिझ — आम्ही समस्येचे स्वतंत्र भागांमध्ये विश्लेषण करतो आणि त्यांचे निराकरण करून, आम्ही संपूर्ण डेटाबेसचे कार्यप्रदर्शन सुधारण्याचा प्रयत्न करतो.

सराव मध्ये, विश्लेषण असे दिसते:

• एक समस्या उद्भवते (कार्यप्रदर्शन घटना)
• डेटाबेसच्या स्थितीबद्दल सांख्यिकीय माहिती गोळा करणे
• अडथळे शोधत आहे
• आम्ही अडथळ्यांमधून समस्या सोडवतो

डेटाबेस अडथळे — पायाभूत सुविधा (CPU, मेमरी, डिस्क, नेटवर्क, OS), सेटिंग्ज (postgresql.conf), क्वेरी:

पायाभूत सुविधा: अभियंत्यासाठी प्रभाव आणि बदलाच्या शक्यता जवळजवळ शून्य आहेत.

डेटाबेस सेटिंग्ज: बदलांची शक्यता मागील प्रकरणांपेक्षा किंचित जास्त आहे, परंतु नियम म्हणून ते अजूनही खूप कठीण आहेत, विशेषतः ढगांमध्ये.

चौकश्या डेटाबेसला: फक्त युक्तीसाठी जागा.

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

गीतात्मक परिचय किंवा हे सर्व का आवश्यक आहे

डेटाबेस कार्यप्रदर्शनाचे परीक्षण केले नसल्यास कार्यप्रदर्शन घटनांचे निराकरण करण्याची प्रक्रिया काय आहे:

ग्राहक - "आमच्यामध्ये सर्व काही वाईट आहे, यास खूप वेळ लागत आहे, आमच्यासाठी काहीतरी चांगले करा"
अभियंता - "किती वाईट आहे?"
ग्राहक - "आता असेच आहे (एक तासापूर्वी, काल, मागच्या वेळी होते), हळू"
अभियंता - "ते कधी चांगले होते?"
ग्राहक - “एक आठवडा (दोन आठवडे) पूर्वी ते वाईट नव्हते. "(हे भाग्यवान आहे)
ग्राहक - "ते कधी चांगले होते ते मला आठवत नाही, पण आता ते वाईट आहे" (सामान्य उत्तर)

परिणाम एक क्लासिक चित्र आहे:

दोष कोणाला द्यायचे आणि काय करावे?

प्रश्नाचा पहिला भाग उत्तर देणे सर्वात सोपा आहे - डीबीए अभियंता नेहमीच दोषी असतो.

दुसरा भाग उत्तर देणे देखील कठीण नाही - आपल्याला डेटाबेस कार्यप्रदर्शन मॉनिटरिंग सिस्टम लागू करणे आवश्यक आहे.

पहिला प्रश्न पडतो - काय निरीक्षण करावे?

पथ 1. आम्ही प्रत्येक गोष्टीचे निरीक्षण करू

CPU लोड, डिस्क रीड/राइट ऑपरेशन्सची संख्या, वाटप केलेल्या मेमरीचा आकार आणि भिन्न काउंटरचा आणखी एक मेगाटन जे कमी किंवा जास्त कार्यरत मॉनिटरिंग सिस्टम प्रदान करू शकते.

परिणाम म्हणजे आलेख, सारांश सारण्या आणि सतत ईमेल सूचना आणि 100% व्यस्त अभियंता समान तिकिटांचा एक समूह सोडवण्यात, तथापि, एक नियम म्हणून, मानक शब्दांसह - “तात्पुरती समस्या. कोणत्याही कारवाईची गरज नाही.” परंतु प्रत्येकजण व्यस्त आहे, आणि ग्राहकांना दाखवण्यासाठी नेहमीच काहीतरी असते - काम जोरात सुरू आहे.

मार्ग 2. जे आवश्यक आहे तेच निरीक्षण करा आणि ज्याची गरज नाही त्याचे निरीक्षण करणे आवश्यक नाही

तुम्ही थोड्या वेगळ्या पद्धतीने निरीक्षण करू शकता, फक्त संस्था आणि कार्यक्रम:

• कोणता DBA अभियंता प्रभावित करू शकतो
• ज्यासाठी एखादी घटना घडते किंवा एखादी संस्था बदलते तेव्हा क्रियांचा अल्गोरिदम असतो.

या गृहीतकावर आणि लक्षात ठेवण्यावर आधारित "तात्विक परिचय"नियमित पुनरावृत्ती टाळण्यासाठी"गीतात्मक परिचय किंवा हे सर्व का आवश्यक आहे“ऑप्टिमायझेशन आणि विश्लेषणासाठी वैयक्तिक प्रश्नांच्या कार्यप्रदर्शनाचे निरीक्षण करणे उचित ठरेल, ज्यामुळे शेवटी संपूर्ण डेटाबेसची कामगिरी सुधारली पाहिजे.

परंतु संपूर्ण डेटाबेस कार्यक्षमतेवर परिणाम करणारी भारी क्वेरी सुधारण्यासाठी, आपण प्रथम ती शोधणे आवश्यक आहे.

तर, दोन परस्परसंबंधित प्रश्न उद्भवतात:

• जी विनंती कठीण मानली जाते
• कठीण प्रश्न कसे शोधायचे.

अर्थात, एक भारी क्वेरी ही एक क्वेरी आहे जी परिणाम मिळविण्यासाठी भरपूर OS संसाधने वापरते.

चला दुसऱ्या प्रश्नाकडे वळू - शोध आणि नंतर जड प्रश्नांचे निरीक्षण कसे करावे?

PostgreSQL कडे कोणत्या क्वेरी मॉनिटरिंग क्षमता आहेत?

ओरॅकलच्या तुलनेत, काही शक्यता आहेत, परंतु तरीही काहीतरी केले जाऊ शकते.

पीजी_स्टॅट_स्टेटमेंट्स

PostgreSQL मध्‍ये जड क्‍वेरी शोधण्‍यासाठी आणि त्यांचे परीक्षण करण्‍यासाठी, मानक विस्तार pg_stat_statements हा उद्देश आहे.

विस्तार स्थापित केल्यानंतर, लक्ष्य डेटाबेसमध्ये समान नावाचे दृश्य दिसते, जे मॉनिटरिंग हेतूंसाठी वापरले जावे.

मॉनिटरिंग सिस्टम तयार करण्यासाठी लक्ष्य pg_stat_statements स्तंभ:

• queryid ऑपरेटरच्या पार्स ट्रीवरून गणना केलेला अंतर्गत हॅश कोड
• कमाल_वेळ विधानावर घालवलेला कमाल वेळ, मिलिसेकंदांमध्ये

या दोन स्तंभांवर आकडेवारी जमा करून आणि वापरून, आपण एक देखरेख प्रणाली तयार करू शकता.

PostgreSQL कामगिरीचे परीक्षण करण्यासाठी pg_stat_statements कसे वापरले जाते

क्वेरी कामगिरीचे परीक्षण करण्यासाठी वापरा:
लक्ष्य डेटाबेस बाजूला - pg_stat_statements दृश्य
बाजूला पासून सर्व्हर आणि मॉनिटरिंग डेटाबेस - बॅश स्क्रिप्ट्स आणि सर्व्हिस टेबल्सचा संच.

स्टेज 1 - सांख्यिकीय डेटाचे संकलन

क्रॉन मॉनिटरिंग होस्टवर, एक स्क्रिप्ट नियमितपणे लाँच केली जाते जी pg_stat_statements दृश्याची सामग्री लक्ष्य डेटाबेसमधून मॉनिटरिंग डेटाबेसमधील pg_stat_history टेबलवर कॉपी करते.

हे वैयक्तिक क्वेरी अंमलबजावणीचा इतिहास तयार करते ज्याचा वापर कार्यप्रदर्शन अहवाल व्युत्पन्न करण्यासाठी आणि मेट्रिक्स कॉन्फिगर करण्यासाठी केला जाऊ शकतो.

स्टेज 2 - कार्यप्रदर्शन मेट्रिक्स सेट करणे

गोळा केलेल्या डेटाच्या आधारे, आम्ही अशा क्वेरी निवडतो ज्यांची अंमलबजावणी क्लायंटसाठी (अनुप्रयोग) सर्वात गंभीर/महत्त्वाची आहे. ग्राहकाशी करार करून, आम्ही queryid आणि max_time फील्ड वापरून कार्यप्रदर्शन मेट्रिक्सची मूल्ये सेट करतो.

परिणाम - कामगिरी निरीक्षण सुरू

1. मॉनिटरिंग स्क्रिप्ट, चालवल्यावर, लक्ष्य डेटाबेसमधील pg_stat_statements दृश्यातील मूल्याशी मेट्रिकच्या max_time मूल्याची तुलना करून कॉन्फिगर केलेले कार्यप्रदर्शन मेट्रिक्स तपासते.
2. लक्ष्य डेटाबेसमधील मूल्य मेट्रिक मूल्यापेक्षा जास्त असल्यास, एक चेतावणी व्युत्पन्न केली जाते (तिकीट प्रणालीमधील एक घटना)

अतिरिक्त पर्याय १

क्वेरी योजना इतिहास

कार्यप्रदर्शन घटनांचे नंतर निराकरण करण्यात मदत करण्यासाठी, क्वेरी अंमलबजावणी योजना बदलण्याचा इतिहास असणे चांगली कल्पना आहे.

log_query सेवा सारणी इतिहास संचयित करण्यासाठी वापरली जाते. लोड केलेल्या PostgreSQL लॉग फाइलचे विश्लेषण करताना टेबल पॉप्युलेट केले जाते. लॉग फाइलमध्ये, pg_stat_statements दृश्याच्या विपरीत, अंमलबजावणी पॅरामीटर्सच्या मूल्यांसह संपूर्ण मजकूर असतो आणि सामान्यीकृत मजकूर नसल्यामुळे, केवळ विनंतीची वेळ आणि कालावधीच लॉग करणे शक्य नाही तर सध्याच्या अंमलबजावणीच्या योजना देखील संग्रहित करणे शक्य आहे. वेळ

अतिरिक्त पर्याय १

सतत कामगिरी सुधारण्याची प्रक्रिया

सर्वसाधारणपणे वैयक्तिक क्वेरींचे निरीक्षण करणे हे संपूर्णपणे डेटाबेसच्या कार्यप्रदर्शनात सतत सुधारणा करण्याच्या समस्येचे निराकरण करण्याचा हेतू नाही, कारण ते केवळ वैयक्तिक प्रश्नांसाठी कार्यप्रदर्शन समस्यांचे परीक्षण करते आणि निराकरण करते. तथापि, तुम्ही पद्धत वाढवू शकता आणि सर्व डेटाबेससाठी मॉनिटरिंग क्वेरी कॉन्फिगर करू शकता.

हे करण्यासाठी, आपण अतिरिक्त कार्यप्रदर्शन मेट्रिक्स प्रविष्ट करणे आवश्यक आहे:

• अलीकडच्या दिवसांत
• बेस कालावधीसाठी

स्क्रिप्ट लक्ष्य डेटाबेसमधील pg_stat_statements दृश्यातून क्वेरी निवडते आणि max_time मूल्याची सरासरी max_time मूल्याशी तुलना करते, पहिल्या प्रकरणात शेवटच्या दिवसांसाठी किंवा निवडलेल्या कालावधीसाठी (बेसलाइन), दुसऱ्या प्रकरणात.

अशा प्रकारे, कोणत्याही विनंतीसाठी कार्यप्रदर्शन कमी झाल्यास, अहवालांचे मॅन्युअल विश्लेषण न करता, एक चेतावणी स्वयंचलितपणे व्युत्पन्न केली जाईल.

संश्लेषणाचा त्याच्याशी काय संबंध आहे?

वर्णन केलेल्या पध्दतीमध्ये, संश्लेषण पद्धतीनुसार, प्रणालीचे वैयक्तिक भाग सुधारून, आम्ही संपूर्ण प्रणाली सुधारतो.

• डेटाबेसद्वारे निष्पादित केलेली क्वेरी - अमूर्त
• सुधारित विनंती - विरोधी
• प्रणालीची स्थिती बदलणे - संश्लेषण

प्रणाली विकास

• pg_stat_activity प्रणाली दृश्यासाठी इतिहास जोडून गोळा केलेल्या आकडेवारीचा विस्तार
• प्रश्नांमध्ये सहभागी होणाऱ्या वैयक्तिक सारण्यांच्या आकडेवारीसाठी इतिहास जोडून एकत्रित आकडेवारीचा विस्तार करणे
• AWS क्लाउड मॉनिटरिंग सिस्टमसह एकत्रीकरण
• आणि तरीही, आपण काहीतरी घेऊन येऊ शकता ...

स्त्रोत: www.habr.com