अधिक सीपीयू कोर बनाम तेज डिस्क


13

मैं एक छोटी सी कंपनी का हिस्सा हूं इसलिए हमेशा की तरह विभिन्न भूमिकाओं को कवर करता हूं। जिनमें से नवीनतम हमारे .NET वेब ऐप के लिए एक समर्पित SQL सर्वर बॉक्स खरीद रहा है। हमें 32 जीबी रैम के साथ एक दोहरी एक्सोन E5-2620 (छह कोर) 2.00 गीगाहर्ट्ज सीपीयू कॉन्फ़िगरेशन (कुल 12 कोर) पर उद्धृत किया गया है। इसने हमें डिस्क सरणी के लिए एक सीमित बजट के साथ छोड़ दिया है, जिसमें अनिवार्य रूप से एक RAID 1 विन्यास में दो 2.5 "SAS 300 GB ड्राइव (15k RPM) शामिल होगा।

मुझे पता है कि डिस्क सेटअप SQL सर्वर के लिए उप-इष्टतम है और मैं वास्तव में RAID 10 के लिए धक्का देना चाहूंगा ताकि हम अपने स्वयं के ड्राइव पर डेटाबेस, लॉग फाइल और टेम्पर्डब को डाल सकें। अपने बजट के साथ इसे संगत बनाने के लिए मुझे सीपीयू कोर की संख्या को कम करने पर विचार करना चाहिए? या क्या मुझे कोर रखने और कम ड्राइव का उपयोग करने वाले हिरन के लिए बेहतर बैंक मिलेगा, शायद 4 एक दोहरी में RAID 1 सेटअप?

यहाँ कुछ अतिरिक्त आँकड़े दिए गए हैं

  • SQL सर्वर डेटाबेस को लिखने की उच्च संख्या की ओर झुकाया जाता है, शायद क्रमशः 80% बनाम 20%। वर्तमान डीबी का आकार वर्तमान में लगभग 10 जीबी 26 जीबी है, जो प्रति माह 250 एमबी की दर से बढ़ रहा है।

  • वर्तमान में SQL Server 2008 R2 मानक पर चल रहे एक एकल क्वाड कोर Xeon बॉक्स पर वेब सर्वर (12 GB Ram, 2 x 10k 300GB SAS ड्राइव में RAID 1) के साथ साझा किया गया है, SQL Server 2012 मानक पर जाने के लिए देख रहा है।

  • डेटाबेस लगभग 100-150 समवर्ती उपयोगकर्ताओं को कुछ पृष्ठभूमि शेड्यूलिंग कार्यों के साथ कार्य करता है, जिसमें इसे पढ़ना है। मैं सोच रहा हूं कि 12 कोर गंभीर ओवरकिल हैं!


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

मैंने शुरू में लाइसेंसिंग की लागतों को अनदेखा किया और यह महसूस नहीं किया कि SQL सर्वर 2012 लाइसेंसिंग कोर की संख्या पर आधारित है। मेरे पास SQL ​​Server 2012 मानक लाइसेंस के साथ एक BizSpark MSDN सदस्यता है, इसलिए मुझे इस बारे में पढ़ने की आवश्यकता होगी कि यह कितने कोर बॉक्स से बाहर निकलेगा।


7
10GB? तेज़ डिस्क आपकी बहुत मदद करने वाली नहीं हैं। आपके सभी डेटा लगभग हमेशा मेमोरी में होना चाहिए ... यह भी कितना अधिक होगा RAID 10 वास्तव में आपकी लागत है? और SQL सर्वर का संस्करण / संस्करण क्या है? मुझे संदेह है कि सॉफ्टवेयर लाइसेंस आसानी से 10-20x हार्डवेयर लागत होगा।
हारून बर्ट्रेंड

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

4
SSD खरीदने पर विचार करें। क्षमा करें, लेकिन 15k SAS की कीमत एक SSD को एक बेहतर प्रस्ताव बनाती है। वास्तव में, मैं अब इसी तरह की जगह पर हूं, और मैं 450G 10k एसएएस ड्राइव और एक 500G एसएसडी (प्रतिबिंबित) के साथ 300G 10k वेलसिराप्टर्स को प्रतिस्थापित करता हूं। 15k एसएएस ड्राइव का मूल्य / लाभ मुझे संकटग्रस्त बनाता है।
टॉमॉम

4
@ टोमटॉम सहमत हुआ। 15K एसएएस 1972 डैटसन के लिए ईंधन योज्य की तरह है - हाँ यह थोड़ा बेहतर होगा, लेकिन अंतर नगण्य है, और एसएसडी की अतिरिक्त लागत इसके लायक से अधिक होगी।
हारून बर्ट्रेंड

जवाबों:


10

अनुभव से बोलना जो विनम्र है लेकिन मुझे लगता है कि शेयर करने लायक है, SQL डेटाबेस (Sybase और SQL सर्वर) के साथ प्रमुख अड़चन भंडारण है।

लेकिन मुझे लगता है कि यह केवल उचित है कि कोई भी गलत धारणा बनाने से पहले अपने सेटअप को बेंचमार्क करता है। मेरे मामले में, सीपीयू का उपयोग कभी भी उच्च नहीं हुआ है जो कि जल्द ही किसी भी समय सीपीयू को अपग्रेड करने का औचित्य साबित कर सकता है। इसके बजाय, मैंने सिंगल ड्राइव से RAID 1 में अपग्रेड किया है और फिर RAID 10 + में 8GB से 16GB RAM तक की टक्कर दी है।

इन सभी RAID अपग्रेड ने 2 से 6 के कारक द्वारा पिछले प्रतीक्षा समय को कम करने में मदद की। मुझे संदेह है कि SSDs में अपग्रेड करना बेहतर होगा। यदि आप इसके बारे में सोचते हैं, तो यह सभी (सैद्धांतिक) बैंडविड्थ तक कम हो सकता है। CPU के लिए आपकी [(RAM Speed ​​+ RAM Size + मेमोरी कंट्रोलर) लिंक] कॉम्बो की एक बैंडविड्थ सीमा होती है जो रीड ऑपरेशंस में सबसे महत्वपूर्ण कारक होगा जब आपका डेटा हमेशा कैश्ड होना चाहिए, आपके विशेष (RAID) स्टोरेज की बैंडविड्थ सीमा होती है ( प्रभावित करता है जब कैश मिस हो जाता है और जब फ्लशिंग या कई क्लाइंट संयुक्त डेटा लिखने के साथ लिखते हैं)।

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

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

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

5 से अधिक सर्वरों पर अधिक व्यापक उन्नयन के बाद, मैं अपना अनुभव साझा करने के लिए वापस आया। मैं निश्चित रूप से अभी भी पहले उन्नयन भंडारण, फिर रैम और फिर सीपीयू की वकालत करता हूं। कारण सबसे कम के क्रम में भंडारण, रैम और सीपीयू के बीच प्रणाली में बैंडविद की असमानता है। इसलिए मैंने SS10 के लिए RAID10 और दोहरे RAID1s से सर्वर का एक गुच्छा अपग्रेड किया।

जिस तरह से मैंने लागत की चिंताओं के कारण इसे किया (मेरे पास 20 और सर्वर हैं अपग्रेड करने के लिए) डेटाबेस डेटा और ऑब्जेक्ट्स फ़ाइलों को SSD (हाँ, RAID0 में सिर्फ एक SSD) को स्थानांतरित करने के लिए है और लेनदेन लॉग प्लस tempdb को 4xDD RAID10 में ले जाना है। विन्यास। मैंने एसएसडी पर टेम्पर्डब के साथ-साथ महान परिणामों के साथ परीक्षण किया (वास्तव में 15 गुना से अधिक तेज प्रश्नों के साथ बहुत अच्छे परिणाम कभी-कभी, कुछ रिपोर्टों को अतीत में मिनटों के बजाय सेकंड में ले जाते हैं) लेकिन बाद में टेम्पर्ड को डिस्क RAID10 में स्थानांतरित कर दिया क्योंकि SSD के लिए गहन लेखन-वस्त्र संबंधी चिंताएँ।

इसलिए अब मूल रूप से मैंने कुछ सबसे लंबे प्रश्नों के प्रति 10-15 गुना तेजी से प्रतिक्रिया समय देखा है। SSD रैम में डेटा को तेजी से पढ़ने के लिए बहुत अच्छा है क्योंकि SQL सर्वर रैम में डेटा तब तक नहीं लाता है जब तक कि और निश्चित रूप से डेटा को सीपीयू द्वारा संसाधित करने के लिए पहले रैम में लोड करने की आवश्यकता होती है (बाद में, L1, L2, L3 कैश में) , इसलिए SSDs एक विशाल कारक द्वारा उस प्रारंभिक प्रतीक्षा समय को कम करने में मदद करते हैं। और SSDs भी स्वैपिंग समय को कम करने में मदद करते हैं ... रैम को साफ़ करना और नए डेटा को लोड करना, खासकर अगर आपका डेटाबेस रैम में फिट हो सकता है।

सब सब में, हम बहुत खुश हैं और सर्वरों को चलाने की अनुमति देने के लिए धीमी गति से माइग्रेशन की प्रक्रिया में कई महीनों से ऐसा ही चल रहा है ताकि मैं अपने सभी सर्वर को इस कॉन्फ़िगरेशन पर स्विच करने से पहले पहनने के स्तर की जानकारी एकत्र कर सकूं। और यह सिर्फ SQL Server Express है! : D - बस यह सुनिश्चित करें कि आपके SSDs निरंतर IOPS प्रदान कर सकते हैं क्योंकि यह एक और बात है जो बहुत बड़ा अंतर बनाती है (बस इसे google करें)। इसलिए मैंने Intel DC (DataCenter) श्रृंखला SSD को चुना।


0

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

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

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


1
यार, क्या तुमने कभी उस के COST को देखा है? जब आप 24/7 चलाते हैं, तो क्लॉट के लिए प्रति घंटा की दर बीमा होती है। बड़े डेटा और डाउनलोड करने के लिए बैंडविड्थ पागल हैं। 1gbit के लिए लागत - 10gbit से बात भी नहीं कर रही है - इंटरनेट से एक तुलनीय लिंक है जब आपको 50gb डेटा को डेटाबेस में और बाहर स्थानांतरित करने की आवश्यकता होती है। यदि आप (क) स्थानीय से डेटाबेस का उपयोग नहीं करते हैं, तो यह क्लाउड अच्छा और बांका है - अर्थात यह क्लाउड में रहता है या (बी) छोटा है।
टॉमटॉम

हां, मैं सार्वजनिक क्लाउड रूट से नीचे आ गया हूं, मैं वास्तव में बहुत लंबा रास्ता तय कर रहा हूं! प्रदर्शन औसत दर्जे का था, जैसा कि आप उम्मीद करेंगे .. लेकिन लागत के लिए यह मेरे लिए स्विंग नहीं करता है। मैं सभी स्केल-आउट पैटर्न विकसित करने के लिए हूं, लेकिन Colo सस्ता है और आपको किसी भी लोकप्रिय क्लाउड विक्रेताओं के साथ पास होने के लिए एक टन पैसा खर्च करना होगा। यकीन है कि यह बुनियादी ढांचे को खत्म कर देता है, लेकिन जब आप हार्डवेयर को बनाए रखने की लागतों को जोड़ते हैं तो भी यह एक मुश्किल बिक्री बनी रहती है।
QFDev
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.