जब हम सक्रिय अनुकूलन के बारे में बात करते हैं तो पहली बात यह है कि यह नहीं जाना जाता है कि अनुकूलित करने की आवश्यकता क्या है। "ऐसा करो, मुझे नहीं पता क्या।"

• कोई क्लासिक एल्गोरिथ्म नहीं है।
• समस्या अभी तक उत्पन्न नहीं हुई है (अज्ञात), और कोई केवल अनुमान लगा सकता है कि यह कहां हो सकता है।
• हमें सिस्टम में कुछ संभावित कमजोर बिंदुओं को खोजने की जरूरत है।
• इन स्थानों में क्वेरी प्रदर्शन को अनुकूलित करने का प्रयास करें।

सक्रिय अनुकूलन के मुख्य लक्ष्य

सक्रिय अनुकूलन के मुख्य कार्य प्रतिक्रियाशील अनुकूलन के कार्यों से भिन्न होते हैं और निम्नानुसार हैं:

• डेटाबेस में बाधाओं से छुटकारा पाने;
• डेटाबेस संसाधन की खपत में कमी।

अंतिम क्षण सबसे मौलिक है। प्रतिक्रियाशील अनुकूलन के मामले में, हमारे पास समग्र रूप से संसाधन खपत को कम करने का कार्य नहीं है, लेकिन केवल कार्यक्षमता की प्रतिक्रिया समय को स्वीकार्य सीमा के भीतर लाने का कार्य है।



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



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

एक मुकाबला डेटाबेस पर अनुकूलन सक्रिय है?

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

फिर भी, हम आरएनसीओ में लड़ाई के सर्वर पर इस परियोजना को करते हैं । कई बार मैंने सुना: “ऐसा कैसे? आप इसे एक मुकाबला सर्वर पर करते हैं - इसका मतलब है कि यह सक्रिय प्रदर्शन अनुकूलन नहीं है! " यहां हमें उस दृष्टिकोण को याद करने की आवश्यकता है जो आईटीआईएल में खेती की जाती है। ITIL के दृष्टिकोण से, हमारे पास:

• प्रदर्शन की घटनाएं वही हैं जो पहले से ही हुई हैं;
• प्रदर्शन की घटनाओं को होने से रोकने के लिए हम जो उपाय करते हैं।

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

इसलिए, इस रिपोर्ट में, आईटीआईएल के अर्थ में सक्रियता को सक्रियता के रूप में समझा जाता है , हम प्रदर्शन की घटना होने से पहले समस्या का समाधान करते हैं।

संदर्भ बिंदु

RNKO "भुगतान केंद्र" 2 बड़े सिस्टम परोसता है:

• आरबीएस-रिटेल बैंक;
• सीएफटी बैंक।

इन प्रणालियों पर लोड की प्रकृति मिश्रित है (DSS + OLTP): कुछ ऐसी चीज है जो बहुत जल्दी काम करती है, रिपोर्ट होती है, मध्यम लोड होती है।

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

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

इसके साथ कुछ करना होगा!

अनुकूलन दृष्टिकोण

हमने सोचा और प्रोएक्टिव ऑप्टिमाइज़ेशन की तकनीक को समझा। लेकिन इससे पहले कि मैं सक्रिय अनुकूलन के बारे में बात करूं, मुझे शास्त्रीय प्रतिक्रियात्मक अनुकूलन के बारे में कुछ शब्द कहने चाहिए।

प्रतिक्रियात्मक अनुकूलन

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

क्लासिक एक्शन एल्गोरिथ्म:

1. समस्या को पुन: प्रस्तुत करें।
2. समस्या स्थान का पता लगाएँ।
3. समस्या स्थान का अनुकूलन करें।

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

प्रतिक्रियाशील अनुकूलन के मुख्य लक्ष्य

प्रतिक्रियात्मक अनुकूलन में, दो मुख्य लक्ष्यों को प्रतिष्ठित किया जा सकता है:

1. प्रतिक्रिया समय में कमी ।

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

2. बैच प्रसंस्करण के दौरान समय की प्रति यूनिट संसाधित वस्तुओं की संख्या में वृद्धि ।

जब लेनदेन का बैच प्रसंस्करण जारी है, तो पैकेज से एक वस्तु के प्रसंस्करण समय को कम करना आवश्यक है।

प्रतिक्रियाशील दृष्टिकोण के पेशेवरों:

● विभिन्न प्रकार के उपकरण और तकनीक प्रतिक्रियाशील दृष्टिकोण का मुख्य प्लस है।

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

● वांछित प्रतिक्रिया समय एक और प्लस है।

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

प्रतिक्रियाशील दृष्टिकोण के विपक्ष:

• प्रदर्शन की घटनाएं बनी हुई हैं - यह प्रतिक्रियात्मक दृष्टिकोण का सबसे बड़ा ऋण है, क्योंकि हम हमेशा मूल कारण तक नहीं पहुंच सकते हैं। वह इस तरह से कहीं बाहर रह सकती है और कहीं गहरे झूठ बोल सकती है, इस तथ्य के बावजूद कि हमने स्वीकार्य प्रदर्शन हासिल किया।

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

प्रोएक्टिव ऑप्टिमाइज़ेशन

पहली बात यह है कि यह पता नहीं है कि अनुकूलित करने की आवश्यकता क्या है। "ऐसा करो, मुझे नहीं पता क्या।"

• कोई क्लासिक एल्गोरिथ्म नहीं है।
• समस्या अभी तक उत्पन्न नहीं हुई है (अज्ञात), और कोई केवल अनुमान लगा सकता है कि यह कहां हो सकता है।
• हमें सिस्टम में कुछ संभावित कमजोर बिंदुओं को खोजने की जरूरत है।
• इन स्थानों में क्वेरी प्रदर्शन को अनुकूलित करने का प्रयास करें।

सक्रिय अनुकूलन के मुख्य लक्ष्य

सक्रिय अनुकूलन के मुख्य कार्य प्रतिक्रियाशील अनुकूलन के कार्यों से भिन्न होते हैं और निम्नानुसार हैं:

• डेटाबेस में बाधाओं से छुटकारा पाने;
• डेटाबेस संसाधन की खपत में कमी।

अंतिम क्षण सबसे मौलिक है। प्रतिक्रियात्मक अनुकूलन के मामले में, हमारे पास संपूर्ण रूप से संसाधन खपत को कम करने का कार्य नहीं है, लेकिन केवल कार्यक्षमता की प्रतिक्रिया समय को स्वीकार्य सीमा के भीतर लाने का कार्य है।

डेटाबेस में अड़चनें कैसे खोजें?

जब हम इस समस्या के बारे में सोचना शुरू करते हैं, तो तुरंत कई उप-कार्य उत्पन्न होते हैं। इसे करना आवश्यक है:

• सीपीयू परीक्षण
• रीड / रिकॉर्ड पर लोड परीक्षण;
• सक्रिय सत्रों की संख्या से तनाव परीक्षण;
• लोड परीक्षण ... आदि

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

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

इस मामले में क्या करना है? आइए यह समझने की कोशिश करें कि पहले स्थान पर किन संसाधनों की कमी होने की संभावना है।

घटते डेटाबेस संसाधन की खपत

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

दूसरा महत्वपूर्ण प्रश्न: किसी चीज़ की तलाश कैसे करें?
सवाल बहुत गैर-तुच्छ है। हम नैदानिक ​​पैक विकल्प के साथ ओरेकल एंटरप्राइज संस्करण का उपयोग करते हैं और हमने अपने लिए ऐसा उपकरण ढूंढ लिया है - AWR रिपोर्ट (ओरेकल के अन्य संस्करणों में आप STATSPACK रिपोर्ट का उपयोग कर सकते हैं)। PostgreSQL में एक एनालॉग - pgstatspack है, एंड्री जुबकोव का pg_profile है । अंतिम उत्पाद, जैसा कि मैंने समझा, दिखाई दिया और पिछले साल ही विकसित होना शुरू हुआ। MySQL के लिए, मुझे समान टूल नहीं मिले, लेकिन मैं MySQL विशेषज्ञ नहीं हूं।

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

शीर्ष 5 संचालन का अनुकूलन

हम जो प्रोएक्टिव ऑप्टिमाइज़ेशन तकनीक विकसित कर चुके हैं और पेमेंट सेंटर आरएनसीओ में उपयोग कर रहे हैं, उसमें चार चरण हैं।

स्टेज 1. हम सबसे बड़ी संभव अवधि के लिए AWR रिपोर्ट प्राप्त करते हैं।

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

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

कभी-कभी बहुत अप्रत्याशित परिस्थितियां सामने आती हैं। उदाहरण के लिए, CFT बैंक के मामले में, रिपोर्ट सर्वर कतार की जाँच करने वाला अनुरोध शीर्ष 10 में हो सकता है। इसके अलावा, यह अनुरोध आधिकारिक है और किसी भी व्यावसायिक तर्क को निष्पादित नहीं करता है, लेकिन केवल यह जांचता है कि निष्पादन पर कोई रिपोर्ट है या नहीं।

स्टेज 2. हम अनुभाग देखते हैं:

• एसक्यूएल बीता समय द्वारा आदेश - एसक्यूएल प्रश्नों क्रम द्वारा हल;
• CPU समय द्वारा SQL ऑर्डर किया गया - CPU उपयोग के लिए;
• एसक्यूएल हो जाता है - तार्किक रीडिंग द्वारा;
• SQL रीड्स द्वारा आदेशित - भौतिक रीडिंग के लिए।

एसक्यूएल के शेष खंडों का अध्ययन आवश्यकतानुसार किया जाता है।

चरण 3. हम माता-पिता के संचालन और उन पर निर्भर अनुरोधों का निर्धारण करते हैं।

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

स्टेज 4. हम शीर्ष 5 ऑपरेशन का अनुकूलन करते हैं।

इस तरह के समूहीकरण के बाद, आउटपुट संचालन की एक सूची है जिसमें से आप सबसे कठिन का चयन कर सकते हैं। हम 5 ऑपरेशन (अनुरोध नहीं, अर्थात् संचालन) तक सीमित हैं। यदि सिस्टम अधिक जटिल है, तो आप अधिक ले सकते हैं।

सामान्य क्वेरी डिज़ाइन त्रुटियाँ

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

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

● बड़ा चयन → पूर्ण स्कैन
दूसरी आम गलती एक बड़ा डेटा नमूना है - एक पूर्ण स्कैन का क्लासिक मामला। हर कोई जानता है कि एक पूर्ण स्कैन का उपयोग केवल तभी किया जाना चाहिए जब यह वास्तव में उचित हो। कभी-कभी ऐसे मामले होते हैं जब एक पूर्ण स्कैन पाया जाता है, जहां इसके बिना करना संभव होगा, उदाहरण के लिए, यदि आप फ़िल्टरिंग शर्तों को pl / sql कोड से क्वेरी में स्थानांतरित करते हैं।

● अप्रभावी सूचकांक → लॉन्ग इंडेक्स रेंज स्कैन
शायद यह यहां तक ​​कि सबसे आम गलती है, जिसके लिए किसी कारण से वे बहुत कम कहते हैं - तथाकथित अकुशल सूचकांक (लंबे सूचकांक स्कैन, लंबे इंडेक्स रेंज स्कैन)। उदाहरण के लिए, हमारे पास रजिस्ट्रियों के लिए एक तालिका है। अनुरोध में, हम इस एजेंट की सभी रजिस्ट्रियों को खोजने की कोशिश करते हैं, और अंततः कुछ प्रकार की फ़िल्टरिंग स्थिति जोड़ते हैं, उदाहरण के लिए, एक निश्चित अवधि के लिए, या एक विशिष्ट संख्या, या एक विशिष्ट ग्राहक के साथ। ऐसी स्थितियों में, सूचकांक आमतौर पर उपयोग की सार्वभौमिकता के कारणों के लिए केवल "एजेंट" फ़ील्ड पर बनाया जाता है। परिणाम निम्न चित्र है: काम के पहले वर्ष में, कहते हैं, एजेंट के पास इस तालिका में 100 प्रविष्टियां थीं, अगले साल पहले से ही 1,000, दूसरे वर्ष में 10,000 प्रविष्टियां हो सकती हैं। कुछ समय बीत जाता है, ये रिकॉर्ड 100,000 हो जाते हैं। जाहिर है, अनुरोध धीरे-धीरे काम करना शुरू कर देता है, क्योंकि अनुरोध में आपको न केवल एजेंट पहचानकर्ता को जोड़ने की आवश्यकता है, बल्कि कुछ अतिरिक्त फ़िल्टर भी, इस मामले में तारीख तक। अन्यथा, यह पता चलेगा कि नमूना आकार साल-दर-साल बढ़ जाएगा, क्योंकि इस एजेंट के लिए रजिस्ट्रियों की संख्या बढ़ रही है। इस समस्या को सूचकांक स्तर पर संबोधित किया जाना चाहिए। यदि बहुत अधिक डेटा है, तो हमें पहले से ही विभाजन की दिशा में सोचना चाहिए।

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

केस की पढ़ाई

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

उदाहरण 1

select * from (select o.* from rnko_dep_reestr_in_oper o where o.type_oper = 'proc' and o.ean_rnko in (select l.ean_rnko from rnko_dep_link l where l.s_rnko = :1) order by o.date_oper_bnk desc, o.date_reg desc) where ROWNUM = 1 

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

आइए जानने की कोशिश करें कि उसके साथ क्या गलत है।

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



आइए जानने की कोशिश करें कि यहां क्या चल रहा है?



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

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

तालिका में तार्किक रीडिंग के लिए एक पंक्ति है। हम देखते हैं कि एक लॉन्च के लिए इसे लगभग 8 हजार ब्लॉक (आमतौर पर 1 ब्लॉक 8 KB) की आवश्यकता होती है। यह पता चला है कि अनुरोध, एक बार काम करने के बाद, मेमोरी से लगभग 64 एमबी डेटा लोड करता है। यहां कुछ गलत है, हमें समझने की जरूरत है।

आइए देखें योजना: एक पूर्ण स्कैन है। खैर, आगे बढ़ते हैं।

  Plan hash value: 634977963 ------------------------------------------------------------------- | Id | Operation | Name | ------------------------------------------------------------------- | 0 | SELECT STATEMENT | | |* 1 | COUNT STOPKEY | | | 2 | VIEW | | |* 3 | SORT ORDER BY STOPKEY | | | 4 | NESTED LOOPS | | | 5 | TABLE ACCESS BY INDEX ROWID| RNKO_DEP_LINK | |* 6 | INDEX UNIQUE SCAN | UK_RNKODEPLINK$S_RNKO | |* 7 | TABLE ACCESS FULL | RNKO_DEP_REESTR_IN_OPER | ------------------------------------------------------------------- Predicate Information (identified by operation id): 1 - filter(ROWNUM=1) 3 - filter(ROWNUM=1) 6 - access("L"."S_RNKO"=:1) 7 - filter(("O"."TYPE_OPER"='proc' AND "O"."EAN_RNKO"="L"."EAN_RNKO")) 

Rnko_dep_reestr_in_oper तालिका में, केवल 5 मिलियन पंक्तियाँ हैं और उनकी औसत पंक्ति की लंबाई 150 बाइट्स है। लेकिन यह पता चला कि जो फ़ील्ड कनेक्ट हो रहा है उसके लिए पर्याप्त इंडेक्स नहीं है - उप-क्षेत्र ean_rnko फ़ील्ड के माध्यम से अनुरोध से जुड़ा है, जिसके लिए कोई इंडेक्स नहीं है!

इसके अलावा, भले ही वह प्रकट होता है, वास्तव में स्थिति बहुत अच्छी नहीं होगी। वह लॉन्ग इंडेक्स स्कैन (लॉन्ग इंडेक्स रेंज स्कैन) होगा। ean_rnko एजेंट का आंतरिक पहचानकर्ता है। एजेंट रजिस्ट्रियां जमा हो जाएंगी, और हर साल इस अनुरोध का चयन करने वाले डेटा की मात्रा बढ़ जाएगी, और अनुरोध धीमा हो जाएगा।

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


अनुकूलन के बाद, ऑपरेटिंग समय एक सेकंड के सौवें भाग से कम हो गया (यह 0.93 था), ब्लॉकों की संख्या पहले की तुलना में औसतन 8.5 - 1000 गुना कम हो गई।

उदाहरण 2

 select count(1) from loy$barcodes t where t.id_processing = :b1 and t.id_rec_out is null and not t.barcode is null and t.status = 'u' and not t.id_card is null 

मैंने यह कहकर कहानी शुरू की कि आमतौर पर क्वेरी टॉप में कुछ जटिल होता है। ऊपर एक "जटिल" क्वेरी का एक उदाहरण है जो एक तालिका (!) पर जाता है, और यह शीर्ष प्रश्नों में भी शामिल हो गया :) ID_PROCESSING फ़ील्ड पर एक सूचकांक है!
इस क्वेरी में 3 IS NULL स्थितियां हैं, और, जैसा कि हम जानते हैं, ऐसी स्थितियों को अनुक्रमित नहीं किया जाता है (आप इस मामले में सूचकांक का उपयोग नहीं कर सकते हैं)। साथ ही, समानता प्रकार (ID_PROCESSING और STATUS द्वारा) की केवल दो स्थितियाँ हैं।

संभवतः, जो डेवलपर इस क्वेरी को देखेगा, सबसे पहले ID_PROCESSING और STATUS पर एक इंडेक्स बनाने का सुझाव देगा। लेकिन उन आंकड़ों की मात्रा को देखते हुए जिन्हें चुना जाएगा (उनमें से बहुत कुछ होगा), यह समाधान काम नहीं करता है।

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


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


और यदि आप आगे देखते हैं, तो आप देख सकते हैं कि क्वेरी समय कभी-कभी काफी भिन्न होता है - कई बार, जो पहले से ही महत्वपूर्ण है।


चलिए इसका पता लगाते हैं।

ओरेकल एंटरप्राइज मैनेजर में SQL- मॉनिटरिंग यूटिलिटी है। इस उपयोगिता के साथ आप अनुरोध द्वारा संसाधनों की खपत को वास्तविक समय में देख सकते हैं।


समस्यात्मक अनुरोध के लिए उपरोक्त रिपोर्ट। सबसे पहले, हमें इस तथ्य में रुचि होनी चाहिए कि वास्तविक रोल्स कॉलम में INDEX RANGE SCAN (निचला रेखा) 17% लाइनों को दर्शाता है। शायद गौर करने लायक।

यदि हम कार्यान्वयन योजना को आगे देखते हैं, तो यह पता चलता है कि योजना में अगले आइटम के बाद, इन 17 मिलियन लाइनों में से, केवल 1705 शेष है। सवाल यह है कि 17 मिलियन क्यों चुना गया था? लगभग 0.01% अंतिम नमूने में रहे , अर्थात्, स्पष्ट रूप से अक्षम, अनावश्यक काम किया गया था । इसके अलावा, यह काम हर 5 मिनट में किया जाता है। यहाँ समस्या है! इसलिए, इस अनुरोध ने शीर्ष प्रश्नों को मारा।

आइए इस गैर-तुच्छ समस्या को हल करने का प्रयास करें। जो सूचकांक पहले स्थान पर है, वह अक्षम है, इसलिए आपको कुछ मुश्किलों के साथ आने की जरूरत है और IS NULL शर्तों को हराएं।

नया सूचकांक

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

 create index gc.loy$barcod_unload_i on gc.loy$barcodes (gc.loy_barcodes_ic_unload(id_rec_out, barcode, id_card, status), id_processing);  function loy_barcodes_ic_unload( pIdRecOut in loy$barcodes.id_rec_out%type, pBarcode in loy$barcodes.barcode%type, pIdCard in loy$barcodes.id_card%type, pStatus in loy$barcodes.status%type) return varchar2 deterministic is vRes varchar2(1) := ''; begin if pIdRecOut is null and pBarcode is not null and pIdCard is not null and pStatus = 'U' then vRes := pStatus; end if; return vRes; end loy_barcodes_ic_unload; 

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

इस सूचकांक के आवेदन के परिणामस्वरूप निम्न परिणाम हुए:



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

औसत अनुरोध आँकड़े
	को	बाद
बीता हुआ समय, एकांत	143.21	60.7
सीपीयू समय, सेकंड	33.23	45.38
बफर ब्लॉक हो जाता है	6`288`237.67	1`589`836
डिस्क रीड्स ब्लॉक	266`600.33	2`680

ऑपरेटिंग समय 2.5 गुना कम हो गया, और संसाधन खपत (बफर हो जाता है) - लगभग 4. डिस्क से पढ़ने वाले डेटा ब्लॉक की संख्या में काफी कमी आई।

प्रोएक्टिव ऑप्टिमाइज़ेशन परिणाम

हमने प्राप्त किया है:

• डेटाबेस पर लोड को कम करना;
• डेटाबेस की स्थिरता में सुधार;
• सॉफ्टवेयर प्रदर्शन की घटनाओं की संख्या में उल्लेखनीय कमी।

प्रदर्शन की घटनाओं में 10 गुना की कमी आई । यह एक व्यक्तिपरक राशि है, इससे पहले महीने में 1-2 बार आरबीएस-रिटेल बैंक कॉम्प्लेक्स में घटनाएं होती थीं, लेकिन अब हम व्यावहारिक रूप से उनके बारे में भूल गए हैं।

यह सवाल उठाता है - सॉफ्टवेयर प्रदर्शन की घटनाओं के बारे में क्या? हमने सीधे उनके साथ व्यवहार नहीं किया?

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

लॉजिकल रीडिंग मेमोरी के साथ काम कर रहा है, यह जल्दी से होता है, और डिस्क तक कोई भी पहुंच धीमी है (यदि आप समय को देखते हैं, तो मिलीसेकंड)। यदि आप भाग्यशाली हैं, और ऑपरेटिंग सिस्टम के कैश में या ऐरे कैश में यह डेटा है, तो यह अभी भी दसियों माइक्रोसेकंड होगा। ओरेकल के कैश से पढ़ना ज्यादा तेज है।

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

प्रोएक्टिव ऑप्टिमाइज़ेशन सारांश:

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

Oracle डेटाबेस में आँकड़े प्राप्त करने के लिए कई उपकरण हैं:

• AWR रिपोर्ट (DBMS_WORKLOAD_REPOSITORY.awr_report_html);
• एंटरप्राइज मैनेजर क्लाउड कंट्रोल 12 सी (एसक्यूएल विवरण);
• SQL विवरण सक्रिय रिपोर्ट (DBMS_PERF.report_sql);
• SQL मॉनिटरिंग (EMCC में टैब);
• SQL मॉनिटरिंग रिपोर्ट (DBMS_SQLTUNE.report_sql_monitor *)।

इन उपकरणों में से कुछ कंसोल में काम करते हैं, अर्थात्, वे एंटरप्राइज़ प्रबंधक से बंधे नहीं हैं।


बोनस: आरएनसीओ "भुगतान केंद्र" और सीएफटी के विशेषज्ञ नोवोसिबिर्स्क में सम्मेलन के लिए अच्छी तरह से तैयार थे, कुछ उपयोगी रिपोर्टें बनाईं, और एक वास्तविक निकास रेडियो भी आयोजित किया। दो दिनों के लिए, विशेषज्ञों, वक्ताओं और आयोजकों ने सीएफटी रेडियो का दौरा किया। आप प्रविष्टियों को शामिल करके साइबेरियाई गर्मियों में वापस आ सकते हैं, यहां ब्लॉकों के लिंक दिए गए हैं: कुबेरनेट्स: पेशेवरों और विपक्ष ; डेटा विज्ञान और मशीन लर्निंग ; DevOps ।

मॉस्को के हाईलोअड ++ में, जो पहले से ही 8 और 9 नवंबर है, वहां और भी दिलचस्प चीजें होंगी। कार्यक्रम में अत्यधिक भरी हुई परियोजनाओं, मास्टर कक्षाओं, बैठकों और भागीदारों से काम के सभी पहलुओं पर रिपोर्ट शामिल हैं जो विशेषज्ञ सलाह साझा करेंगे और आश्चर्यचकित करने के लिए कुछ पाएंगे। सबसे दिलचस्प के बारे में लिखना सुनिश्चित करें और समाचार पत्र में सूचित करें, जुड़ा हुआ है!