प्रदर्शन डेटा का उपयोग करके क्षमता नियोजन

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

नया या मौजूदा?

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

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

[बोनस:यदि विक्रेता के पास प्रदान करने के लिए कोई जानकारी नहीं है, तो क्या यह मददगार नहीं होगा यदि, सिस्टम के चालू होने और कुछ महीनों तक चलने के बाद, आप उन्हें अपना डेटा भेजते हैं ... जैसे कि आपके पास कौन सा हार्डवेयर है , और कार्यभार कैसा दिखता है? इसके लिए 20-पृष्ठ का लेखन होना आवश्यक नहीं है, लेकिन प्रतिक्रिया उन्हें आगे बढ़ने के लिए और अधिक सक्रिय होने की दिशा में प्रेरित कर सकती है।]

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

संग्रहण

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

हार्डवेयर संसाधन

सीपीयू

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

स्मृति

मेमोरी अपेक्षाकृत सस्ती है और यह हमारी सिफारिश है कि हम हमेशा अधिकतम मात्रा में मेमोरी खरीद सकते हैं जो एक सर्वर रख सकता है। मेमोरी से डेटा पढ़ना डिस्क से पढ़ने की तुलना में काफी तेज है, इसलिए जितना अधिक डेटा मेमोरी में फिट होगा उतना ही बेहतर होगा। ध्यान दें कि संपूर्ण डेटाबेस में है . नहीं है स्मृति में फिट होने के लिए। स्मृति में फ़िट होने के लिए आपको बस डेटा के कार्यशील सेट की आवश्यकता है। 2TB डेटाबेस पर विचार करें। यह संभावना नहीं है कि, एक OLTP परिदृश्य में, सभी 2TB को प्रतिदिन एक्सेस किया जाता है। आमतौर पर केवल हाल का डेटा ही एक्सेस किया जाता है - शायद पिछले 30 या 60 दिन। यही वह डेटा है जिसे मेमोरी में फिट करने की आवश्यकता होती है। लेकिन निश्चित रूप से, हम शायद ही कभी शुद्ध OLTP वातावरण देखते हैं, अक्सर यह एक मिश्रित वातावरण होता है क्योंकि उपयोगकर्ता डेटा के बड़े सेट पर रिपोर्ट चलाना पसंद करते हैं, और डेटाबेस की कोई डेटा वेयरहाउस या रिपोर्टिंग कॉपी नहीं होती है, इसलिए उनके पास है उत्पादन के खिलाफ रिपोर्ट चलाने के लिए। यह स्मृति आवश्यकता को जटिल बनाता है। अब, कभी-कभी आपको स्मृति में उस पुराने डेटा की आवश्यकता होती है, लेकिन कभी-कभी आपको नहीं। कार्यभार को समझना महत्वपूर्ण है; डेटाबेस के विरुद्ध किस प्रकार की क्वेरी निष्पादित की जा रही हैं?

यदि आप मानक संस्करण का उपयोग कर रहे हैं, तो सत्यापित करें कि आपके पास सर्वर में समर्थित अधिकतम मेमोरी से अधिक मेमोरी है। उदाहरण के लिए, SQL सर्वर 2014 और उच्चतर के साथ, मानक संस्करण में मेमोरी की अधिकतम मात्रा जिसे आप बफर पूल (अधिकतम सर्वर मेमोरी सेटिंग के माध्यम से) आवंटित कर सकते हैं, 128GB है। इसलिए, आप सर्वर में अधिक मेमोरी (जैसे 160GB) रखना चाहते हैं ताकि आप अधिकतम सर्वर मेमोरी को 128GB के उच्चतम संभव मान पर सेट कर सकें, और अभी भी OS और अन्य SQL सर्वर प्रक्रियाओं के लिए मेमोरी उपलब्ध हो। इसके अलावा, SQL सर्वर 2016 SP1 मानक संस्करण के साथ आप 32GB प्रति डेटाबेस की सीमा के साथ इन-मेमोरी OLTP का उपयोग कर सकते हैं। यह अधिकतम सर्वर मेमोरी मान से ऊपर है, इसलिए यदि आप इस सुविधा का उपयोग करने की योजना बना रहे हैं, तो तदनुसार मेमोरी खरीदें।

भंडारण

जब हम भंडारण के लिए प्रदर्शन आवश्यकताओं के बारे में बात करते हैं, तो आप अक्सर लोगों को आईओपीएस (प्रति सेकंड इनपुट/आउटपुट संचालन) के बारे में बात करते सुनते हैं। वास्तव में, यह लेख एक दर्शक के एक प्रश्न से प्रेरित था जिसने बेंचमार्किंग और बेसलाइनिंग पर मेरा प्लूरलसाइट पाठ्यक्रम देखा था। सवाल था:"आप प्रति उपयोगकर्ता आईओ की संख्या का अनुमान लगाने के लिए उपयोगकर्ता कनेक्शन के लिए प्रति सेकंड पढ़ने और लिखने के लिए प्रदर्शन मॉनिटर काउंटर को कैसे सहसंबंधित करते हैं?" प्रति सेकंड पढ़ना और लिखना इनपुट/आउटपुट संचालन हैं, इसलिए हमारे पास यह डेटा उदाहरण स्तर पर PerfMon के माध्यम से उपलब्ध है, और इसका उपयोग आप एक उदाहरण के लिए IOPS आवश्यकताओं को परिभाषित करने के लिए करते हैं।

हालाँकि, यदि आप जानते हैं कि और . पढ़ता और लिखता है उपयोगकर्ता कनेक्शन, तो आप कुछ गणित कर सकते हैं और प्रति उपयोगकर्ता आईओपीएस का पता लगा सकते हैं। यदि आप समाधान विकसित करने और अधिक उपयोगकर्ता जोड़ने की योजना बना रहे हैं तो यह उपयोगी है। आप यह सुनिश्चित करना चाहते हैं कि समाधान का पैमाना होगा, और आपके पास एक विकल्प है कि आप अपने परिकलित IOPS प्रति उपयोगकर्ता, X उपयोगकर्ताओं की संख्या के आधार पर लें, और फिर Y उपयोगकर्ताओं की संख्या के लिए उदाहरण IOPS का अनुमान लगाएं। अब, हम इस गणना के साथ बहुत सी धारणाएँ बनाते हैं। हम मानते हैं कि जिस तरह से नए कनेक्शन सिस्टम का उपयोग करते हैं वह आज भी वैसा ही है - अंत में ऐसा हो भी सकता है और नहीं भी, आपको तब तक पता नहीं चलेगा जब तक कि सिस्टम लागू नहीं हो जाता। जब आप इस मान को समझते हैं (पढ़ता है + लिखता है / उपयोगकर्ता कनेक्शन =प्रति उपयोगकर्ता औसत आईओपीएस), तो आप जानते हैं कि अनुमानित उपयोगकर्ता कनेक्शन के आधार पर समाधान के लिए आईओपीएस का अनुमान कैसे लगाया जाता है।

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

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

निष्कर्ष

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