आखिर डीटीयू क्या है?

अतिथि लेखक:एंडी मॉलन (@AMtwo)

नहीं, गंभीरता से। डीटीयू क्या है?

जब आप कोई एप्लिकेशन परिनियोजित कर रहे होते हैं, तो सबसे पहले जो प्रश्न सामने आता है, वह है "इसकी कीमत क्या होगी?" हम में से अधिकांश लोग किसी समय SQL सर्वर स्थापना को आकार देने के लिए इस तरह के अभ्यास से गुज़रे हैं, लेकिन क्या होगा यदि आप क्लाउड पर परिनियोजित कर रहे हैं? Azure IaaS परिनियोजन के साथ, बहुत कुछ नहीं बदला है-आप अभी भी CPU गणना, कुछ मात्रा में मेमोरी के आधार पर एक सर्वर बना रहे हैं, और आपको अपने कार्यभार के लिए पर्याप्त IOPS देने के लिए स्टोरेज को कॉन्फ़िगर कर रहे हैं। हालाँकि, जब आप Paa पर कूदते हैं, तो Azure SQL डेटाबेस का आकार विभिन्न सेवा स्तरों के साथ होता है, जहाँ प्रदर्शन को DTU में मापा जाता है। DTU क्या होता है?

मुझे पता है कि बीटीयू क्या है। शायद DTU का मतलब डेटाबेस थर्मल यूनिट है? क्या यह डाटा सेंटर के तापमान को एक डिग्री बढ़ाने के लिए आवश्यक प्रसंस्करण शक्ति की मात्रा है? अनुमान लगाने के बजाय, आइए दस्तावेज़ीकरण देखें, और देखें कि Microsoft का क्या कहना है:

ए [डेटाबेस ट्रांजेक्शन यूनिट] सीपीयू, मेमोरी और डेटा I/O और ट्रांजेक्शन लॉग I/O का एक मिश्रित माप है, जो वास्तविक दुनिया के OLTP वर्कलोड के विशिष्ट होने के लिए डिज़ाइन किए गए OLTP बेंचमार्क वर्कलोड द्वारा निर्धारित अनुपात में होता है। डेटाबेस के प्रदर्शन स्तर को बढ़ाकर DTU को दोगुना करना उस डेटाबेस के लिए उपलब्ध संसाधन के सेट को दोगुना करने के बराबर है।

ठीक है, यह मेरा दूसरा अनुमान था-लेकिन "मिश्रित माप" क्या है? मैं सर्वर को आकार देने के बारे में जो कुछ जानता हूं उसका अनुवाद Azure SQL डेटाबेस में कैसे कर सकता हूं? दुर्भाग्य से, "2 CPU कोर, और 4GB मेमोरी" को DTU माप में अनुवाद करने का कोई सीधा तरीका नहीं है।

क्या कोई DTU कैलकुलेटर नहीं है?

हां! माइक्रोसॉफ्ट हमें अनुमान . के लिए एक डीटीयू कैलकुलेटर देता है Azure SQL डेटाबेस का उचित सेवा स्तर। इसका उपयोग करने के लिए, आप SQL सर्वर में वर्कलोड चलाते समय सर्वर पर पावरशेल स्क्रिप्ट (sql-perfmon.ps1) डाउनलोड और चलाते हैं। स्क्रिप्ट एक CSV को आउटपुट करती है जिसमें चार परफ़ॉर्म काउंटर होते हैं:(1) कुल% प्रोसेसर समय, (2) कुल डिस्क रीड/सेकंड, (3) कुल डिस्क प्रति सेकंड लिखता है, और (4) कुल लॉग बाइट्स फ्लश/सेकंड। यह सीएसवी आउटपुट तब डीटीयू कैलकुलेटर पर अपलोड किया जाता है, जो अनुमान लगाता है कि कौन सा सेवा स्तर आपकी आवश्यकताओं को सर्वोत्तम रूप से पूरा करेगा। सीएसवी के अलावा डीटीयू कैलकुलेटर जो एकमात्र डेटा लेता है वह सर्वर पर सीपीयू कोर की संख्या है जो फ़ाइल उत्पन्न करता है। DTU कैलक्यूलेटर अभी भी एक ब्लैक बॉक्स है-जो हम अपने ऑन-प्रिमाइसेस डेटाबेस से जानते हैं उसे Azure में मैप करना आसान नहीं है।

मैं यह बताना चाहता हूं कि DTU की परिभाषा यह है कि यह "CPU का एक मिश्रित माप है, मेमोरी , और डेटा I/O और लेन-देन लॉग I/O…" DTU कैलकुलेटर द्वारा उपयोग किए जाने वाले परफ़ॉर्मेंस काउंटरों में से कोई भी मेमोरी को ध्यान में नहीं रखता है, लेकिन यह गणना के हिस्से के रूप में परिभाषा में स्पष्ट रूप से सूचीबद्ध है। यह जरूरी नहीं है समस्या है, लेकिन यह सबूत है कि डीटीयू कैलकुलेटर सही नहीं होगा।

मैं डीटीयू कैलकुलेटर में कुछ सिंथेटिक लोड अपलोड करूंगा, और देखूंगा कि क्या मैं यह पता लगा सकता हूं कि ब्लैक बॉक्स कैसे काम करता है। वास्तव में, मैं पूरी तरह से सीएसवी तैयार करूंगा ताकि मैं डीटीयू कैलकुलेटर में लोड किए गए परफॉर्म नंबरों को पूरी तरह से नियंत्रित कर सकूं। आइए एक बार में एक मीट्रिक के माध्यम से आगे बढ़ें। प्रत्येक मीट्रिक के लिए, हम 25 मिनट (1500 सेकंड-मुझे गोल संख्याएँ पसंद हैं) का फ़ैब्रिकेटेड डेटा अपलोड करेंगे, और देखेंगे कि कैसे उस परफ़ॉर्म डेटा को DTU में परिवर्तित किया जाता है।

सीपीयू

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

मैं एक CSV फ़ाइल बनाउंगा जिसमें प्रति सेकंड एक पंक्ति होगी, और हर 94 सेकंड में, मैं कुल% प्रोसेसर समय काउंटर को ~ 6% बढ़ा दूंगा। अन्य तीन काउंटर सभी मामलों में शून्य होंगे। अब, मैं इस फ़ाइल को डीटीयू कैलकुलेटर पर अपलोड करता हूं (और डीटीयू कैलकुलेटर को 16 कोर पर विचार करने के लिए कहता हूं), और यहां आउटपुट है:

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

<थ>डीटीयू <थ>सर्विस टियर

संख्या कोर
1	100	मानक - S3
2-4	500	प्रीमियम - P4
5-8	1000	प्रीमियम - P6
9-13	1750	प्रीमियम - P11
14-16	4000	प्रीमियम - P15

इस डेटा को देखकर हमें कुछ बातें पता चलती हैं:

एक सीपीयू कोर, 100% उपयोग किया गया 100 डीटीयू के बराबर है।
DTU थोड़े में वृद्धि करते हैं सीपीयू बढ़ने के साथ रैखिक रूप से, लेकिन फिट और स्पर्ट में प्रतीत होता है।
बेसिक और स्टैंडर्ड सर्विस टियर सिंगल सीपीयू कोर से कम के बराबर होते हैं।
कोई भी मल्टी-कोर सर्वर प्रीमियम सर्विस टियर के भीतर कुछ आकार में अनुवाद करेगा।

पढ़ता है

इस बार, मैं उसी पद्धति का उपयोग करने जा रहा हूं। मैं रीड/सेकंड काउंटर के लिए बढ़ती संख्या के साथ एक सीएसवी उत्पन्न करूंगा, अन्य परफॉर्म काउंटर शून्य पर। मैं समय के साथ धीरे-धीरे संख्या बढ़ाऊंगा। इस बार, हम 30000 तक पहुंचने तक, हर 100 सेकंड में 2000 की मात्रा में कदम बढ़ाते हैं। यह हमें कुल 25 मिनट का कुल समय देता है-हालाँकि, इस बार मेरे पास 16 के बजाय 15 कदम हैं। (मुझे गोल संख्याएँ पसंद हैं।)

जब हम इस CSV को DTU कैलकुलेटर पर अपलोड करते हैं, तो यह हमें यह DTU ग्राफ देता है:

एक सेकंड रुकिए... यह पहले ग्राफ़ के समान ही सुंदर दिखता है। फिर से, यह 5 असमान वेतन वृद्धि में आगे बढ़ रहा है, भले ही मेरी फ़ाइल में 15 चरण भी थे। आइए इसे एक सारणीबद्ध प्रारूप में देखें:

<थ>डीटीयू <थ>सर्विस टियर

पढ़ें/सेकंड
2000	250	प्रीमियम - P2
4000-6000	500	प्रीमियम - P4
8000-12000	1000	प्रीमियम - P6
14000-22000	1750	प्रीमियम - P11
24000-30000	4000	प्रीमियम - P15

फिर से, हम देखते हैं कि बुनियादी और मानक स्तर बहुत तेज़ी से आगे बढ़ते हैं (2000 से कम/सेकंड से कम), लेकिन फिर प्रीमियम स्तर बहुत चौड़ा होता है, जो 2000 से 30000 प्रति सेकंड तक फैला होता है। उपरोक्त तालिका में, "रीड्स/सेकंड" को शायद "आईओपीएस" के रूप में माना जा सकता है ... या, तकनीकी रूप से, केवल "ओपीएस" क्योंकि आईओपीएस के "इनपुट" भाग का गठन करने के लिए कोई लेखन नहीं है।

लिखता है

यदि हम उसी फॉर्मूले का उपयोग करके एक CSV बनाते हैं जिसका उपयोग हमने Reads के लिए किया था, और उस CSV को DTU कैलकुलेटर पर अपलोड करते हैं, तो हमें एक ऐसा ग्राफ़ मिलेगा जो रीड्स के लिए ग्राफ़ के समान होगा:

IOPS IOPS हैं, इसलिए चाहे वह पढ़ना हो या लिखना, ऐसा लगता है कि DTU गणना इसे समान रूप से मानती है। पढ़ने के बारे में हम जो कुछ भी जानते हैं (या सोचते हैं कि हम जानते हैं) लिखने के लिए समान रूप से लागू होते हैं।

लॉग बाइट फ्लश किया गया

हम अंतिम परफ़ॉर्मन काउंटर तक हैं:लॉग बाइट्स प्रति सेकंड फ़्लश किए जाते हैं। यह आईओ का एक और उपाय है, लेकिन SQL सर्वर लेनदेन लॉग के लिए विशिष्ट है। यदि आपने अब तक नहीं पकड़ा है, तो मैं इन CSV को बना रहा हूं ताकि उच्च मानों की गणना P15 Azure DB के रूप में की जाए, फिर मान को समान चरणों में विभाजित करने के लिए बस विभाजित किया जाए। इस बार, हम 5 मिलियन के चरणों में, 5 मिलियन से 75 मिलियन करने जा रहे हैं। जैसा कि हमने सभी पूर्व परीक्षणों में किया था, अन्य परफ़ॉर्मेंस काउंटर शून्य होंगे। चूंकि यह परफ़ॉर्मन काउंटर बाइट प्रति सेकंड में है, और हम लाखों में माप रहे हैं, हम इस बारे में उस इकाई में सोच सकते हैं जिसमें हम अधिक सहज हैं:मेगाबाइट प्रति सेकंड।

हम इस सीएसवी को डीटीयू कैलकुलेटर पर अपलोड करते हैं, और हमें निम्न ग्राफ मिलता है:

<थ>डीटीयू <थ>सर्विस टियर

लॉग मेगाबाइट फ्लश/सेकंड
5	250	प्रीमियम - P2
10	500	प्रीमियम - P4
15-25	1000	प्रीमियम - P6
30-40	1750	प्रीमियम - P11
45-75	4000	प्रीमियम - P15

इस ग्राफ़ का आकार काफी अनुमानित होता जा रहा है। इस समय को छोड़कर, हम स्तरों के माध्यम से थोड़ा तेजी से कदम बढ़ाते हैं, केवल 8 चरणों के बाद P15 को मारते हैं (आईओ के लिए 11 और सीपीयू के लिए 12 की तुलना में)। यह आपको सोचने के लिए प्रेरित कर सकता है, "यह मेरी सबसे छोटी बाधा होगी!" लेकिन मुझे इस पर इतना यकीन नहीं होगा। आप कितनी बार 75MB लॉग एक सेकंड में generating उत्पन्न कर रहे हैं ? यानी 4.5GB प्रति मिनट . यह बहुत सारी डेटाबेस गतिविधि है। मेरा सिंथेटिक वर्कलोड जरूरी नहीं कि वास्तविक वर्कलोड हो।

सब कुछ मिलाना

ठीक है, अब जब हमने देखा है कि कुछ ऊपरी सीमाएं अलगाव में हैं, तो मैं डेटा को संयोजित करने जा रहा हूं और देखता हूं कि वे तुलना कैसे करते हैं जब सीपीयू, आई/ओ, और लेनदेन लॉग आईओ सभी एक साथ हो रहे हैं-आखिरकार , ऐसा नहीं है कि चीजें वास्तव में कैसे होती हैं?

इस सीएसवी को बनाने के लिए, मैंने ऊपर दिए गए प्रत्येक व्यक्तिगत परीक्षण के लिए उपयोग किए गए मौजूदा मूल्यों को लिया, और उन मानों को एक एकल सीएसवी में जोड़ दिया, जो इस सुंदर ग्राफ को उत्पन्न करता है:

यह संदेश भी देता है:

आपके डेटाबेस उपयोग के आधार पर, आपका SQL सर्वर कार्यभार सीमा से बाहर . है . इस समय, कोई सेवा स्तर/प्रदर्शन स्तर नहीं है जो आपके उपयोग को कवर करेगा।

यदि आप वाई-अक्ष को देखते हैं, तो आप देखेंगे कि हम 1200 सेकंड के निशान पर "1,000k" (यानी 1 मिलियन) डीटीयू हिट करते हैं। ऐसा लगता है ... उह ... गलत? यदि हम उपरोक्त परीक्षणों को देखें, तो 1200 सेकंड का निशान तब था जब सभी 4 व्यक्तिगत मेट्रिक्स ने 4000 DTU, P15 टियर के लिए निशान मारा। यह समझ में आता है कि हम सीमा से बाहर हो जाएंगे, लेकिन ग्राफ़ का आकार मेरे लिए बिल्कुल मायने नहीं रखता है-मुझे लगता है कि डीटीयू कैलकुलेटर ने बस हाथ ऊपर कर दिया और कहा, "जो भी हो, एंडी। यह बहुत है। यह भी है बहुत। यह एक अरब डीटीयू है। यह कार्यभार Azure SQL डेटाबेस के लिए उपयुक्त नहीं है।"

ठीक है, तो क्या होता है पहले 1200 सेकंड का निशान? आइए सीएसवी को कम करें और इसे केवल पहले 1200 सेकंड के साथ कैलकुलेटर पर पुनः सबमिट करें। प्रत्येक कॉलम के लिए अधिकतम मान हैं:81% सीपीयू (या 100% पर apx 13 कोर), 24000 रीड/सेकंड, 24000 राइट/सेकंड, और 60एमबी लॉग फ्लश/सेकंड।

हैलो, पुराने दोस्त... वह परिचित रूप फिर से वापस आ गया है। यहां सीएसवी से डेटा का सारांश दिया गया है, और डीटीयू कैलकुलेटर कुल डीटीयू उपयोग और सेवा स्तर के लिए क्या अनुमान लगाता है।

<थ>पढ़ता/सेकंड <थ>डीटीयू <थ>सर्विस टियर

संख्या कोर	लिखता/सेकंड	लॉग मेगाबाइट फ़्लश/सेकंड
1	2000	2000	5	500	प्रीमियम - P4
2-3	4000-6000	4000-6000	10	1000	प्रीमियम - P6
4-5	8000-10000	8000-10000	15-25	1750	प्रीमियम - P11
6-13	12000-24000	12000-24000	30-40	4000	प्रीमियम - P15

अब, आइए देखें कि व्यक्तिगत डीटीयू गणना (जब हमने उनका मूल्यांकन अलग-अलग किया था) इस सबसे हालिया जांच से डीटीयू गणनाओं की तुलना कैसे करते हैं:

<थ> फ्लश डीटीयू लॉग करें <थ>सर्विस टियर

CPU DTUs	DTU पढ़ें	DTU लिखें	कुल DTU का योग	DTU कैलकुलेटर अनुमान
100	250	250	250	850	500	प्रीमियम - P4
500	500	500	500	2000	1000	प्रीमियम - P6
500-1000	1000	1000	1000	3500-4000	1750	प्रीमियम - P11
1000-1750	1000-1750	1000-1750	1750	4750-7000	4000	प्रीमियम - P15

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

DTU को पारंपरिक हार्डवेयर से मैप करना

आइए DTU कैलकुलेटर से डेटा लें, और कुछ अनुमान लगाने का प्रयास करें कि पारंपरिक हार्डवेयर कुछ Azure SQL डेटाबेस स्तरों पर कैसे मैप कर सकता है।

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

जब मैं हार्डवेयर स्पेक्स का अनुमान लगा रहा हूं, तो मैं एक संभावित Azure VM आकार भी चुनूंगा जो प्रत्येक हार्डवेयर कॉन्फ़िगरेशन में फिट होगा। कई समान Azure VM आकार हैं, प्रत्येक अलग-अलग प्रदर्शन मीट्रिक के लिए अनुकूलित है, लेकिन मैंने आगे बढ़कर अपनी पसंद को A-Series और DSv2-Series तक सीमित कर दिया है।

<थ>आईओपीएस <थ>स्मृति <थ>डीटीयू <थ>सर्विस टियर

संख्या कोर	तुलनीय Azure VM आकार
1 कोर, 5% उपयोग	10	???	5	बुनियादी	Standard_A0, बमुश्किल उपयोग किया जाता है
<1 कोर	150	???	100	मानक S0-S3	Standard_A0, पूरी तरह से उपयोग नहीं किया गया
1 कोर	4000 तक	???	500	प्रीमियम - P4	मानक_DS1_v2
2-3 कोर	12000 तक	???	1000	प्रीमियम - P6	Standard_DS3_v2
4-5 कोर	20000 तक	???	1750	प्रीमियम - P11	Standard_DS4_v2
6-13	48000 तक	???	4000	प्रीमियम - P15	Standard_DS5_v2

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

मानक स्तर भी बहुत सीमित है, लेकिन छोटे अनुप्रयोगों के लिए, यह आपकी आवश्यकताओं को पूरा करने में सक्षम है। यदि आपके पास एक 2-कोर सर्वर है जो मुट्ठी भर डेटाबेस चला रहा है, तो वे डेटाबेस व्यक्तिगत रूप से मानक स्तर में फिट हो सकते हैं। इसी तरह, यदि आपके पास केवल एक डेटाबेस वाला सर्वर है, जो 100% पर 1 CPU कोर चला रहा है (या 2 कोर 50% पर चल रहा है), तो शायद यह प्रीमियम-P1 सर्विस टियर में स्केल को टिप देने के लिए पर्याप्त हॉर्स पावर है।

यदि आप ऑन-प्रिमाइसेस (या IaaS) में मल्टी-कोर सर्वर का उपयोग कर रहे हैं, तो आप Azure SQL डेटाबेस पर प्रीमियम सर्विस टियर के भीतर देख रहे होंगे। यह केवल यह निर्धारित करने की बात है कि आपको अपने कार्यभार के लिए कितनी CPU और I/O हॉर्सपावर की आवश्यकता है। आपका 2-कोर, 4GB सर्वर शायद आपको P6 Azure SQL DB के आसपास कहीं लैंड करता है। एक शुद्ध सीपीयू वर्कलोड (शून्य I/O के साथ) में, एक P15 डेटाबेस 16 कोर प्रसंस्करण के लायक संभाल सकता है, लेकिन एक बार जब आप मिश्रण में IO जोड़ते हैं, तो ~ 12 कोर से बड़ा कुछ भी Azure SQL डेटाबेस में फिट नहीं होता है।

अगली बार, मैं कुछ वास्तविक कार्यभार लूंगा, और सेवा स्तरों पर प्रदर्शन की तुलना करूंगा। क्या डीटीयू कैलकुलेटर के अनुमान सटीक होंगे? हम पता लगा लेंगे।

लेखक के बारे में

एंडी मॉलन एक SQL सर्वर DBA और Microsoft डेटा प्लेटफ़ॉर्म MVP है जिसने स्वास्थ्य, वित्त, और -वाणिज्य, और गैर-लाभकारी क्षेत्र। 2003 से, एंडी प्रदर्शन आवश्यकताओं की मांग के साथ उच्च मात्रा, अत्यधिक उपलब्ध ओएलटीपी वातावरण का समर्थन कर रहा है। एंडी, BostonSQL के संस्थापक हैं, SQLSaturday बोस्टन के सह-आयोजक हैं, और am2.co पर ब्लॉग करते हैं।