PostgreSQL मॉनिटरिंगची मूलभूत माहिती. अलेक्सी लेसोव्स्की

मी तुम्हाला डेटा एग्रेट "फंडामेंटल्स ऑफ पोस्टग्रेएसक्यूएल मॉनिटरिंग" मधील अलेक्सी लेसोव्स्कीच्या अहवालाचा उतारा वाचण्याची सूचना देतो.

या अहवालात, अॅलेक्सी लेसोव्स्की पोस्ट-ग्रेस आकडेवारीच्या मुख्य मुद्द्यांबद्दल बोलतील, त्यांचा अर्थ काय आहे आणि ते निरीक्षणात का उपस्थित असावेत; मॉनिटरिंगमध्ये कोणते आलेख असावेत, ते कसे जोडायचे आणि त्यांचा अर्थ कसा लावायचा. हा अहवाल डेटाबेस प्रशासक, सिस्टम प्रशासक आणि पोस्टग्रेस समस्यानिवारणात स्वारस्य असलेल्या विकासकांसाठी उपयुक्त ठरेल.

माझे नाव अॅलेक्सी लेसोव्स्की आहे, मी डेटा एग्रेट कंपनीचे प्रतिनिधित्व करतो.

माझ्याबद्दल काही शब्द. मी सिस्टम प्रशासक म्हणून खूप पूर्वी सुरुवात केली होती.

मी सर्व प्रकारच्या लिनक्स सिस्टमचे व्यवस्थापन केले, लिनक्सशी संबंधित विविध गोष्टींवर काम केले, उदा. व्हर्च्युअलायझेशन, मॉनिटरिंग, प्रॉक्सीसह काम केले, इ. पण कधीतरी मी डेटाबेस, PostgreSQL सह अधिक काम करण्यास सुरुवात केली. मला तो खरोखर आवडला. आणि काही क्षणी मी माझ्या कामाचा बहुतेक वेळ PostgreSQL वर काम करू लागलो. आणि म्हणून हळूहळू मी PostgreSQL DBA झालो.

आणि माझ्या संपूर्ण कारकिर्दीत, मला सांख्यिकी, निरीक्षण आणि टेलिमेट्री या विषयांमध्ये नेहमीच रस आहे. आणि जेव्हा मी सिस्टम प्रशासक होतो, तेव्हा मी Zabbix सह खूप जवळून काम केले. आणि मी स्क्रिप्टचा एक छोटा संच लिहिला zabbix-विस्तार. त्यांच्या काळात ते खूप लोकप्रिय होते. आणि तेथे केवळ लिनक्सच नव्हे तर विविध घटकांवरही अतिशय भिन्न महत्त्वाच्या गोष्टींचे निरीक्षण करणे शक्य झाले.

आता मी PostgreSQL वर काम करत आहे. मी आधीच दुसरी गोष्ट लिहित आहे जी तुम्हाला PostgreSQL आकडेवारीसह कार्य करण्यास अनुमती देते. असे म्हणतात pgCenter (हॅब्रेवरील लेख - नसा आणि तणावाशिवाय पोस्ट-ग्रेसची आकडेवारी).

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

म्हणूनच, या चर्चेत मी तुम्हाला केवळ PostgreSQL साठीच नव्हे तर डेटाबेससाठी देखील मॉनिटरिंग कसे निवडायचे याबद्दल काही ज्ञान देण्याचा प्रयत्न करेन. आणि तुम्हाला ते ज्ञान द्या जे तुम्हाला तुमचे निरीक्षण पूर्ण करण्यास अनुमती देईल जेणेकरून त्याचा काही फायदा होईल, ज्यामुळे तुम्ही तुमच्या डेटाबेसचे फायद्यासह निरीक्षण करू शकता, ज्यामुळे उद्भवू शकणार्‍या कोणत्याही आपत्कालीन परिस्थितीला तत्परतेने प्रतिबंध करता येईल.

आणि या अहवालात असलेल्या कल्पना थेट कोणत्याही डेटाबेसमध्ये रुपांतरित केल्या जाऊ शकतात, मग ते DBMS किंवा noSQL असो. म्हणून, पोस्टग्रेएसक्यूएलच नाही तर पोस्टग्रेएसक्यूएलमध्ये हे कसे करायचे याच्या अनेक पाककृती असतील. पोस्टग्रेएसक्यूएलकडे निरीक्षणासाठी असलेल्या प्रश्नांची उदाहरणे, संस्थांची उदाहरणे असतील. आणि जर तुमच्या डीबीएमएसमध्ये समान गोष्टी असतील ज्या तुम्हाला मॉनिटरिंगमध्ये ठेवण्याची परवानगी देतात, तर तुम्ही त्यांना जुळवून घेऊ शकता, त्यांना जोडू शकता आणि ते चांगले होईल.

मी अहवालात येणार नाही
मेट्रिक्स कसे वितरित आणि संग्रहित करायचे याबद्दल बोला. मी डेटावर पोस्ट-प्रोसेसिंग आणि वापरकर्त्याला सादर करण्याबद्दल काहीही बोलणार नाही. आणि मी अलर्टबद्दल काहीही बोलणार नाही.
पण जसजशी कथा पुढे जाईल तसतसे मी विद्यमान मॉनिटरिंगचे वेगवेगळे स्क्रीनशॉट्स दाखवेन आणि त्यावर टीका करेन. परंतु असे असले तरी, मी या उत्पादनांसाठी जाहिराती किंवा विरोधी जाहिराती तयार करू नयेत म्हणून ब्रँडचे नाव न देण्याचा प्रयत्न करेन. म्हणून, सर्व योगायोग यादृच्छिक आहेत आणि आपल्या कल्पनेवर सोडले आहेत.

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

म्हणून, आमच्या सरावातून, जेव्हा आम्ही क्लायंटकडे येतो, तेव्हा मॉनिटरिंग अनेकदा अपूर्ण असते आणि त्यात आम्हाला डेटाबेससह चांगले काम करण्यास मदत करणाऱ्या कोणत्याही मनोरंजक गोष्टी नसतात. आणि म्हणून निरीक्षण नेहमी पूर्ण करणे आवश्यक आहे.

डेटाबेस अशा गुंतागुंतीच्या गोष्टी आहेत ज्यांचे परीक्षण करणे देखील आवश्यक आहे, कारण डेटाबेस हे माहितीचे भांडार आहेत. आणि कंपनीसाठी माहिती खूप महत्वाची आहे; ती कोणत्याही प्रकारे गमावली जाऊ शकत नाही. परंतु त्याच वेळी, डेटाबेस हे सॉफ्टवेअरचे अतिशय जटिल भाग आहेत. त्यामध्ये मोठ्या संख्येने घटक असतात. आणि यापैकी अनेक घटकांचे निरीक्षण करणे आवश्यक आहे.

जर आपण विशेषतः PostgreSQL बद्दल बोलत आहोत, तर ते मोठ्या संख्येने घटक असलेल्या योजनेच्या रूपात प्रस्तुत केले जाऊ शकते. हे घटक एकमेकांशी संवाद साधतात. आणि त्याच वेळी, PostgreSQL मध्ये तथाकथित स्टॅट्स कलेक्टर उपप्रणाली आहे, जी तुम्हाला या उपप्रणालीच्या ऑपरेशनबद्दल आकडेवारी गोळा करण्यास आणि प्रशासक किंवा वापरकर्त्याला काही प्रकारचे इंटरफेस प्रदान करण्यास अनुमती देते जेणेकरून तो ही आकडेवारी पाहू शकेल.

ही आकडेवारी फंक्शन्स आणि दृश्यांच्या विशिष्ट संचाच्या स्वरूपात सादर केली जाते. त्यांना टेबल देखील म्हटले जाऊ शकते. म्हणजेच, नियमित psql क्लायंटचा वापर करून, तुम्ही डेटाबेसशी कनेक्ट करू शकता, या फंक्शन्स आणि दृश्यांवर निवड करू शकता आणि PostgreSQL उपप्रणालीच्या ऑपरेशनबद्दल काही विशिष्ट क्रमांक मिळवू शकता.

तुम्ही हे आकडे तुमच्या आवडत्या मॉनिटरिंग सिस्टममध्ये जोडू शकता, आलेख काढू शकता, फंक्शन्स जोडू शकता आणि दीर्घकालीन विश्लेषण मिळवू शकता.

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

आणि जर आपण डेटाबेस मॉनिटरिंगबद्दल बोललो, तर कशावर लक्ष ठेवण्याची गरज आहे? सर्वप्रथम, आम्हाला उपलब्धतेचे निरीक्षण करणे आवश्यक आहे, कारण डेटाबेस ही एक सेवा आहे जी क्लायंटला डेटामध्ये प्रवेश प्रदान करते आणि आम्हाला उपलब्धतेचे निरीक्षण करणे आवश्यक आहे, आणि त्याची काही गुणात्मक आणि परिमाणात्मक वैशिष्ट्ये देखील प्रदान करणे आवश्यक आहे.

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

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

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

आणि आम्ही डेटाबेसबद्दल बोलत असल्याने, डेटाबेस नेहमीच पार्श्वभूमी प्रक्रिया असते. पार्श्वभूमी प्रक्रिया डेटाबेस कार्यप्रदर्शन चांगल्या स्तरावर राखण्यात मदत करतात, म्हणून त्यांना ऑपरेट करण्यासाठी विशिष्ट प्रमाणात संसाधनांची आवश्यकता असते. आणि त्याच वेळी, ते क्लायंट विनंती संसाधनांसह ओव्हरलॅप करू शकतात, म्हणून लोभी पार्श्वभूमी प्रक्रिया थेट क्लायंट विनंत्यांच्या कार्यक्षमतेवर परिणाम करू शकतात. म्हणून, पार्श्वभूमी प्रक्रियेच्या बाबतीत कोणतेही विकृतीकरण होऊ नये म्हणून त्यांचे परीक्षण आणि मागोवा घेणे देखील आवश्यक आहे.

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

सिस्टम मेट्रिक्ससह सर्व काही कमी-अधिक चांगले आहे, सर्व आधुनिक मॉनिटरिंग सिस्टम आधीपासूनच या मेट्रिक्सचे समर्थन करतात, परंतु सर्वसाधारणपणे, काही घटक अद्याप पुरेसे नाहीत आणि काही गोष्टी जोडणे आवश्यक आहे. मी त्यांना देखील स्पर्श करेन, त्यांच्याबद्दल अनेक स्लाइड्स असतील.

योजनेचा पहिला मुद्दा म्हणजे प्रवेशयोग्यता. प्रवेशयोग्यता म्हणजे काय? माझ्या समजुतीनुसार उपलब्धता ही सेवा कनेक्शनसाठी बेसची क्षमता आहे, म्हणजे बेस वाढवला जातो, तो, सेवा म्हणून, ग्राहकांकडून कनेक्शन स्वीकारतो. आणि या प्रवेशयोग्यतेचे मूल्यांकन विशिष्ट वैशिष्ट्यांद्वारे केले जाऊ शकते. डॅशबोर्डवर ही वैशिष्ट्ये प्रदर्शित करणे खूप सोयीचे आहे.

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

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

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

त्यानुसार, आम्ही या वस्तुस्थितीपासून सुरुवात करू शकतो की आम्ही सर्व विनंत्यांची एकूण अंमलबजावणी वेळ घेऊ शकतो आणि वरील फील्ड्स वापरून विनंत्यांच्या संख्येने विभाजित करू शकतो. परंतु हे रुग्णालयातील सरासरी तापमान आहे. आम्ही इतर फील्डमधून सुरुवात करू शकतो - किमान क्वेरी अंमलबजावणी वेळ, कमाल आणि मध्य. आणि आम्ही पर्सेंटाइल देखील तयार करू शकतो; PostgreSQL कडे यासाठी संबंधित कार्ये आहेत. आणि आम्ही काही संख्या मिळवू शकतो जे आधीच पूर्ण झालेल्या विनंत्यांसाठी आमच्या डेटाबेसचा प्रतिसाद वेळ दर्शवतात, म्हणजे आम्ही बनावट विनंती 'सिलेक्ट 1' कार्यान्वित करत नाही आणि प्रतिसाद वेळ पाहतो, परंतु आम्ही आधीच पूर्ण झालेल्या विनंत्यांसाठी प्रतिसाद वेळेचे विश्लेषण करतो आणि काढतो. एकतर वेगळी आकृती किंवा आम्ही त्यावर आधारित आलेख तयार करतो.

सध्या सिस्टमद्वारे व्युत्पन्न होणाऱ्या त्रुटींच्या संख्येवर लक्ष ठेवणे देखील महत्त्वाचे आहे. आणि यासाठी तुम्ही pg_stat_database view वापरू शकता. आम्ही xact_rollback फील्डवर लक्ष केंद्रित करतो. हे फील्ड डेटाबेसमध्ये येणार्‍या रोलबॅकची संख्याच दर्शवत नाही तर त्रुटींची संख्या देखील विचारात घेते. तुलनेने बोलायचे झाल्यास, आम्ही आमच्या डॅशबोर्डमध्ये ही आकृती प्रदर्शित करू शकतो आणि आमच्याकडे सध्या किती त्रुटी आहेत ते पाहू शकतो. जर बर्याच त्रुटी असतील, तर लॉगमध्ये पाहण्याचे आणि त्या कोणत्या प्रकारच्या त्रुटी आहेत आणि त्या का उद्भवतात हे पाहण्याचे हे एक चांगले कारण आहे आणि नंतर गुंतवणूक करा आणि त्यांचे निराकरण करा.

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

व्यवहारांच्या संख्येचा अंदाज घेण्यासाठी, आम्ही पुन्हा pg_stat_database दृश्याचा संदर्भ घेऊ शकतो. आम्ही कमिटची संख्या आणि रोलबॅकची संख्या जोडू शकतो आणि प्रति सेकंद व्यवहारांची संख्या मिळवू शकतो.

एका व्यवहारात अनेक विनंत्या बसू शकतात हे प्रत्येकाला समजते का? त्यामुळे TPS आणि QPS थोडे वेगळे आहेत.

प्रति सेकंद विनंत्यांची संख्या pg_stat_statements वरून मिळवता येते आणि सर्व पूर्ण केलेल्या विनंत्यांची बेरीज मोजा. हे स्पष्ट आहे की आपण वर्तमान मूल्याची मागील मूल्याशी तुलना करतो, ते वजा करतो, डेल्टा मिळवतो आणि प्रमाण मिळवतो.

आपण इच्छित असल्यास अतिरिक्त मेट्रिक्स जोडू शकता, जे आमच्या डेटाबेसच्या उपलब्धतेचे मूल्यमापन करण्यात आणि कोणताही डाउनटाइम झाला आहे की नाही यावर लक्ष ठेवण्यास देखील मदत करते.

या मेट्रिक्सपैकी एक म्हणजे अपटाइम. पण PostgreSQL मध्ये अपटाइम थोडा अवघड आहे. मी तुम्हाला का सांगेन. PostgreSQL सुरू झाल्यावर, अपटाइम रिपोर्टिंग सुरू होतो. परंतु जर एखाद्या वेळी, उदाहरणार्थ, रात्री काही कार्य चालू असेल, तर एक OOM-किलर आला आणि जबरदस्तीने PostgreSQL चाइल्ड प्रक्रिया संपुष्टात आणली, तर या प्रकरणात PostgreSQL सर्व क्लायंटचे कनेक्शन संपुष्टात आणते, शार्डेड मेमरी क्षेत्र रीसेट करते आणि रिकव्हरी सुरू करते. शेवटची चौकी. आणि चेकपॉईंटवरून ही पुनर्प्राप्ती टिकत असताना, डेटाबेस कनेक्शन स्वीकारत नाही, म्हणजेच या परिस्थितीचे डाउनटाइम म्हणून मूल्यांकन केले जाऊ शकते. परंतु अपटाइम काउंटर रीसेट केले जाणार नाही, कारण ते पहिल्या क्षणापासून पोस्टमास्टर स्टार्टअप वेळ लक्षात घेते. म्हणून, अशा परिस्थिती वगळल्या जाऊ शकतात.

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

आपल्याला त्याचे निरीक्षण करण्याची आवश्यकता का आहे? कारण व्हॅक्यूम कधी कधी खूप त्रास देतो. हे मोठ्या प्रमाणात संसाधने वापरते आणि परिणामी क्लायंटच्या विनंत्यांचा त्रास होऊ लागतो.

आणि pg_stat_activity दृश्याद्वारे त्याचे परीक्षण केले पाहिजे, ज्याबद्दल मी पुढील भागात बोलेन. हे दृश्य डेटाबेसमधील वर्तमान क्रियाकलाप दर्शविते. आणि या उपक्रमाद्वारे आम्ही सध्या कार्यरत असलेल्या व्हॅक्यूम्सची संख्या ट्रॅक करू शकतो. आम्ही व्हॅक्यूमचा मागोवा घेऊ शकतो आणि पाहू शकतो की जर आम्ही मर्यादा ओलांडली असेल, तर हे पोस्टग्रेएसक्यूएल सेटिंग्जमध्ये पाहण्याचे आणि व्हॅक्यूमचे ऑपरेशन कसेतरी अनुकूल करण्याचे एक कारण आहे.

PostgreSQL बद्दल आणखी एक गोष्ट अशी आहे की PostgreSQL लांब व्यवहारांसाठी खूप आजारी आहे. विशेषत: अशा व्यवहारांपासून जे बर्याच काळासाठी लटकत असतात आणि काहीही करत नाहीत. हे तथाकथित स्टेट आयडल-इन-ट्रान्झॅक्शन आहे. अशा व्यवहारात कुलूप असतात आणि व्हॅक्यूमला काम करण्यापासून प्रतिबंधित करते. आणि परिणामी, टेबल फुगतात आणि आकारात वाढतात. आणि या सारण्यांसह कार्य करणार्या क्वेरी हळूहळू कार्य करण्यास सुरवात करतात, कारण तुम्हाला मेमरीपासून डिस्क आणि बॅकपर्यंतच्या पंक्तीच्या सर्व जुन्या आवृत्त्या फावडे करणे आवश्यक आहे. त्यामुळे, वेळ, प्रदीर्घ व्यवहारांचा कालावधी, सर्वात लांब व्हॅक्यूम विनंत्या यांचेही निरीक्षण करणे आवश्यक आहे. आणि जर आपल्याला OLTP लोडसाठी 10-20-30 मिनिटांपेक्षा जास्त काळापासून चालू असलेल्या काही प्रक्रिया दिसल्या, तर आपण त्यांच्याकडे लक्ष देणे आवश्यक आहे आणि त्यांना जबरदस्तीने समाप्त करणे आवश्यक आहे किंवा अनुप्रयोग ऑप्टिमाइझ करणे आवश्यक आहे जेणेकरून ते म्हटले जात नाही आणि इतके लांब लटकत नाही. विश्लेषणात्मक वर्कलोडसाठी, 10-20-30 मिनिटे सामान्य असतात; त्यापेक्षा जास्त लांब असतात.

पुढे आमच्याकडे कनेक्टेड क्लायंटसह पर्याय आहे. आम्ही आधीच डॅशबोर्ड तयार केल्यावर आणि त्यावर मुख्य उपलब्धता मेट्रिक्स पोस्ट केल्यावर, आम्ही तेथे कनेक्ट केलेल्या क्लायंटबद्दल अतिरिक्त माहिती देखील जोडू शकतो.

कनेक्टेड क्लायंटबद्दल माहिती महत्वाची आहे कारण, PostgreSQL दृष्टीकोनातून, क्लायंट वेगळे आहेत. चांगले ग्राहक आहेत आणि वाईट ग्राहक आहेत.

एक साधे उदाहरण. क्लायंटद्वारे मला अर्ज समजतो. अॅप्लिकेशन डेटाबेसशी कनेक्ट झाले आहे आणि लगेच तिथे त्याच्या विनंत्या पाठवायला सुरुवात करतो, डेटाबेस प्रक्रिया करतो आणि त्याची अंमलबजावणी करतो आणि क्लायंटला निकाल परत करतो. हे चांगले आणि योग्य ग्राहक आहेत.

अशी परिस्थिती असते जेव्हा क्लायंट कनेक्ट केलेला असतो, तो कनेक्शन ठेवतो, परंतु काहीही करत नाही. ते निष्क्रिय अवस्थेत आहे.

पण वाईट ग्राहक आहेत. उदाहरणार्थ, त्याच क्लायंटने कनेक्ट केले, व्यवहार उघडला, डेटाबेसमध्ये काहीतरी केले आणि नंतर कोडमध्ये गेला, उदाहरणार्थ, बाह्य स्त्रोतामध्ये प्रवेश करण्यासाठी किंवा तेथे प्राप्त झालेल्या डेटावर प्रक्रिया करण्यासाठी. मात्र त्याने व्यवहार बंद केला नाही. आणि व्यवहार डेटाबेसमध्ये हँग होतो आणि लाइनवरील लॉकमध्ये ठेवला जातो. ही वाईट स्थिती आहे. आणि जर अचानक कुठेतरी एखादा अनुप्रयोग अपवादाने अयशस्वी झाला, तर व्यवहार बराच काळ खुला राहू शकतो. आणि याचा थेट परिणाम PostgreSQL कामगिरीवर होतो. PostgreSQL हळू होईल. म्हणून, अशा क्लायंटचा वेळेवर मागोवा घेणे आणि त्यांचे काम सक्तीने समाप्त करणे महत्वाचे आहे. आणि आपल्याला आपला अनुप्रयोग ऑप्टिमाइझ करणे आवश्यक आहे जेणेकरून अशा परिस्थिती उद्भवणार नाहीत.

इतर वाईट क्लायंट वाट पाहणारे क्लायंट आहेत. पण परिस्थितीमुळे ते वाईट होतात. उदाहरणार्थ, एक साधा निष्क्रिय व्यवहार: तो व्यवहार उघडू शकतो, काही ओळींवर लॉक घेऊ शकतो, नंतर कोडमध्ये कुठेतरी तो अयशस्वी होईल आणि हँगिंग व्यवहार सोडून जाईल. दुसरा क्लायंट येईल आणि त्याच डेटाची विनंती करेल, परंतु त्याला एक लॉक येईल, कारण त्या हँगिंग ट्रान्झॅक्शनमध्ये काही आवश्यक पंक्तींवर आधीच लॉक आहेत. आणि दुसरा व्यवहार पहिला व्यवहार पूर्ण होण्याची प्रतीक्षा करत असेल किंवा प्रशासकाकडून जबरदस्तीने बंद करेल. त्यामुळे, प्रलंबित व्यवहार जमा होऊ शकतात आणि डेटाबेस कनेक्शन मर्यादा भरू शकतात. आणि जेव्हा मर्यादा पूर्ण होते, तेव्हा अनुप्रयोग यापुढे डेटाबेससह कार्य करू शकत नाही. प्रकल्पासाठी ही आधीच आणीबाणीची परिस्थिती आहे. म्हणून, खराब क्लायंटचा मागोवा घेणे आणि त्यांना वेळेवर प्रतिसाद देणे आवश्यक आहे.

देखरेखीचे आणखी एक उदाहरण. आणि येथे आधीपासूनच एक सभ्य डॅशबोर्ड आहे. वर कनेक्शन्सची माहिती आहे. डीबी कनेक्शन - 8 तुकडे. आणि हे सर्व आहे. कोणते क्लायंट सक्रिय आहेत, कोणते क्लायंट फक्त निष्क्रिय आहेत, काहीही करत नाहीत याबद्दल आमच्याकडे कोणतीही माहिती नाही. प्रलंबित व्यवहार आणि प्रलंबित कनेक्शनबद्दल कोणतीही माहिती नाही, म्हणजे ही एक आकृती आहे जी कनेक्शनची संख्या दर्शवते आणि तेच आहे. आणि मग स्वत: साठी अंदाज लावा.

त्यानुसार, ही माहिती मॉनिटरिंगमध्ये जोडण्यासाठी, तुम्हाला pg_stat_activity सिस्टम व्ह्यूमध्ये प्रवेश करणे आवश्यक आहे. जर तुम्ही PostgreSQL मध्ये बराच वेळ घालवत असाल, तर हे एक अतिशय चांगले दृश्य आहे जे तुमचे मित्र बनले पाहिजे, कारण ते PostgreSQL मधील वर्तमान क्रियाकलाप दर्शवते, म्हणजे त्यात काय चालले आहे. प्रत्येक प्रक्रियेसाठी एक स्वतंत्र ओळ आहे जी या प्रक्रियेबद्दल माहिती दर्शवते: कोणत्या होस्टकडून कनेक्शन केले गेले, कोणत्या वापरकर्त्याने, कोणत्या नावाने, व्यवहार कधी सुरू झाला, सध्या कोणती विनंती चालू आहे, कोणती विनंती शेवटची अंमलात आणली गेली. आणि, त्यानुसार, आम्ही स्टेट फील्ड वापरून क्लायंटच्या स्थितीचे मूल्यांकन करू शकतो. तुलनेने बोलायचे झाल्यास, आम्ही या फील्डनुसार गटबद्ध करू शकतो आणि सध्या डेटाबेसमध्ये असलेली आकडेवारी आणि डेटाबेसमध्ये ही स्थिती असलेल्या कनेक्शनची संख्या मिळवू शकतो. आणि आम्ही आधीच प्राप्त झालेले नंबर आमच्या मॉनिटरिंगला पाठवू शकतो आणि त्यावर आधारित आलेख काढू शकतो.
व्यवहाराच्या कालावधीचे मूल्यांकन करणे देखील महत्त्वाचे आहे. मी आधीच सांगितले आहे की व्हॅक्यूमच्या कालावधीचे मूल्यांकन करणे महत्वाचे आहे, परंतु व्यवहारांचे मूल्यांकन त्याच प्रकारे केले जाते. xact_start आणि query_start फील्ड आहेत. ते, तुलनेने बोलत, व्यवहाराची प्रारंभ वेळ आणि विनंतीची प्रारंभ वेळ दर्शवतात. आम्ही now() फंक्शन घेतो, जे वर्तमान टाइमस्टॅम्प दाखवते आणि व्यवहार वजा करतो आणि टाइमस्टॅम्पची विनंती करतो. आणि आम्हाला व्यवहाराचा कालावधी, विनंतीचा कालावधी मिळतो.

जर आपल्याला लांबचे व्यवहार दिसले तर आपण ते आधीच पूर्ण केले पाहिजेत. OLTP लोडसाठी, लांब व्यवहार आधीच 1-2-3 मिनिटांपेक्षा जास्त आहेत. OLAP वर्कलोडसाठी, लांबचे व्यवहार सामान्य असतात, परंतु ते पूर्ण होण्यासाठी दोन तासांपेक्षा जास्त वेळ लागल्यास, हे देखील एक चिन्ह आहे की आपल्याकडे कुठेतरी तिरकस आहे.

एकदा क्लायंट डेटाबेसशी कनेक्ट झाल्यानंतर, ते आमच्या डेटासह कार्य करण्यास सुरवात करतात. ते टेबल्समध्ये प्रवेश करतात, ते टेबलमधून डेटा मिळविण्यासाठी निर्देशांकांमध्ये प्रवेश करतात. आणि क्लायंट या डेटाशी कसा संवाद साधतात याचे मूल्यांकन करणे महत्त्वाचे आहे.

आमच्या वर्कलोडचे मूल्यांकन करण्यासाठी आणि आमच्यासाठी कोणते टेबल "सर्वात जास्त" आहेत हे अंदाजे समजून घेण्यासाठी हे आवश्यक आहे. उदाहरणार्थ, आम्हाला काही प्रकारच्या वेगवान SSD स्टोरेजवर "हॉट" टेबल ठेवायचे आहेत अशा परिस्थितीत हे आवश्यक आहे. उदाहरणार्थ, काही संग्रहण सारण्या ज्या आम्ही बर्याच काळापासून वापरल्या नाहीत त्या काही प्रकारच्या "कोल्ड" संग्रहणात, SATA ड्राइव्हवर हलवल्या जाऊ शकतात आणि त्यांना तेथे राहू द्या, त्यांना आवश्यकतेनुसार प्रवेश केला जाईल.

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

तुम्ही "फ्लोटिंग" आकडेवारीमध्ये विसंगती देखील शोधू शकता. याचा अर्थ काय? PostgreSQL मध्ये एक अतिशय मजबूत आणि अतिशय चांगला क्वेरी शेड्युलर आहे. आणि विकासक त्याच्या विकासासाठी बराच वेळ घालवतात. तो कसा काम करतो? चांगल्या योजना बनवण्यासाठी, PostgreSQL ठराविक वेळेच्या अंतराने आणि ठराविक वारंवारतेने टेबलमधील डेटाच्या वितरणाची आकडेवारी गोळा करते. ही सर्वात सामान्य मूल्ये आहेत: अद्वितीय मूल्यांची संख्या, टेबलमधील NULL बद्दल माहिती, बरीच माहिती.

या आकडेवारीच्या आधारे, नियोजक अनेक क्वेरी तयार करतो, सर्वात इष्टतम एक निवडतो आणि क्वेरी स्वतः कार्यान्वित करण्यासाठी आणि डेटा परत करण्यासाठी ही क्वेरी योजना वापरतो.

आणि असे घडते की आकडेवारी "फ्लोट" होते. टेबलमध्ये गुणवत्ता आणि प्रमाण डेटा कसा तरी बदलला, परंतु आकडेवारी गोळा केली गेली नाही. आणि तयार केलेल्या योजना इष्टतम नसतील. आणि जर आमच्या योजना संकलित केलेल्या देखरेखीच्या आधारे सर्वोत्कृष्ट ठरल्या तर, आम्ही या विसंगती पाहण्यास सक्षम होऊ. उदाहरणार्थ, कुठेतरी डेटा गुणात्मकपणे बदलला आणि निर्देशांकाच्या ऐवजी, टेबलमधून एक अनुक्रमिक पास वापरला जाऊ लागला, म्हणजे. जर एखाद्या क्वेरीला फक्त 100 पंक्ती परत कराव्या लागतील (100 ची मर्यादा आहे), तर या क्वेरीसाठी संपूर्ण शोध केला जाईल. आणि याचा नेहमी कामगिरीवर खूप वाईट परिणाम होतो.

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

देखरेखीचे आणखी एक उदाहरण. मला वाटते की अनेकांनी त्याला ओळखले कारण तो खूप लोकप्रिय आहे. कोण ते त्यांच्या प्रकल्पात वापरतो Prometheus? प्रोमिथियसच्या संयोगाने हे उत्पादन कोण वापरते? वस्तुस्थिती अशी आहे की या मॉनिटरिंगच्या मानक भांडारात PostgreSQL सह काम करण्यासाठी डॅशबोर्ड आहे - postgres_exporter प्रोमिथियस. पण एक वाईट तपशील आहे.

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

या तक्त्यांवर आकडेवारी कशी मिळवायची? या उद्देशासाठी, PostgreSQL कडे दृश्यांचे एक विशिष्ट कुटुंब आहे. आणि मुख्य दृश्य आहे pg_stat_user_tables. User_tables - याचा अर्थ वापरकर्त्याच्या वतीने तयार केलेली टेबल्स. याउलट, PostgreSQL द्वारे स्वतः वापरलेली सिस्टम दृश्ये आहेत. आणि एक सारांश सारणी आहे Alltables, ज्यामध्ये सिस्टम आणि वापरकर्ता दोन्ही समाविष्ट आहेत. तुम्हाला सर्वात जास्त आवडेल अशा कोणत्याही पासून तुम्ही सुरुवात करू शकता.

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

या डेटाच्या आधारे, आम्ही तथाकथित TopN टेबल तयार करू शकतो. उदाहरणार्थ, टॉप-5, टॉप-10. आणि तुम्ही त्या हॉट टेबल्सचा मागोवा घेऊ शकता ज्या इतरांपेक्षा जास्त रिसायकल केल्या जातात. उदाहरणार्थ, समाविष्ट करण्यासाठी 5 "हॉट" टेबल. आणि या TopN टेबल्सचा वापर करून आम्ही आमच्या वर्कलोडचे मूल्यांकन करतो आणि कोणत्याही रिलीझ, अपडेट्स आणि डिप्लॉयमेंटनंतर वर्कलोडच्या वाढीचे मूल्यांकन करू शकतो.

टेबलच्या आकाराचे मूल्यांकन करणे देखील महत्त्वाचे आहे, कारण काहीवेळा विकसक नवीन वैशिष्ट्य आणतात आणि आमची टेबल त्यांच्या मोठ्या आकारात फुगण्यास सुरवात करतात, कारण त्यांनी अतिरिक्त प्रमाणात डेटा जोडण्याचा निर्णय घेतला, परंतु हे कसे होईल याचा अंदाज लावला नाही. डेटाबेसच्या आकारावर परिणाम होतो. अशी प्रकरणे देखील आपल्यासाठी आश्चर्यचकित करतात.

आणि आता तुमच्यासाठी एक छोटासा प्रश्न. तुमच्या डेटाबेस सर्व्हरवरील लोड लक्षात आल्यावर कोणता प्रश्न उद्भवतो? तुम्हाला पुढील प्रश्न काय आहे?

पण प्रत्यक्षात प्रश्न खालीलप्रमाणे उद्भवतो. लोडमुळे कोणत्या विनंत्या होतात? म्हणजेच, लोडमुळे उद्भवणार्या प्रक्रियांकडे पाहणे मनोरंजक नाही. हे स्पष्ट आहे की जर होस्टकडे डेटाबेस असेल तर डेटाबेस तेथे चालू आहे आणि हे स्पष्ट आहे की केवळ डेटाबेसची तेथे विल्हेवाट लावली जाईल. आपण Top उघडल्यास, PostgreSQL मधील प्रक्रियांची एक सूची दिसेल जी काहीतरी करत आहेत. ते काय करत आहेत हे वरून स्पष्ट होणार नाही.

त्यानुसार, तुम्हाला त्या क्वेरी शोधण्याची आवश्यकता आहे ज्यामुळे सर्वाधिक लोड होते, कारण ट्यूनिंग क्वेरी, नियमानुसार, पोस्टग्रेएसक्यूएल किंवा ऑपरेटिंग सिस्टम कॉन्फिगरेशन ट्यून करण्यापेक्षा किंवा हार्डवेअर ट्यून करण्यापेक्षा अधिक नफा देते. माझ्या अंदाजानुसार, हे अंदाजे 80-85-90% आहे. आणि हे खूप वेगाने केले जाते. कॉन्फिगरेशन दुरुस्त करणे, रीस्टार्ट शेड्यूल करण्यापेक्षा विनंती दुरुस्त करणे जलद आहे, विशेषत: डेटाबेस रीस्टार्ट करणे किंवा हार्डवेअर जोडणे शक्य नसल्यास. या क्वेरीमधून चांगला परिणाम मिळवण्यासाठी कुठेतरी क्वेरी पुन्हा लिहिणे किंवा अनुक्रमणिका जोडणे सोपे आहे.

त्यानुसार, विनंत्या आणि त्यांच्या पर्याप्ततेचे निरीक्षण करणे आवश्यक आहे. मॉनिटरिंगचे दुसरे उदाहरण घेऊ. आणि येथे देखील, उत्कृष्ट देखरेख असल्याचे दिसते. प्रतिकृतीची माहिती आहे, थ्रुपुट, ब्लॉकिंग, संसाधन वापराविषयी माहिती आहे. सर्व काही ठीक आहे, परंतु विनंत्यांवर कोणतीही माहिती नाही. आमच्या डेटाबेसमध्ये कोणती क्वेरी चालू आहेत, त्या किती काळ चालू आहेत, यापैकी किती क्वेरी आहेत हे स्पष्ट नाही. आमच्या मॉनिटरिंगमध्ये आम्हाला ही माहिती नेहमी असणे आवश्यक आहे.

आणि ही माहिती मिळवण्यासाठी आपण pg_stat_statements मॉड्यूल वापरू शकतो. त्यावर आधारित, आपण विविध आलेख तयार करू शकता. उदाहरणार्थ, तुम्ही सर्वाधिक वारंवार येणाऱ्या क्वेरींची माहिती मिळवू शकता, म्हणजेच त्या क्वेरींबद्दल ज्या बहुतेक वेळा अंमलात आणल्या जातात. होय, तैनातीनंतर ते पाहणे आणि विनंत्यांमध्ये काही वाढ झाली आहे का हे समजून घेणे देखील खूप उपयुक्त आहे.

तुम्ही प्रदीर्घ क्वेरींचे निरीक्षण करू शकता, म्हणजेच त्या क्वेरी ज्या पूर्ण होण्यासाठी सर्वात जास्त वेळ घेतात. ते प्रोसेसरवर चालतात, ते I/O वापरतात. आम्ही total_time, mean_time, blk_write_time आणि blk_read_time फील्ड वापरून देखील याचे मूल्यमापन करू शकतो.

आम्ही संसाधनांच्या वापराच्या दृष्टीने सर्वात जास्त विनंत्यांचे मूल्यमापन आणि परीक्षण करू शकतो, जे डिस्कवरून वाचतात, जे मेमरीसह कार्य करतात किंवा याउलट, काही प्रकारचे लेखन लोड तयार करतात.

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

आणि तुम्ही तात्पुरत्या फाइल्स किंवा तात्पुरत्या टेबल्स वापरणाऱ्या क्वेरींचेही निरीक्षण करू शकता.

आणि आमच्याकडे अजूनही पार्श्वभूमी प्रक्रिया आहेत. पार्श्वभूमी प्रक्रिया प्रामुख्याने चेकपॉईंट असतात किंवा त्यांना चेकपॉईंट देखील म्हणतात, या ऑटोव्हॅक्यूम आणि प्रतिकृती आहेत.

देखरेखीचे आणखी एक उदाहरण. डावीकडे एक देखभाल टॅब आहे, त्यावर जा आणि काहीतरी उपयुक्त दिसेल अशी आशा करा. परंतु येथे केवळ व्हॅक्यूम ऑपरेशन आणि आकडेवारी संकलनाची वेळ आहे, आणखी काही नाही. ही अतिशय खराब माहिती आहे, त्यामुळे आमच्या डेटाबेसमध्ये पार्श्वभूमी प्रक्रिया कशा कार्य करतात आणि त्यांच्या कामात काही समस्या आहेत का याबद्दल माहिती आमच्याकडे नेहमीच असणे आवश्यक आहे.

जेव्हा आपण चेकपॉईंट्स पाहतो, तेव्हा आपण हे लक्षात ठेवले पाहिजे की चेकपॉईंट्स शार्ड केलेल्या मेमरी क्षेत्रापासून डिस्कवर घाणेरडे पृष्ठे फ्लश करतात, त्यानंतर चेकपॉईंट तयार करतात. आणि पोस्टग्रेएसक्यूएल अचानक आपत्कालीन स्थितीत बंद झाल्यास हा चेकपॉईंट पुनर्प्राप्तीसाठी जागा म्हणून वापरला जाऊ शकतो.

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

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

मी पुन्हा ऑटोव्हॅक्यूमवर परत येत आहे कारण मी म्हटल्याप्रमाणे ही एक गोष्ट आहे, जी डिस्क आणि क्वेरी कार्यप्रदर्शन दोन्ही सहजपणे जोडू शकते, म्हणून ऑटोव्हॅक्यूमच्या प्रमाणाचा अंदाज घेणे नेहमीच महत्त्वाचे असते.

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

आणि, अर्थातच, व्हॅक्यूमचा कालावधी. जर आमच्याकडे दीर्घकाळ टिकणारे व्हॅक्यूम खूप काळ चालत असतील तर याचा अर्थ असा आहे की आम्हाला पुन्हा व्हॅक्यूम कॉन्फिगरेशनकडे लक्ष देणे आणि कदाचित त्याच्या सेटिंग्जवर पुनर्विचार करणे आवश्यक आहे. कारण अशी परिस्थिती उद्भवू शकते जेव्हा व्हॅक्यूम टेबलवर बराच काळ (3-4 तास) काम करतो, परंतु व्हॅक्यूम कार्य करत असताना, मोठ्या प्रमाणात मृत पंक्ती पुन्हा टेबलमध्ये जमा होण्यास व्यवस्थापित होते. आणि व्हॅक्यूम पूर्ण होताच, त्याला हे टेबल पुन्हा व्हॅक्यूम करणे आवश्यक आहे. आणि आम्ही एका परिस्थितीत येतो - एक अंतहीन व्हॅक्यूम. आणि या प्रकरणात, व्हॅक्यूम त्याच्या कामाचा सामना करत नाही आणि टेबल्स हळूहळू आकारात फुगायला लागतात, जरी त्यातील उपयुक्त डेटाची मात्रा समान राहते. म्हणूनच, दीर्घ व्हॅक्यूम्स दरम्यान, आम्ही नेहमी कॉन्फिगरेशन पाहतो आणि ते ऑप्टिमाइझ करण्याचा प्रयत्न करतो, परंतु त्याच वेळी क्लायंटच्या विनंत्यांच्या कार्यक्षमतेस त्रास होणार नाही.

आजकाल जवळजवळ कोणतीही पोस्टग्रेएसक्यूएल स्थापना नाही ज्यामध्ये स्ट्रीमिंग प्रतिकृती नाही. प्रतिकृती ही मास्टरकडून प्रतिकृतीमध्ये डेटा हलविण्याची प्रक्रिया आहे.

PostgreSQL मधील प्रतिकृती व्यवहार लॉगद्वारे केली जाते. विझार्ड एक व्यवहार लॉग व्युत्पन्न करतो. ट्रान्झॅक्शन लॉग नेटवर्क कनेक्शनवरून प्रतिकृतीवर प्रवास करतो आणि नंतर तो प्रतिकृतीवर पुनरुत्पादित केला जातो. हे सोपं आहे.

त्यानुसार, प्रतिकृती अंतराचे निरीक्षण करण्यासाठी pg_stat_replication दृश्य वापरले जाते. परंतु तिच्याबरोबर सर्व काही सोपे नाही. आवृत्ती 10 मध्ये, दृश्यात अनेक बदल झाले आहेत. प्रथम, काही फील्डचे नाव बदलले गेले आहे. आणि काही फील्ड जोडले गेले आहेत. आवृत्ती 10 मध्ये, फील्ड दिसू लागले जे तुम्हाला प्रतिकृती अंतराचा काही सेकंदात अंदाज लावू देतात. हे खूप आरामदायक आहे. आवृत्ती 10 पूर्वी, बाइट्समधील प्रतिकृती अंतराचा अंदाज लावणे शक्य होते. हा पर्याय आवृत्ती 10 मध्ये कायम आहे, म्हणजे तुमच्यासाठी अधिक सोयीस्कर काय आहे ते तुम्ही निवडू शकता - बाइट्समधील अंतराचा अंदाज लावा किंवा सेकंदांमधील अंतराचा अंदाज लावा. बरेच लोक दोन्ही करतात.

परंतु असे असले तरी, प्रतिकृती अंतराचे मूल्यांकन करण्यासाठी, आपल्याला व्यवहारातील लॉगची स्थिती माहित असणे आवश्यक आहे. आणि या व्यवहार लॉग पोझिशन्स pg_stat_replication दृश्यात आहेत. तुलनेने बोलायचे झाल्यास, आम्ही pg_xlog_location_diff() फंक्शन वापरून व्यवहार लॉगमध्ये दोन गुण घेऊ शकतो. त्यांच्यामधील डेल्टाची गणना करा आणि प्रतिकृती अंतर बाइट्समध्ये मिळवा. हे खूप सोयीस्कर आणि सोपे आहे.

आवृत्ती १० मध्ये, या फंक्शनचे नाव बदलून pg_wal_lsn_diff(). सर्वसाधारणपणे, सर्व फंक्शन्स, व्ह्यूज आणि युटिलिटीजमध्ये जिथे “xlog” हा शब्द दिसत होता, तो “wal” या मूल्याने बदलला गेला. हे दृश्ये आणि कार्य दोन्ही लागू होते. असा हा नवोपक्रम आहे.

तसेच, आवृत्ती 10 मध्ये, ओळी जोडल्या गेल्या ज्या विशेषतः अंतर दर्शवितात. हे राइट लॅग, फ्लश लॅग, रिप्ले लॅग आहेत. म्हणजेच या गोष्टींवर लक्ष ठेवणे गरजेचे आहे. जर आम्हाला दिसले की आमच्याकडे प्रतिकृती अंतर आहे, तर ते का दिसले, ते कोठून आले याचा तपास करणे आणि समस्येचे निराकरण करणे आवश्यक आहे.

सिस्टम मेट्रिक्ससह जवळजवळ सर्वकाही क्रमाने आहे. जेव्हा कोणतेही निरीक्षण सुरू होते, तेव्हा ते सिस्टम मेट्रिक्ससह सुरू होते. हे प्रोसेसर, मेमरी, स्वॅप, नेटवर्क आणि डिस्कची विल्हेवाट आहे. तथापि, अनेक पॅरामीटर्स डीफॉल्टनुसार नाहीत.

रीसायकलिंग प्रक्रियेत सर्वकाही व्यवस्थित असल्यास, डिस्क रिसायकलिंगमध्ये समस्या आहेत. नियमानुसार, मॉनिटरिंग डेव्हलपर थ्रूपुटबद्दल माहिती जोडतात. हे iops किंवा बाइट्समध्ये असू शकते. परंतु ते डिस्क उपकरणांच्या विलंब आणि वापराबद्दल विसरतात. हे अधिक महत्त्वाचे पॅरामीटर्स आहेत जे आम्हाला आमच्या डिस्क्स किती लोड आहेत आणि ते किती हळू आहेत याचे मूल्यांकन करण्यास अनुमती देतात. जर आमच्याकडे उच्च विलंब असेल तर याचा अर्थ डिस्कमध्ये काही समस्या आहेत. जर आमच्याकडे उच्च वापर असेल, तर याचा अर्थ असा आहे की डिस्क सामना करत नाहीत. ही थ्रूपुटपेक्षा चांगली वैशिष्ट्ये आहेत.

शिवाय, ही आकडेवारी /proc फाईल सिस्टीम वरून देखील मिळवता येते, जसे की रिसायकलिंग प्रोसेसरसाठी केली जाते. ही माहिती मॉनिटरिंगमध्ये का जोडली जात नाही हे मला माहीत नाही. परंतु असे असले तरी, हे आपल्या निरीक्षणामध्ये असणे महत्त्वाचे आहे.

हेच नेटवर्क इंटरफेसवर लागू होते. पॅकेट्समध्ये, बाइट्समध्ये नेटवर्क थ्रूपुटबद्दल माहिती आहे, परंतु तरीही विलंब बद्दल कोणतीही माहिती नाही आणि वापराबद्दल कोणतीही माहिती नाही, जरी ही देखील उपयुक्त माहिती आहे.

कोणत्याही देखरेखीत कमतरता आहेत. आणि आपण कोणत्या प्रकारचे मॉनिटरिंग घेतले हे महत्त्वाचे नाही, ते नेहमीच काही निकष पूर्ण करणार नाही. परंतु तरीही, ते विकसित होत आहेत, नवीन वैशिष्ट्ये आणि नवीन गोष्टी जोडल्या जात आहेत, म्हणून काहीतरी निवडा आणि ते पूर्ण करा.

आणि पूर्ण करण्यासाठी, प्रदान केलेल्या आकडेवारीचा अर्थ काय आहे आणि समस्यांचे निराकरण करण्यासाठी आपण त्यांचा वापर कसा करू शकता याची आपल्याला नेहमी कल्पना असणे आवश्यक आहे.

आणि काही महत्त्वाचे मुद्दे:

• तुम्ही नेहमी उपलब्धतेचे निरीक्षण केले पाहिजे आणि डॅशबोर्ड असले पाहिजेत जेणेकरून डेटाबेसमध्ये सर्वकाही व्यवस्थित आहे हे तुम्ही त्वरीत मूल्यांकन करू शकता.
• खराब क्लायंटला बाहेर काढण्यासाठी आणि त्यांना शूट करण्यासाठी क्लायंट आपल्या डेटाबेससह काय काम करत आहेत याची आपल्याला नेहमी कल्पना असणे आवश्यक आहे.
• हे क्लायंट डेटासह कसे कार्य करतात याचे मूल्यांकन करणे महत्त्वाचे आहे. तुम्हाला तुमच्या वर्कलोडची कल्पना असणे आवश्यक आहे.
• कोणत्या प्रश्नांच्या मदतीने हा वर्कलोड कसा तयार होतो याचे मूल्यमापन करणे महत्त्वाचे आहे. तुम्ही प्रश्नांचे मूल्यांकन करू शकता, तुम्ही त्यांना ऑप्टिमाइझ करू शकता, त्यांना रिफॅक्टर करू शकता, त्यांच्यासाठी निर्देशांक तयार करू शकता. ते खूप महत्वाचे आहे.
• पार्श्वभूमी प्रक्रिया क्लायंटच्या विनंत्यांवर नकारात्मक परिणाम करू शकतात, त्यामुळे ते खूप संसाधने वापरत नाहीत यावर लक्ष ठेवणे महत्त्वाचे आहे.
• सिस्टम मेट्रिक्स तुम्हाला तुमच्या सर्व्हरची स्केलिंग आणि क्षमता वाढवण्यासाठी योजना बनवण्याची परवानगी देतात, त्यामुळे त्यांचा मागोवा घेणे आणि त्यांचे मूल्यांकन करणे देखील महत्त्वाचे आहे.

तुम्हाला या विषयात स्वारस्य असल्यास, तुम्ही या लिंक्सचे अनुसरण करू शकता.
http://bit.do/stats_collector - हे सांख्यिकी संग्राहकाचे अधिकृत दस्तऐवजीकरण आहे. सर्व सांख्यिकीय दृश्यांचे वर्णन आणि सर्व फील्डचे वर्णन आहे. तुम्ही ते वाचू शकता, समजून घेऊ शकता आणि त्यांचे विश्लेषण करू शकता. आणि त्यावर आधारित, तुमचे आलेख तयार करा आणि ते तुमच्या मॉनिटरिंगमध्ये जोडा.

विनंत्या उदाहरणे:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

हे आमचे कॉर्पोरेट भांडार आहे आणि माझे स्वतःचे आहे. त्यामध्ये उदाहरण प्रश्न आहेत. तेथे मालिकेतील निवडक* कडून कोणतीही क्वेरी नाहीत. रुचीपूर्ण फंक्शन्स वापरून जॉइन्ससह आधीच तयार केलेल्या क्वेरी आहेत जी तुम्हाला कच्च्या संख्येला वाचनीय, सोयीस्कर मूल्यांमध्ये बदलण्याची परवानगी देतात, म्हणजे हे बाइट्स, वेळ आहेत. तुम्ही त्यांना उचलू शकता, त्यांना पाहू शकता, त्यांचे विश्लेषण करू शकता, त्यांना तुमच्या मॉनिटरिंगमध्ये जोडू शकता, त्यांच्यावर आधारित तुमचे मॉनिटरिंग तयार करू शकता.

प्रश्न

प्रश्न: तुम्ही म्हणालात की तुम्ही ब्रँडची जाहिरात करणार नाही, पण तरीही मी उत्सुक आहे - तुम्ही तुमच्या प्रोजेक्टमध्ये कोणत्या प्रकारचे डॅशबोर्ड वापरता?
उत्तरः ते बदलते. असे घडते की आम्ही एका ग्राहकाकडे येतो आणि त्याचे स्वतःचे निरीक्षण आहे. आणि आम्ही ग्राहकांना त्यांच्या मॉनिटरिंगमध्ये काय जोडले पाहिजे याबद्दल सल्ला देतो. सर्वात वाईट परिस्थिती Zabbix ची आहे. कारण त्यात TopN आलेख तयार करण्याची क्षमता नाही. आम्ही स्वतः वापरतो ओकमीटर, कारण आम्ही मॉनिटरिंगवर या मुलांशी सल्लामसलत करत होतो. त्यांनी आमच्या तांत्रिक वैशिष्ट्यांवर आधारित PostgreSQL चे परीक्षण केले. मी माझा स्वतःचा पाळीव प्राणी-प्रोजेक्ट लिहित आहे, जो प्रोमिथियस द्वारे डेटा संकलित करतो आणि त्यास प्रस्तुत करतो ग्राफाना. प्रोमिथियसमध्ये माझा स्वतःचा निर्यातदार तयार करणे आणि नंतर ग्राफानामध्ये सर्वकाही प्रस्तुत करणे हे माझे कार्य आहे.

प्रश्न: AWR अहवाल किंवा... एकत्रीकरणाचे काही analogues आहेत का? तुम्हाला असे काही माहीत आहे का?
उत्तर: होय, मला AWR काय आहे हे माहित आहे, ही एक छान गोष्ट आहे. याक्षणी अशा विविध प्रकारच्या सायकली आहेत ज्या अंदाजे खालील मॉडेलची अंमलबजावणी करतात. काही वेळेच्या अंतराने, काही बेसलाइन समान PostgreSQL वर किंवा वेगळ्या स्टोरेजवर लिहिल्या जातात. तुम्ही त्यांना इंटरनेटवर गुगल करू शकता, ते तिथे आहेत. पोस्टग्रेएसक्यूएल थ्रेडमधील sql.ru फोरमवर अशा गोष्टीचा एक विकासक बसला आहे. तुम्ही त्याला तिथे पकडू शकता. होय, अशा गोष्टी आहेत, त्या वापरल्या जाऊ शकतात. त्यात प्लस pgCenter मी एक गोष्ट देखील लिहित आहे जी तुम्हाला तीच गोष्ट करण्याची परवानगी देते.

PS1 तुम्ही postgres_exporter वापरत असल्यास, तुम्ही कोणता डॅशबोर्ड वापरत आहात? त्यापैकी अनेक आहेत. ते आधीच जुने झाले आहेत. कदाचित समुदाय अद्ययावत टेम्पलेट तयार करेल?

PS2 काढले pganalyze कारण ते एक प्रोप्रायटरी SaaS ऑफर आहे जे कार्यप्रदर्शन निरीक्षण आणि स्वयंचलित ट्यूनिंग सूचनांवर लक्ष केंद्रित करते.

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

तुम्ही कोणते स्व-होस्ट केलेले पोस्टग्रेसक्यूएल मॉनिटरिंग (डॅशबोर्डसह) सर्वोत्तम मानता?

• 30,0%Alexey Lesovsky किंवा zabbix 4.4 किंवा libzbxpgsql + zabbix libzbxpgsql + zabbix3 कडून Zabbix + जोडणे

• 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