अपने डेटाबेस प्रदर्शन की निगरानी और अनुकूलन कैसे करें:एक व्यावहारिक मार्गदर्शिका

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

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

डेटाबेस प्रदर्शन की निगरानी क्यों करें?

मान लें कि कोई क्वेरी बहुत धीमी है, और आपके ऐप को परिणामों की प्रतीक्षा करनी पड़ती है-जिससे आपके अंतिम-उपयोगकर्ताओं और/या आपके ऐप के एक हिस्से में चीज़ें रुक जाती हैं।

ट्रैफिक जाम की तरह, एक हिस्सा कहीं और होने वाली घटना के प्रभाव के रूप में स्थिर हो सकता है। यदि बहुत सी प्रश्नों को हल करने में बहुत अधिक समय लगता है, तो ऐसा इसलिए हो सकता है क्योंकि अन्य प्रश्न रास्ते में आ जाते हैं।

आपका लक्ष्य यह पता लगाना है कि कोई समस्या कहां से आ रही है, इससे पहले कि आपके ऐप्लिकेशन के अन्य हिस्सों में चीजें गलत हो जाएं।

अगला कदम अपने आर्किटेक्चर को अनुकूलित करने के लिए निगरानी का सक्रिय रूप से उपयोग करना है और देखें कि आप चीजों को तेजी से कैसे बना सकते हैं। लेकिन हम खुद से आगे निकल रहे हैं - आइए चरण 1 से शुरू करें:

चरण 1:AKA इंस्ट्रुमेंटिंग डेटाबेस प्रदर्शन को मापना

डेटाबेस की निगरानी यह सुनिश्चित करने के साथ शुरू होती है कि आप सही चीजों को मापते हैं:

• त्रुटियाँ

• प्रदर्शन

• प्रश्नों का साधन और 90वां प्रतिशत अवधि

• कुल थ्रूपुट - थ्रूपुट एक समस्या होने पर आपको ट्रिगर/फ्लैग सेट करने का एक और तरीका देता है

सौभाग्य से, उस डेटा को प्राप्त करना आपके लिए पहले ही किया जा चुका है:आपका एपीएम सॉफ़्टवेयर संभवतः आपको वह कॉन्फ़िगर करने देता है जिसे आप उपकरण और मापना चाहते हैं। यदि आप ऐपसिग्नल का उपयोग करते हैं, तो डेटा एकत्र करना और एकत्र करना बिना किसी सेटअप के स्वचालित रूप से होता है। हमने आपके लिए भारी भारोत्तोलन किया है!

चरण 2:एक प्रारंभिक बिंदु - उच्च प्रभाव वाली क्वेरी खोजें

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

यह स्क्रीन आपको ऑप्टिमाइज़ेशन के लिए एक बढ़िया शुरुआती बिंदु देगी। डिफ़ॉल्ट रूप से, धीमी क्वेरी को प्रभाव द्वारा क्रमबद्ध किया जाता है। वे ऐसे प्रश्न हैं जो आप अक्सर करते हैं। प्रभाव थ्रूपुट x माध्य क्वेरी समय है।

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

एक त्वरित साइड-स्टेप:कुछ व्यक्तिगत क्वेरी ठीक करें

अब आप फिक्सिंग में गोता लगाने के लिए कुछ प्रश्न पा सकते हैं।

यदि आप धीमी क्वेरी पर क्लिक करते हैं, तो आप इसके सभी विवरण दाईं ओर देखेंगे, क्वेरी के लिए थ्रूपुट और प्रतिक्रिया समय से लेकर क्वेरी नाम तक:

चरम पर प्रतिक्रिया समय पर होवर करें, और फिर आप 'यहां क्या हुआ' विकल्प पर क्लिक करके ज़ूम इन कर सकते हैं। आप देखेंगे कि उस समय क्या त्रुटियां हुईं, उस नमूने में, और होस्ट पर क्या हुआ।

हमने इसे एक विशेष एंटी-पैटर्न:N+1 के लिए बहुत दृश्यमान बना दिया है। N+1एंटी-पैटर्न तब होता है जब पिछली क्वेरी के प्रत्येक परिणाम के लिए कोई क्वेरी निष्पादित की जाती है।

क्वेरी की संख्या N + 1 है, जिसमें N प्रारंभिक क्वेरी परिणामों के लिए प्रश्नों की संख्या है। यदि उस प्रारंभिक क्वेरी का एक परिणाम है, तो N+1 =2. यदि उसके पास 1,000 परिणाम हैं, तो N+1 =1,001 क्वेरीज़ हैं। बूम।

यदि प्रश्न N+1 विरोधी पैटर्न का पालन करते हैं, तो यह एक सुखद दुर्घटना है - उन्हें यहां लेबल किया गया है ताकि आप उन्हें तुरंत ढूंढ सकें:

हम उन्हें यहां हल करने के तरीके में नहीं जाएंगे - हमने N+1 प्रश्नों पर एक अलग ब्लॉग पोस्ट लिखा है।

ठीक है, अब मान लेते हैं कि हमने कुछ पागल चीजें ठीक कीं, और जैसे ही हमने उन्हें ठीक किया, हमने देखा कि वे कब हुईं और सबसे खराब प्रतिक्रिया समय।

चरण 3:ढूंढना पैटर्न पर निर्णय लेना - गलत क्या है?

निगरानी अक्सर यह देखने के बारे में होती है कि चीजें कब गलत होती हैं। लेकिन निगरानी के आसपास की जटिलता का एक हिस्सा यह परिभाषित कर रहा है कि आपके सेटअप के लिए क्या 'गलत' माना जाना चाहिए। साथ ही, क्या आप किसी ऐसे मुद्दे से सतर्क रहेंगे जो तब स्वयं हल हो जाता है या जो नहीं होता है उसे याद करते हैं?

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

नोड-पोस्टग्रेज डैशबोर्ड इस तरह डेटा दिखाएगा:

अगर आप इसे अपने ऐप के लिए सेट करना चाहते हैं, तो यहां कुछ और पढ़ना है।

जब आप अलग-अलग समय सीमाओं के बीच स्विच करते हैं, तो आपको छोटी चोटियां दिखाई देंगी जो एक घंटे के औसत में गायब हो जाती हैं, साथ ही जब आप अधिक विस्तारित समय सीमा तक ज़ूम आउट करते हैं तो चोटियां ऊंची रहती हैं।

सबसे धीमी क्वेरी स्क्रीन देखने के अपने अनुभव से, अब हमें मुख्य दोषियों के बारे में एक विचार है और वे कब चरम पर थे।

थ्रूपुट में कुछ छोटी चोटियाँ ठीक हो सकती हैं - उदाहरण के लिए, हो सकता है कि होस्ट क्वेरी को धीमा करने वाली अन्य प्रक्रियाओं को चला रहा हो।

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

चरण 4:क्या रखें गेट यू अप एट नाइट?

हम आमतौर पर स्पेक्ट्रम के शोर वाले हिस्से पर शुरू करने की सलाह देते हैं:एक ऐसे चैनल पर आपको सचेत करने के लिए कुछ ट्रिगर सेट करें जो आपको जगाता नहीं है, जैसे पेजरड्यूटी के बजाय ईमेल या स्लैक।

"event_duration" मीट्रिक पर एक कस्टम मीट्रिक ट्रिगर बनाएं और अपने ऐप में औसत क्वेरी समय पर अलर्ट प्राप्त करने के लिए माध्य फ़ील्ड का चयन करें। आपके ऐप द्वारा सामना की जाने वाली सबसे धीमी क्वेरी पर अलर्ट प्राप्त करने के लिए 90वां या 95वां प्रतिशत चुनें।

फिर उस प्रकार के ईवेंट के लिए "समूह" और "नाम स्थान" टैग कॉन्फ़िगर करें जिसके बारे में आप और किस नाम स्थान के बारे में सतर्क रहना चाहते हैं। उदाहरण के लिए, समूह के लिए "active_record" (रेल) या "पोस्टग्रेज" (Node.js) या "एक्टो" (एलिक्सिर), और नाम स्थान के लिए "वेब" या "पृष्ठभूमि":

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

फिर आप कम शोर करने के लिए ट्रिगर्स को एडजस्ट कर सकते हैं और जब आप विशिष्ट अलर्ट से जागना चाहते हैं तो चैनल जोड़ सकते हैं।

चरण 5:डेटाबेस मॉनिटरिंग सेट अप करने के साथ संपन्न

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

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

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

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

AppSignal आज़माएं, स्ट्रूपवाफ़ेल प्राप्त करें

स्ट्रूपवाफेल्स की बात करें तो हम उन्हें पूरी दुनिया में भेजते हैं। Ruby, Elixir और Node.js के लिए हमारे AppSignal APM सॉफ़्टवेयर को आज़माएं। अगर आप नि:शुल्क परीक्षण सेट अप करते हैं और हमसे संपर्क करते हैं, तो हम आपको घर पर स्ट्रूपवाफल्स का एक बॉक्स भेजेंगे।