PostgreSQL निगरानी को आधारभूत। एलेक्सी लेसोव्स्की

म तपाईंलाई डेटा एग्रेट "पोस्टग्रेएसक्यूएल निगरानीको आधारभूतहरू" बाट एलेक्सी लेसोभस्की द्वारा रिपोर्टको ट्रान्सक्रिप्ट पढ्न सुझाव दिन्छु।

यस रिपोर्टमा, एलेक्सी लेसोभस्कीले पोस्ट-ग्रेस तथ्याङ्कका मुख्य बुँदाहरू, तिनीहरूको अर्थ के हो, र तिनीहरू किन अनुगमनमा उपस्थित हुनुपर्छ भन्ने बारे कुरा गर्नेछन्; अनुगमनमा कुन ग्राफहरू हुनुपर्छ, तिनीहरूलाई कसरी थप्ने र तिनीहरूलाई कसरी व्याख्या गर्ने भन्ने बारे। रिपोर्ट डाटाबेस प्रशासकहरू, प्रणाली प्रशासकहरू र विकासकर्ताहरूका लागि उपयोगी हुनेछ जो Postgres समस्या निवारणमा रुचि राख्छन्।

मेरो नाम Alexey Lesovsky हो, म डाटा Egret कम्पनी को प्रतिनिधित्व गर्छु।

मेरो बारेमा केहि शब्दहरू। मैले एक प्रणाली प्रशासकको रूपमा लामो समय पहिले सुरु गरें।

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

र मेरो क्यारियर भर, म सधैं तथ्याङ्क, अनुगमन, र टेलिमेट्री विषयहरूमा रुचि राखेको छु। र जब म प्रणाली प्रशासक थिएँ, मैले Zabbix सँग धेरै नजिकबाट काम गरें। र मैले जस्तै स्क्रिप्टको सानो सेट लेखें zabbix-विस्तारहरू। उनी आफ्नो पालामा निकै लोकप्रिय थिए । र त्यहाँ धेरै फरक महत्त्वपूर्ण चीजहरू निगरानी गर्न सम्भव थियो, लिनक्स मात्र होइन, तर विभिन्न घटकहरू पनि।

अब म PostgreSQL मा काम गर्दैछु। म पहिले नै अर्को कुरा लेख्दै छु जसले तपाईंलाई PostgreSQL तथ्याङ्कहरूसँग काम गर्न अनुमति दिन्छ। भनिन्छ pgCenter (Habré मा लेख - स्नायु र तनाव बिना पोस्ट-ग्रेस तथ्याङ्क).

एक सानो परिचयात्मक नोट। हाम्रा ग्राहकहरू, हाम्रा ग्राहकहरूसँग कस्तो अवस्था छ? डाटाबेससँग सम्बन्धित कुनै प्रकारको दुर्घटना छ। र जब डाटाबेस पहिले नै पुनर्स्थापित भइसकेको छ, विभाग प्रमुख वा विकास प्रमुख आउँछन् र भन्छन्: "साथीहरू, हामीले डाटाबेसलाई निगरानी गर्न आवश्यक छ, किनकि केहि नराम्रो भयो र हामीले भविष्यमा यो हुनबाट रोक्न आवश्यक छ।" र यहाँ एक अनुगमन प्रणाली छनोट गर्ने वा अवस्थित अनुगमन प्रणाली अनुकूलन गर्ने रोचक प्रक्रिया सुरु हुन्छ ताकि तपाइँ आफ्नो डाटाबेस - 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 फिल्डमा फोकस गर्छौं। यो फिल्डले डाटाबेसमा हुने रोलब्याकहरूको संख्या मात्र देखाउँदैन, तर त्रुटिहरूको संख्यालाई पनि ध्यानमा राख्छ। तुलनात्मक रूपमा भन्नुपर्दा, हामी यो आंकडा हाम्रो ड्यासबोर्डमा देखाउन सक्छौं र हामीसँग हाल कति त्रुटिहरू छन् भनेर हेर्न सक्छौं। यदि त्यहाँ धेरै त्रुटिहरू छन् भने, त्यसपछि लगहरूमा हेर्नु र तिनीहरू कस्ता प्रकारका त्रुटिहरू छन् र तिनीहरू किन हुन्छन्, र त्यसपछि लगानी गर्नुहोस् र तिनीहरूलाई समाधान गर्ने यो राम्रो कारण हो।

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

लेनदेनको संख्या अनुमान गर्न, हामी फेरि pg_stat_database दृश्यलाई सन्दर्भ गर्न सक्छौं। हामी कमिटहरूको संख्या र रोलब्याकहरूको संख्या थप्न सक्छौं र प्रति सेकेन्ड लेनदेनको संख्या प्राप्त गर्न सक्छौं।

के सबैले बुझ्छन् कि धेरै अनुरोधहरू एक लेनदेनमा फिट हुन सक्छन्? त्यसैले TPS र QPS अलि फरक छन्।

प्रति सेकेन्ड अनुरोधहरूको संख्या pg_stat_statements बाट प्राप्त गर्न सकिन्छ र केवल सबै पूरा अनुरोधहरूको योगफल गणना गर्नुहोस्। यो स्पष्ट छ कि हामीले हालको मानलाई अघिल्लोसँग तुलना गर्छौं, यसलाई घटाउँछौं, डेल्टा पाउँछौं, र मात्रा पाउँछौं।

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

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

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

किन यसको अनुगमन गर्न आवश्यक छ? किनभने शून्यताले कहिलेकाहीँ धेरै दुख दिन्छ। यसले ठूलो मात्रामा स्रोतहरू उपभोग गर्दछ र ग्राहक अनुरोधहरूले परिणामको रूपमा पीडित हुन थाल्छ।

र यो pg_stat_activity दृश्य मार्फत निगरानी गरिनु पर्छ, जसको बारेमा म अर्को खण्डमा कुरा गर्नेछु। यो दृश्यले डाटाबेसमा हालको गतिविधि देखाउँछ। र यस गतिविधि मार्फत हामी अहिले काम गरिरहेका भ्याकुमहरूको संख्या ट्र्याक गर्न सक्छौं। हामी भ्याकुमहरू ट्र्याक गर्न सक्छौं र देख्न सक्छौं कि यदि हामीले सीमा नाघ्यौं भने, यो PostgreSQL सेटिङहरू हेर्ने र भ्याकुमको सञ्चालनलाई अनुकूलन गर्ने कारण हो।

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

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

जडान गरिएका ग्राहकहरूको बारेमा जानकारी महत्त्वपूर्ण छ किनभने, PostgreSQL परिप्रेक्ष्यबाट, ग्राहकहरू फरक छन्। त्यहाँ राम्रो ग्राहकहरू छन् र त्यहाँ खराब ग्राहकहरू छन्।

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

त्यहाँ परिस्थितिहरू छन् जब ग्राहक जडान भएको छ, यसले जडान राख्छ, तर केही गर्दैन। यो निष्क्रिय अवस्थामा छ।

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

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

अनुगमनको अर्को उदाहरण। र यहाँ पहिले नै एक सभ्य ड्यासबोर्ड छ। माथि जडानहरू बारे जानकारी छ। DB जडान - 8 टुक्रा। र यो सबै छ। कुन क्लाइन्टहरू सक्रिय छन्, कुन क्लाइन्टहरू निष्क्रिय छन्, केही गर्दैनन् भन्ने बारे हामीसँग कुनै जानकारी छैन। पेन्डिङ लेनदेन र पेन्डिङ जडानहरूको बारेमा कुनै जानकारी छैन, अर्थात् यो जडानहरूको संख्या देखाउने फिगर हो र त्यो हो। र त्यसपछि आफ्नै लागि अनुमान गर्नुहोस्।

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

यदि हामीले लामो लेनदेन देख्यौं भने, हामीले तिनीहरूलाई पहिले नै पूरा गर्नुपर्छ। OLTP लोडको लागि, लामो लेनदेनहरू पहिले नै 1-2-3 मिनेट भन्दा बढी छन्. OLAP कार्यभारको लागि, लामो लेनदेनहरू सामान्य छन्, तर यदि तिनीहरू पूरा हुन दुई घण्टा भन्दा बढी लाग्छ भने, यो पनि एक संकेत हो कि हामीसँग कतै तिरछा छ।

एकपटक क्लाइन्टहरू डाटाबेसमा जडान भएपछि, तिनीहरूले हाम्रो डाटासँग काम गर्न थाल्छन्। तिनीहरू तालिकाहरू पहुँच गर्छन्, तिनीहरू तालिकाबाट डेटा प्राप्त गर्न अनुक्रमणिकाहरू पहुँच गर्छन्। र यो मूल्याङ्कन गर्न महत्त्वपूर्ण छ कि ग्राहकहरूले यस डेटासँग कसरी अन्तरक्रिया गर्छन्।

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

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

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

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

र यो हुन्छ कि तथ्याङ्क "फ्लोट"। तालिकामा गुणस्तर र मात्रा तथ्याङ्कहरू कुनै न कुनै रूपमा परिवर्तन भयो, तर तथ्याङ्कहरू सङ्कलन भएनन्। र गठन गरिएका योजनाहरू इष्टतम नहुन सक्छन्। र यदि हाम्रा योजनाहरू तालिकाहरूमा आधारित, संकलित अनुगमनको आधारमा सबोप्टिमल भएमा, हामी यी विसंगतिहरू देख्न सक्षम हुनेछौं। उदाहरणका लागि, कतै डाटा गुणात्मक रूपमा परिवर्तन भयो र अनुक्रमणिकाको सट्टा, तालिका मार्फत एक अनुक्रमिक पास प्रयोग गर्न थाल्यो, अर्थात्। यदि कुनै क्वेरीले 100 पङ्क्तिहरू मात्र फर्काउन आवश्यक छ (त्यहाँ 100 को सीमा छ), त्यसपछि यो क्वेरीको लागि पूर्ण खोजी गरिनेछ। र यो सधैं प्रदर्शन मा धेरै नराम्रो प्रभाव छ।

र हामी यो अनुगमन मा देख्न सक्छौं। र पहिले नै यो क्वेरी हेर्नुहोस्, यसको लागि व्याख्या चलाउनुहोस्, तथ्याङ्क सङ्कलन गर्नुहोस्, नयाँ अतिरिक्त अनुक्रमणिका निर्माण गर्नुहोस्। र पहिले नै यो समस्या प्रतिक्रिया। त्यसैले यो महत्त्वपूर्ण छ।

अनुगमनको अर्को उदाहरण। मलाई लाग्छ धेरै मानिसहरूले उहाँलाई चिन्छन् किनभने उहाँ धेरै लोकप्रिय हुनुहुन्छ। कसले यसलाई आफ्नो परियोजनाहरूमा प्रयोग गर्दछ Prometheus? कसले यो उत्पादन प्रोमिथियससँग संयोजनमा प्रयोग गर्दछ? तथ्य यो हो कि यो निगरानी को मानक भण्डार मा PostgreSQL संग काम गर्न को लागी एक ड्यासबोर्ड छ - postgres_exporter प्रोमेथियस। तर त्यहाँ एक खराब विवरण छ।

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

यी तालिकाहरूमा तथ्याङ्कहरू कसरी प्राप्त गर्ने? यस उद्देश्यको लागि, PostgreSQL को एक निश्चित परिवार छ। र मुख्य दृश्य हो pg_stat_user_tables। User_tables - यसको मतलब प्रयोगकर्ताको तर्फबाट बनाइएको तालिका हो। यसको विपरित, त्यहाँ प्रणाली दृश्यहरू छन् जुन PostgreSQL द्वारा प्रयोग गरिन्छ। र त्यहाँ एक सारांश तालिका Alltables छ, जसमा प्रणाली र प्रयोगकर्ता दुवै समावेश छ। तपाईंले तिनीहरूलाई मनपर्ने कुनै पनिबाट सुरु गर्न सक्नुहुन्छ।

माथिका फिल्डहरू प्रयोग गरेर तपाईंले सम्मिलितहरू, अद्यावधिकहरू र मेटाउनेहरूको सङ्ख्या अनुमान गर्न सक्नुहुन्छ। मैले प्रयोग गरेको ड्यासबोर्डको उदाहरणले कार्यभारको विशेषताहरू मूल्याङ्कन गर्न यी क्षेत्रहरू प्रयोग गर्दछ। त्यसकारण, हामी तिनीहरूलाई पनि निर्माण गर्न सक्छौं। तर यो याद गर्न लायक छ कि यी टपलहरू हुन्, बाइटहरू होइनन्, त्यसैले हामी यसलाई बाइटहरूमा मात्र गर्न सक्दैनौं।

यस डाटाको आधारमा, हामी तथाकथित TopN तालिकाहरू निर्माण गर्न सक्छौं। उदाहरणका लागि, शीर्ष-5, शीर्ष-10। र तपाइँ ती तातो तालिकाहरू ट्र्याक गर्न सक्नुहुन्छ जुन अन्य भन्दा बढी पुन: प्रयोग गरिन्छ। उदाहरण को लागी, सम्मिलनको लागि 5 "तातो" तालिकाहरू। र यी TopN तालिकाहरू प्रयोग गरेर हामी हाम्रो कार्यभारको मूल्याङ्कन गर्छौं र कुनै पनि रिलीज, अपडेटहरू, र डिप्लोयमेन्टहरू पछि कार्यभारको फटहरू मूल्याङ्कन गर्न सक्छौं।

यो तालिकाको आकार मूल्याङ्कन गर्न पनि महत्त्वपूर्ण छ, किनभने कहिलेकाहीँ विकासकर्ताहरूले नयाँ सुविधा रोल आउट गर्छन्, र हाम्रो तालिकाहरू तिनीहरूको ठूलो आकारमा फुल्न थाल्छन्, किनभने तिनीहरूले थप डेटा थप्ने निर्णय गरे, तर यो कसरी हुनेछ भनेर भविष्यवाणी गरेन। डाटाबेसको आकारलाई असर गर्छ। यस्ता घटनाहरू हाम्रा लागि अचम्मका रूपमा पनि आउँछन्।

र अब तपाईंको लागि एउटा सानो प्रश्न। तपाईको डाटाबेस सर्भरमा लोड भएको देख्दा कस्तो प्रश्न उठ्छ? तपाईको अर्को प्रश्न के छ?

तर वास्तवमा प्रश्न निम्नानुसार उठ्छ। लोडको कारण के अनुरोधहरू छन्? त्यो हो, यो लोडको कारण हुने प्रक्रियाहरू हेर्न रोचक छैन। यो स्पष्ट छ कि यदि होस्टसँग डाटाबेस छ भने, डाटाबेस त्यहाँ चलिरहेको छ र यो स्पष्ट छ कि डाटाबेसहरू मात्र त्यहाँ डिस्पोज हुनेछन्। यदि हामीले शीर्ष खोल्यौं भने, हामी त्यहाँ PostgreSQL मा प्रक्रियाहरूको सूची देख्नेछौं जुन केहि गरिरहेको छ। उनीहरूले के गरिरहेका छन् भन्ने कुरा शीर्षबाट स्पष्ट हुनेछैन।

तदनुसार, तपाईंले ती प्रश्नहरू फेला पार्न आवश्यक छ जसले उच्चतम लोडको कारण बनाउँछ, किनभने ट्युनिङ क्वेरीहरूले, नियमको रूपमा, PostgreSQL वा अपरेटिङ सिस्टम कन्फिगरेसन, वा हार्डवेयर ट्युनिङ भन्दा बढी लाभ दिन्छ। मेरो अनुमान अनुसार, यो लगभग 80-85-90% हो। र यो धेरै छिटो गरिन्छ। यो कन्फिगरेसन सच्याउन, पुन: सुरु गर्ने तालिका बनाउन भन्दा, विशेष गरी डाटाबेस पुन: सुरु गर्न सकिँदैन, वा हार्डवेयर थप्न भन्दा छिटो छ। यो क्वेरीबाट राम्रो परिणाम प्राप्त गर्न कतै क्वेरी पुन: लेख्न वा अनुक्रमणिका थप्न सजिलो छ।

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

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

तपाईले सबैभन्दा लामो प्रश्नहरूको निगरानी गर्न सक्नुहुन्छ, त्यो हो, ती प्रश्नहरू जसले पूरा गर्न सबैभन्दा लामो समय लिन्छ। तिनीहरू प्रोसेसरमा चल्छन्, तिनीहरूले I/O उपभोग गर्छन्। हामी कुल_समय, मतलब_समय, blk_write_time र blk_read_time फिल्डहरू प्रयोग गरेर पनि यसलाई मूल्याङ्कन गर्न सक्छौं।

हामी मूल्याङ्कन गर्न सक्छौं र संसाधन प्रयोगको सन्दर्भमा भारी अनुरोधहरूको निगरानी गर्न सक्छौं, डिस्कबाट पढ्ने, मेमोरीसँग काम गर्ने, वा, यसको विपरीत, कुनै प्रकारको लेखन लोड सिर्जना गर्नुहोस्।

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

र तपाइँ अस्थायी फाइलहरू वा अस्थायी तालिकाहरू प्रयोग गर्ने प्रश्नहरू पनि निगरानी गर्न सक्नुहुन्छ।

र हामीसँग अझै पनि पृष्ठभूमि प्रक्रियाहरू छन्। पृष्ठभूमि प्रक्रियाहरू मुख्य रूपमा चेकपोइन्टहरू हुन् वा तिनीहरूलाई चेकपोइन्टहरू पनि भनिन्छ, यी अटोभ्याक्यूम र प्रतिकृति हुन्।

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

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

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

तदनुसार, निर्दिष्ट क्षेत्रहरू प्रयोग गरेर pg_stat_bgwriter मार्फत हामी हुने चेकपोइन्टहरूको संख्या निगरानी गर्न सक्छौं। र यदि हामीसँग निश्चित अवधिमा धेरै चेकपोइन्टहरू छन् (१०-१५-२० मिनेटमा, आधा घण्टामा), उदाहरणका लागि, ३-४-५, त्यसपछि यो पहिले नै समस्या हुन सक्छ। र तपाईले पहिले नै डेटाबेसमा हेर्नु आवश्यक छ, कन्फिगरेसनमा हेर्नुहोस्, के कारणले चेकपोइन्टहरूको यस्तो प्रशस्तता हुन्छ। सायद त्यहाँ कुनै प्रकारको ठूलो रेकर्डिङ भइरहेको छ। हामीले पहिले नै कार्यभारको मूल्याङ्कन गर्न सक्छौं, किनभने हामीले पहिले नै कार्यभार ग्राफहरू थपेका छौं। हामी पहिले नै चेकपोइन्ट प्यारामिटरहरू ट्वीक गर्न सक्छौं र तिनीहरूले क्वेरी कार्यसम्पादनलाई ठूलो असर गर्दैनन् भनेर सुनिश्चित गर्न सक्छौं।

म फेरि अटोभ्याकुममा फर्कदैछु किनभने यो त्यस्तो चीज हो, जस्तो कि मैले भने, यसले सजिलैसँग डिस्क र क्वेरी कार्यसम्पादन दुवै थप्न सक्छ, त्यसैले अटोभ्याकुमको मात्रा अनुमान गर्न सधैं महत्त्वपूर्ण हुन्छ।

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

र, निस्सन्देह, vacuums को अवधि। यदि हामीसँग लामो समयसम्म चल्ने भ्याकुमहरू छन् भने, यसको मतलब यो हो कि हामीले फेरि भ्याकुम कन्फिगरेसनमा ध्यान दिनुपर्छ र सायद यसको सेटिङहरूमा पुनर्विचार गर्नुपर्छ। किनभने भ्याकुम लामो समय (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

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

तपाईंका प्रश्नहरू

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

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

PS1 यदि तपाइँ postgres_exporter प्रयोग गर्दै हुनुहुन्छ भने, तपाइँ कुन ड्यासबोर्ड प्रयोग गर्दै हुनुहुन्छ? ती मध्ये धेरै छन्। तिनीहरू पहिले नै पुरानो भइसकेका छन्। हुनसक्छ समुदायले अद्यावधिक टेम्प्लेट सिर्जना गर्नेछ?

PS2 हटाइयो pganalyze किनभने यो एक मालिकाना SaaS प्रस्ताव हो जसले प्रदर्शन निगरानी र स्वचालित ट्युनिङ सुझावहरूमा ध्यान केन्द्रित गर्दछ।

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

कुन स्व-होस्ट गरिएको postgresql अनुगमन (ड्यासबोर्डको साथ) तपाईलाई उत्तम मान्नुहुन्छ?

• 30,0%Zabbix + Alexey Lesovsky वा zabbix 4.4 वा libzbxpgsql + zabbix libzbxpgsql + zabbix3 बाट थपहरू

• 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 एक स्वामित्व सास हो - म यसलाई मेटाउन सक्दिन

• 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