बर्स्ट उपयोग के लिए IO आवश्यकताएँ का अनुमान लगाना


11

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

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

मैं ऐसी प्रणाली के लिए IO आवश्यकताओं का अनुमान कैसे लगा सकता हूं? क्या व्यक्तिगत, फालतू प्रश्नों से निपटने के लिए डिस्क कतार की लंबाई एक विश्वसनीय संकेतक है? क्या अन्य मीट्रिक हैं जिन पर मुझे विचार करना चाहिए?


क्या कोई लेखन चल रहा है, या यह भारी-भरकम है?
जैक का कहना है कि topanswers.xyz

@JackDouglas: यह 98% रीड है। लिखने की एक चाल है।
एरिक जे।

1
अगला सवाल: क्या रीड बिखरे हुए हैं या आपके "अपेक्षाकृत बड़ी मात्रा में डेटा के लिए व्यक्तिगत अनुरोध" क्रमिक आईओ होने की संभावना है?
जैक का कहना है कि topanswers.xyz

@JackDouglas: सबसे बड़ी रीड्स एक अनुक्रमित दृश्य के माध्यम से होती हैं, जैसे कि WHERE क्लॉज़ इंडेक्स से मेल खाती है, लेकिन इंडेक्स में जो है उससे अधिक डेटा वापस करना। मुझे यकीन नहीं है कि अनुक्रमिक IO की डिग्री के लिए इसका क्या मतलब है। चूंकि अंतर्निहित IO उपतंत्र AWS EBS है, इसलिए मुझे यकीन नहीं है कि यह भौतिक पहुंच को कैसे प्रभावित करता है।
एरिक जे।

अंतर्निहित IO सबसिस्टम प्रदर्शन की स्थिरता को प्रभावित करेगा , लेकिन स्थानीय भंडारण के समान तरीके से बिखरे हुए v क्रमिक पहुंच के बारे में परवाह करेगा। जो बड़े पढ़ते हैं, वे आम तौर पर कितने अलग-अलग ब्लॉक करते हैं? अनुक्रमणिका स्कैन स्वयं अनुक्रमिक होगा लेकिन टेबल एक्सेस नहीं होगा यदि मैंने आपको अभी तक सही ढंग से समझा है।
जैक का कहना है कि topanswers.xyz

जवाबों:


10

प्राथमिक मीट्रिक जिसे मैंने हमेशा SQL सर्वर में IO के लिए माना है IOP या डिस्क कतार लंबाई नहीं है, लेकिन डिस्क थ्रूपुट (सेकंड / रीड और सेकंड / राइट्स)। कुल मिलाकर, डेटाबेस इस बारे में नहीं हैं कि आप डिस्क पर कितने ऑपरेशन फेंक सकते हैं, लेकिन कितनी जल्दी वे ऑपरेशन पूरे हो जाते हैं। अंगूठे का सामान्य नियम 20ms / ऑपरेशन से कम है (हालांकि कम हमेशा बेहतर होता है)। इस लेख में और अधिक विवरण पाया जा सकता है ।

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

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

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

मेरी सिफारिश होगी कि अधिक से अधिक मेमोरी आवंटित की जाए। बफ़र पूल (LRU-K पर आधारित) में दबाव और स्थान में होने पर SQL सर्वर केवल मेमोरी से सामान बाहर धकेल देगा। इसलिए यदि आप बफर पूल में अधिकांश डेटाबेस को मेमोरी में स्टोर कर सकते हैं, तो आप कुछ धमाकेदार प्रदर्शन को कम कर सकते हैं। इसके अलावा, उन विचारों पर विचार करें जो कैश ऑब्जेक्ट्स को "गर्म" रख सकते हैं। अंत में, SQL 2014 और नई हेकोटन सुविधा पर नज़र रखें ।


"SQL सर्वर केवल मेमोरी से सामान बाहर धक्का देगा अगर यह दबाव में है" या एक चेकपॉइंट पर ?
जैक कहते हैं कि

5
चेकपॉइंट बफर से ऑब्जेक्ट्स को नहीं हटाता है, लेकिन रिकवरी के लिए डिस्क पर गंदे पेज लिखता है। यह अभी भी बफर पूल में वस्तुओं को बनाए रखेगा।
माइक फाल

विस्तृत उत्तर के लिए धन्यवाद। AWS में अब एक प्रीमियम सुविधा है, जिसे Provisioned IOPS कहा जाता है जो सुनिश्चित करता है कि प्रति सेकंड IO परिचालनों की खरीदी गई संख्या को 99.9% समय पर प्रदर्शित किया जा सकता है। मुझे लगता है कि एक IO ऑपरेशन को डेटा के 16K ब्लॉक को पढ़ने या लिखने के रूप में परिभाषित किया गया है।
एरिक जे।

@ माइकफाल: क्या आपके पास विशेष रूप से इस फटने वाले पैटर्न के लिए परीक्षण पद्धति पर कोई विचार है? केवल एक ही क्वेरी चलाएँ और काउंटर को प्रश्न में देखें? काउंटरों को देखते हुए एक के बाद एक (सामान्य रूप से आवधिक) प्रश्नों की संख्या चलाएं?
एरिक जे।

हाँ, मैं PIOPS से परिचित हूँ। राज्य के रूप में, मैं यह नहीं जानना चाहता कि कितने ऑपरेशन किए जा सकते हैं, मैं यह जानना चाहता हूं कि वे कितने तेज हैं। और यह कोई ऐसी चीज नहीं है जिसकी गारंटी PWSP पर भी AWS द्वारा दी जा सकती है।
माइक फाल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.