... उम्मीद कर रहा था कि मुझे मिल सकता है ... एक मोटा मोटा अनुमान है कि हमें क्या चलना चाहिए।
आपके प्रश्नों और डेटा आकारों के बारे में अधिक जानकारी के बिना, आपको किसी भी तरह का अनुमान देना वास्तव में मुश्किल है, अकेले ही एक सटीक अनुमान दें।
डेटाबेस: sql सर्वर 2008 r2 एंटरप्राइज़ डेटाबेस
विंडोज: विंडोज 2008 r2 एंटरप्राइज 64 बिट, बहुत यकीन है कि VMware पर चल रहा है।
प्रोसेसर: Intel (R) Xeon (R) CPU E7-4860 @ 2.27GHz 2.26 GHz (2 प्रोसेसर)
इंस्टॉल की गई मेमोरी: 4GB
दो प्रोसेसर (मैं मान रहा हूं कि यह वीएम में 2 कोर के रूप में सामने आया है) अंडर-प्रोवीड हो सकता है या नहीं। एक वीएम को सौंपी गई कोर जरूरी नहीं कि भौतिक कोर से सीधे मैप की जाए (या जरूरत पड़ने पर 100% सिंगल का उपयोग करने की भी अनुमति दी जाए!), इसलिए आपको यह याददाश्त से अधिक लचीला संसाधन लग सकता है। आपके कार्यभार या हार्डवेयर / वर्चुअलाइजेशन कॉन्फ़िगरेशन के बारे में अधिक जानकारी के बिना, मैं कहूंगा कि इसे बढ़ाकर 4 करना अच्छा होगा।
स्मृति आवंटन। ओह यार। यह वर्कलोड के लिए मोटे तौर पर कम-प्रावधान है। खुश रहने के लिए विंडोज को नंगे न्यूनतम 2-3 जीबी की आवश्यकता होती है, और बॉक्स पर BIDS चलाने वाले 2 उपयोगकर्ताओं में से प्रत्येक को कम से कम 500 एमबी की आवश्यकता होगी। और इसके साथ, बॉक्स को पहले से ही अधिकतम किया गया है, और मुझे यह पता लगाना भी शुरू नहीं हुआ कि डेटाबेस को कितनी ज़रूरत है।
अधिकांश उपयोगकर्ता asp.net वेबसाइट और रिपोर्ट सर्वर वेबसाइट के माध्यम से डेटाबेस के साथ बातचीत करते हैं।
आपने कहा नहीं, लेकिन अगर ये एक ही बॉक्स पर चल रहे हैं, तो उनके लिए मेमोरी आवश्यकताओं को भी ध्यान में रखा जाना चाहिए।
अंत में, हमारे पास एक काफी डेटा स्टोरेज ऑपरेशन है जो शायद एसएसआईएस पैकेज के माध्यम से प्रति दिन 3 मिलियन रिकॉर्ड लाता है जो सर्वर पर भी चलता है।
यह मानते हुए कि यह रात में चलता है जब सिस्टम पर कोई लाइव उपयोगकर्ता नहीं होते हैं, मैं इसे एक समस्या के रूप में नहीं देखता जब तक कि इसे चलाने में बहुत समय नहीं लगता। चीजों का यह हिस्सा आपकी चिंताओं का कम से कम है; लाइव उपयोगकर्ता अधिक महत्वपूर्ण हैं।
अतिरिक्त मेमोरी के लिए हमारे पिछले अनुरोधों को आम प्रतिक्रिया से इनकार कर दिया गया है कि हमें अधिक क्वेरी अनुकूलन करने की आवश्यकता है।
जैसा कि मैंने ऊपर दर्शाया है, जिस मेमोरी की प्रावधान किया गया है वह पूरी तरह से अपर्याप्त है। एक ही समय में, हालांकि, स्पेक्ट्रम के दूसरे छोर पर, यह अत्यधिक संभावना नहीं है कि आप पर्याप्त मेमोरी प्राप्त करने में सक्षम होंगे, जो पूरे डेटाबेस को एक बार में याद रखने में सक्षम हो ।
भले ही आपको इस तरह की प्रतिक्रिया मिली (जो, वैसे, संभवतः अतिरिक्त संसाधनों के लिए आपका औचित्य कितना प्रेरक था, और वास्तविक संसाधन उपयोग खुद के लिए नहीं था ), यह बहुत संभावना है कि डेटाबेस की दक्षता हो सकती है सुधार हुआ। अभी तक अकेले ट्यूनिंग की कोई राशि नहीं है जो उन मुद्दों को ठीक कर सकती है जो आप अभी अनुभव कर रहे हैं; उस का सुझाव मेरे लिए एक पूर्ण गैर-स्टार्टर है।
मैं समग्र दृष्टिकोण लूंगा कि वर्तमान में प्रावधान की गई मेमोरी की मात्रा न्यूनतम आवश्यक से कम है (जिसे एएसएपी को ठीक किया जाना चाहिए), और उपयोगकर्ता के अनुभव को एक उपयोगी स्तर तक सुधारने के लिए अतिरिक्त संसाधनों की आवश्यकता हो सकती है जबकि सुधार दक्षता बढ़ाने के लिए किए जाते हैं। सिस्टम।
यहाँ कुछ विचार हैं (हमले के क्रम में):
आप जीतेंगे अगर आप साबित कर सकते हैं कि हर बार जब आप अधिक संसाधनों का प्रावधान करते हैं तो प्रदर्शन कितना बेहतर होता है। प्रदर्शन मॉनिटर लॉगिंग (नोट: लॉगिंग भाग बहुत महत्वपूर्ण है) का उपयोग करते हुए प्रदर्शन मीट्रिक पर नज़र रखें , यदि आप कर सकते हैं तो वेबसाइट प्रतिक्रिया समय सहित। कुछ भी करने से पहले, अब ऐसा करना शुरू करें । जब आप अंत में न्यूनतम मात्रा में मेमोरी प्राप्त करते हैं (आप अभी तक 32 जीबी प्राप्त नहीं कर रहे हैं), तो अचानक आपके पास अब इस बात के सबूत हैं कि जोड़ा गया मेमोरी में सुधार हुआ है ... जिसका अर्थ है कि और भी अधिक जोड़ने में मदद मिलेगी! यदि आप वर्तमान कॉन्फ़िगरेशन पर एक आधार रेखा एकत्र नहीं करते हैं, तो आप नाव को याद करने जा रहे हैं जब चीजें न्यूनतम अनुशंसित स्तर तक टकरा जाती हैं।
अपने सर्वर के प्रतीक्षा आंकड़ों का विश्लेषण करें । यह आपको बताएगा कि सिस्टम में सबसे बड़ी अड़चन क्या है। आपके पास शायद PAGEIOLATCH_XXसबसे आम / उच्चतम प्रतीक्षा समय होगा, जो इंगित करता है कि डिस्क से पृष्ठों को लाने के लिए I / O बहुत अधिक किया जा रहा है। यह स्मृति को जोड़कर कम किया जा सकता है, इसलिए भौतिक I / O कम लगातार हो जाते हैं क्योंकि आवश्यक डेटा पहले से ही स्मृति में है। हालांकि यह विश्लेषण बहुत अधिक निष्कर्ष निकाला गया है, जिस तथ्य को आपने इन आँकड़ों को इकट्ठा किया है वह संसाधनों की आवश्यकता को उचित ठहराते हुए आपको अधिक बारूद देता है।
जैसा कि मैंने ऊपर उल्लेख किया है, स्मृति के लिए नंगे न्यूनतम आवश्यकता को पूरा नहीं किया जा रहा है। आपके द्वारा चलाए जा रहे सभी सॉफ़्टवेयरों के लिए अनुशंसित हार्डवेयर आवश्यकताओं के सेट को इकट्ठा करें , और शायद टास्क मैनेजर के स्क्रीनशॉट को भी पकड़ो। यह अकेले मौके पर कम से कम 4-8 जीबी अधिक का औचित्य साबित करने के लिए पर्याप्त होना चाहिए। यदि वे अभी भी मना करते हैं, तो उन्हें एक सप्ताह के लिए इसे आज़माने की अनुमति देने के लिए उन्हें समझाने की कोशिश करें, और इसके बाद उसे वापस दें (आप प्रदर्शन आँकड़े एकत्र कर रहे हैं, इसलिए आपको इसे वापस देने की आवश्यकता नहीं होगी क्योंकि मध्य सप्ताह में आप ' यह साबित करने में सक्षम हो जाएगा कि स्थिति में कितना सुधार हुआ है)। यदि वे अभी भी मना करते हैं, तो आपको असफल होने के लिए सेट किया जा रहा है; URLT ।
यदि आप कुछ वर्कलोड को बंद कर सकते हैं (विशेष रूप से, यदि संभव हो तो उसे हटाने से बचें), इससे डेटाबेस के लिए उपलब्ध मेमोरी की मात्रा बढ़ जाएगी, जो अधिक महत्वपूर्ण है।
आप एक ही बार में पूरे डेटाबेस को मेमोरी में फिट नहीं कर पाएंगे, जिसका मतलब है कि आपको मेमोरी को कम करने के लिए SQL सर्वर की अधिकतम मेमोरी सेटिंग को बहुत सावधानी से सेट करने की आवश्यकता है , जो प्रदर्शन को कुछ और नहीं की तरह मारता है । ओवर-कमिट वास्तव में स्मृति में सभी डेटा को फिट करने में सक्षम नहीं होने से भी बदतर है। यह अत्यधिक संभावना है कि आप अभी इस परिदृश्य में हैं, क्योंकि अभी कोई मेमोरी उपलब्ध नहीं है, और यह संभव है कि अधिकतम मेमोरी सेटिंग डिफ़ॉल्ट (असीमित) पर सेट हो।
चूँकि आप SQL सर्वर एंटरप्राइज़ संस्करण चला रहे हैं, और मेमोरी प्रीमियम पर है, इसलिए मैं दृढ़ता से डेटा कम्प्रेशन को लागू करने पर विचार करूँगा । यह मेमोरी की अंतरिक्ष-बचत के लिए सीपीयू उपयोग में वृद्धि का व्यापार करेगा (और इसलिए डिस्क एक्सेस कम हो जाता है, जो तुलनात्मक रूप से बहुत धीमा है)।
डेटाबेस ट्यून करें। यह संभव है कि संरचनाओं और प्रश्नों में सुधार हो सकता है जहां तक अनुक्रमण और पहुंच पैटर्न चलते हैं। इसके अलावा, यदि बहुत सारे डेटा को अक्सर स्कैन और एकत्र किया जा रहा है, तो अनुक्रमित विचार, सारांश तालिका या पूर्व-निर्मित रिपोर्ट बनाना बहुत सहायक हो सकता है।
यह एक लॉन्गशॉट हो सकता है क्योंकि इसका मतलब शायद अधिक हार्डवेयर प्रोविजनिंग है, लेकिन कैशिंग समाधान को लागू करना। सबसे तेज़ क्वेरी वह है जिसे आप कभी नहीं बनाते हैं ।
वे केवल कुछ विचार हैं। लब्बोलुआब यह है कि अकेले ट्यूनिंग न तो यहां की समस्याओं को हल करेगा, न ही अकेले हार्डवेयर करेगा, हालांकि बाद वाला शायद तत्काल मुद्दों के बहुमत को कम कर देगा। यह वास्तव में यह कैसे होता है: आग को बाहर निकालने के लिए शॉर्ट-टर्म में समस्या पर हार्डवेयर फेंकें, और मूल कारण को ठीक करने के लिए दीर्घकालिक में समस्या पर ट्यूनिंग फेंकें जितना आप कर सकते हैं।