मैं दो भागों में उत्तर दूंगा: पहला "क्यों अनुक्रमिक और यादृच्छिक को अलग करने के बारे में पारंपरिक उत्तर अक्सर लागू नहीं होता है।"
फिर मैं विंडोज़ फिजिकलडिस्क पर फ़ाइलों को अलग करने के अतिरिक्त लाभों पर चर्चा करूँगा, और अतिरिक्त vHBAs जोड़कर उनके बीच फिजिकल डिस्क वितरित करूँगा।
विंडोज फिजिकलडिस्क स्तर पर यादृच्छिक और अनुक्रमिक डिस्क IO को अलग करने से लाभ की उम्मीद आमतौर पर डेटा भंडारण के लिए HDD उपकरणों को मानती है। यह आमतौर पर यह भी मानता है कि अलग-अलग विंडोज़ फिजिकलडिस्क का अर्थ है अलग एचडीडी डिवाइस। विचार यह है कि HDD के कुछ सेट मुख्य रूप से अनुक्रमिक डिस्क IO को संभाल रहे हैं और बहुत ही सीमित डिस्क हेड मूवमेंट हैं (उदाहरण के लिए HDDs एक एकल व्यस्त txlog * की मेजबानी कर रहे हैं) जबकि HDD का एक अलग सेट यादृच्छिक डिस्क IO को संभाल रहा है।
उन मान्यताओं को आज शायद ही कोई पकड़ता है - खासकर वीएम में। सबसे पहले, जब तक कि वीएम विंडोज फिजिकलडिस्क आरडीएम नहीं हैं, एक से अधिक डेटासटोर में हो सकता है - या शायद एक से अधिक डेटास्टोर्स एक ईएसएक्सआई होस्ट LUN पर हैं। तो जो अतिथि में अलग हो गया है वह ईएसएक्सआई होस्ट स्तर पर शुरू किया जा सकता है।
लेकिन मान लें कि आरडीएम का उपयोग किया जाता है, या यह कि प्रत्येक अतिथि फिजिकलिस्क अपने खुद के ईएसएक्सएक्स लून पर, अपने स्वयं के डेटास्टोर पर है। फिर भी, अतिथि में यादृच्छिक io से अलग अनुक्रमिक अक्सर सरणी में आ जाता है, क्योंकि ESXi होस्ट को प्रस्तुत LUN डिस्क डिवाइस के एक ही पूल से हो सकता है। लगभग हर भंडारण सरणी अब ऐसा करती है - या तो विशेष रूप से या प्रबंधन को आसान बनाने और सरणी दक्षता / संसाधन उपयोग को बढ़ाने के लिए एक विकल्प के रूप में।
अंत में, आज इतना भंडारण या तो सभी फ्लैश या हाइब्रिड फ्लैश + एचडीडी है। चिंता करने के लिए कोई सिर आंदोलन के साथ, फ्लैश यादृच्छिक के लिए अनुक्रमिक के अलगाव के बारे में परवाह नहीं करता है ... आईओ बुनाई के बारे में भी परवाह नहीं करता है।
तो ... उन सभी कारणों से यादृच्छिक से अनुक्रमिक को अलग करने वाले सभी फायदेमंद नहीं हो सकते हैं। अगला क्यों फिजिकलडिस्क में फाइलें फैलाना और वीएचबीए में फिजिकलडिस्क फैलाना अभी भी प्रदर्शन को बढ़ावा दे सकता है।
* मैंने इस HDD उदाहरण में एक ही लेन-देन लॉग का उल्लेख किया है। जब कई अलग-अलग अनुक्रमिक डिस्क IO स्ट्रीम (जैसे 8 व्यस्त लेनदेन लॉग) एक ही HDD पर हो रहे हैं - जब तक कि लगभग किसी भी तरह की गतिविधि लगभग सभी SAN कैश के भीतर हो - क्रमिक IO ट्रैकों के बीच निरंतर सिर की आवाजाही IO बुनाई की ओर ले जाती है। यह एक विशिष्ट प्रकार का डिस्क हेड थ्रैशिंग है जो डिस्क लेटेंसी की ओर जाता है जो "यादृच्छिक से बदतर" है। RAID5 और RAID10 पर होता है, हालांकि RAID10 महत्वपूर्ण गिरावट से पहले RAID5 की तुलना में इस संबंध में थोड़ा अधिक भिन्नता को सहन कर सकता है।
अब - दी गई है कि लंबी बात के बारे में कैसे यादृच्छिक से अनुक्रमिक अलग मदद नहीं कर सकता है - कैसे फिजिकलडिस्क भर में फ़ाइलों को फैलाने अभी भी मदद कर सकता है? वीएचबीए के बीच फिजिक्स को कैसे फैलाया जा सकता है?
यह डिस्क IO कतारों के बारे में है।
किसी भी विंडोज फिजिकलडिस्क या लॉजिकलडिस्क में 255 बकाया डिस्क आईओएस हो सकते हैं, जो कि "समसामयिक डिस्क क्यू" के रूप में परफॉमेंस द्वारा सूचित किया जाता है। फिजिकलडिस्क कतार में बकाया डिस्क आईओ से, स्टोर्पोड 254 तक मिनीड्राइव से गुजर सकता है। लेकिन minidriver में सेवा कतार (अगले निचले स्तर तक नीचे) और प्रतीक्षा कतार दोनों हो सकती हैं। और स्टोरपोर्ट को 254 से गुजरने वाली संख्या को कम करने के लिए कहा जा सकता है।
VMware विंडोज अतिथि में, pvscsi ड्राइवर में 64 की गहराई "डिफ़ॉल्ट" कतार है, जहां डिवाइस एक फिजिकलडिस्क है। इसलिए हालांकि परफॉमेंस सिंगल फिजिकलडिस्क के लिए "वर्तमान डिस्क कतार लंबाई" में 255 डिस्क आईओ तक दिखा सकता है, उनमें से केवल 64 तक एक समय में अगले स्तर तक पारित किया जाएगा (जब तक कि चूक नहीं बदली जाती)।
कितने डिस्क आईओ एक के लिए बकाया हो सकते हैंएक बार में व्यस्त लेन-देन? खैर, लेन-देन लॉग राइट्स आकार में 60kb तक हो सकता है। उच्च स्तर के ईटीएल के दौरान, मैं अक्सर 60kb पर txlog के लिए हर लेखन देखूंगा। Txlog लेखक एक समय में एक txlog के लिए बकाया 60kb के 32 लिखते हैं। तो क्या हुआ अगर मुझे डिफ़ॉल्ट वीएमवेयर सेटिंग्स के साथ एक ही फिजिक्स पर एक व्यस्त स्टेजिंग txlog और एक व्यस्त dw txlog मिल गया है? यदि दोनों txlogs 32 बकाया 60kb पर अधिकतम कर रहे हैं, प्रत्येक लिखते हैं कि physicaldisk 64 की गहराई पर है। अब ... क्या होगा अगर वहाँ भी एक ईपीएल स्रोत के रूप में physicaldisk पर flatfiles हैं? खैर ... फ्लैटफाइल्स और txlog को पढ़ता है के बीच लिखते हैं, वे प्रतीक्षा कतार का उपयोग करना होगा, क्योंकि एक समय में केवल 64 बाहर निकल सकते हैं। इस तरह के व्यस्त txlogs वाले डेटाबेस के लिए, चाहे वह भौतिक सर्वर हो या वर्चुअल, मैं txlog को अपने फिजिकलडिस्क पर सुझाता हूं, Physicaldisk पर और कुछ नहीं के साथ। यह उस स्तर पर कतार को रोकता है और कई फ़ाइलों की सामग्री के साथ किसी भी चिंता को समाप्त करता है (जो इन दिनों बहुत अधिक चिंता का विषय है)।
कितने डिस्क IOs एक समय में एक RFfile के लिए बकाया हो सकते हैं (SQL सर्वर के नजरिए से, जरूरी नहीं कि उन्हें निचले स्तरों पर प्रस्तुत किया जाए)? SQL Server में वास्तव में कोई सीमा नहीं है (जो मैंने पाया है, वैसे भी)। लेकिन फ़ाइल संभालने एक भी विंडोज PhysicalDisk (मैं एसक्यूएल सर्वर, एक और समय के लिए एक विषय है कि के लिए धारीदार गतिशील डिस्क उपयोग करने की अनुशंसा नहीं करते हैं) पर है, वहाँ है एक सीमा होती। यह 255 मैंने पहले उल्लेख किया है।
SQL सर्वर रीडहेड और एसिंक्रोनस IO के जादू के साथ, मैंने 4 समवर्ती प्रश्नों को देखा है, जो धारावाहिक ड्राइव में 1200 से अधिक की कुल "वर्तमान डिस्क कतार लंबाई" में चलते हैं! 255 सीमा के कारण, यह एक भी फिजिकलडिस्क पर सभी rowfile सामग्री के साथ संभव नहीं है। यह 8 प्राथमिक फाइलों के साथ एक प्राथमिक फाइलग्रुप के खिलाफ था, प्रत्येक फिजिकलडिस्क पर।
इसलिए रीडहेड रीड बहुत आक्रामक हो सकता है, और आईओ कतारों पर जोर दे सकता है। वे इतने आक्रामक हो सकते हैं कि अन्य उपद्रवी पढ़ते हैं और लिखते हैं कि इंतजार खत्म होता है। यदि लेन-देन लॉग एक ही फिजिकलडिस्क पर हैं जैसा कि रॉफाइल्स, साथ ही साथ रीडहेड पढ़ता है और txlog लिखता है कि यह जगह लेने के लिए इंतजार करना बहुत आसान है। यहां तक कि अगर वह प्रतीक्षा "वर्तमान डिस्क कतार लंबाई" स्तर पर नहीं है, तो यह डिवाइस कतार (pvscsi के साथ डिफ़ॉल्ट रूप से 64) पर प्रतीक्षा कर सकता है।
Rowfiles के खिलाफ बैकअप रीडिंग्स भी आक्रामक हो सकते हैं, खासकर अगर बैकअप थ्रूपुट को अधिकतम करने के लिए बफ़राउंट को ट्यून किया गया हो।
Txlogs को अलग करने पर विचार करते समय जागरूक होने के लिए एक और SQL सर्वर io प्रकार है: tempdb को क्वेरी स्पिल। जब क्वेरी स्पिल होती है, तो प्रत्येक स्पिलिंग कार्य टेम्पर्ड को लिखता है। एक ही समय में सभी समानांतर श्रमिकों के बहुत सारे मिल गए? यह काफी एक भार हो सकता है। व्यस्त txlog और महत्वपूर्ण rowfiles को उस से दूर रखना वास्तव में उपयोगी हो सकता है :-)
अब, pvscsi ड्राइवर के लिए डिफ़ॉल्ट डिवाइस कतार गहराई को बदलना संभव है। यह 64 तक डिफॉल्ट करता है, और 254 के रूप में उच्च सेट किया जा सकता है जो कि सबसे अधिक स्टोरेज है, जो पास होगा। लेकिन इसे बदलने में सावधानी बरतें। मैं हमेशा अंतर्निहित ESXi होस्ट LUN कतार गहराई के साथ अतिथि डिवाइस कतार गहराई संरेखित करने की सलाह देता हूं। और ESXi होस्ट LUN कतार गहराई प्रति सरणी सर्वोत्तम प्रथाओं की स्थापना। एक EMC VNX का उपयोग? होस्ट LUN कतार की गहराई 32 होनी चाहिए। अतिथि RDM का उपयोग करता है? महान। अतिथि pvscsi डिवाइस कतार गहराई को 32 पर सेट करें ताकि यह ESXi होस्ट LUN कतार गहराई के साथ संरेखित हो। EMC VMAX? आमतौर पर ईएसएक्सआई मेजबान स्तर पर 64, अतिथि में 64। शुद्ध / Xtremio / IBM FlashSystem? कभी-कभी होस्ट LUN कतार गहराई 256 के रूप में उच्च सेट की जाएगी! आगे बढ़ो और 254 (अधिकतम संभव) के लिए pvscsi डिवाइस कतार गहराई सेट करें।
यहां निर्देशों के साथ एक लिंक दिया गया है।
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
लिंक भी अनुरोधों के बारे में बात करता है - WhatAreThose ?? वे स्वयं pvscsi एडेप्टर के लिए कतार की गहराई निर्धारित करते हैं। प्रत्येक पृष्ठ एडेप्टर कतार गहराई में 32 स्लॉट देता है। डिफ़ॉल्ट रूप से, अनुरोधकर्ता 256 के अडैप्टर कतार गहराई के लिए 8 है। यह 1024 एडॉप्टर कतार गहराई स्लॉट के लिए 32 के रूप में उच्च सेट किया जा सकता है।
मान लें कि सब कुछ डिफ़ॉल्ट रूप से है। मैं उन पर rowfiles के साथ 8 physicaldisks मिला है, और SQL सर्वर हल्के से व्यस्त है। 8 भर में औसतन 32 "वर्तमान डिस्क कतार लंबाई" है, और कोई भी 64 से अधिक नहीं है (सब कुछ विभिन्न डिवाइस सेवा कतार में फिट बैठता है)। महान - जो 256 OIO देता है। यह डिवाइस सेवा कतारों में फिट बैठता है, यह एडेप्टर सेवा कतार में फिट बैठता है, इसलिए सभी 256 इसे अतिथि से बाहर ESX होस्ट स्तर पर कतार में बनाते हैं।
लेकिन ... अगर चीजें थोड़ी व्यस्त हो जाती हैं, तो 64 का औसत कुछ शारीरिक डिस्क की कतार के रूप में 128 के रूप में उच्च है। उन उपकरणों के लिए जो 64 से अधिक बकाया हैं, ओवरएज एक प्रतीक्षा कतार में है। यदि 8 से अधिक फिजिक्स में डिवाइस की सर्विस कतार में 256 से अधिक है, तो एडेप्टर सेवा कतार में स्लॉट्स खुलने तक वहां इंतजार खत्म हो जाता है।
उस स्थिति में, एक और pvscsi vHBA को जोड़ने और उनके बीच के फिजिक्स को फैलाने से कुल एडेप्टर कतार की गहराई 512 हो जाती है। एक ही समय में अधिक io को अतिथि से होस्ट किया जा सकता है।
कुछ इसी तरह एक pvscsi एडॉप्टर पर रहकर और रिस्ट्रिंजिंग को बढ़ाकर हासिल किया जा सकता है। 16 में जाने से 512 स्लॉट निकलेंगे, और 32 से 1024 स्लॉट बनेंगे।
जब संभव हो, तो मैं गहरे (एडेप्टर कतार गहराई बढ़ाने) जाने से पहले व्यापक (एडेप्टर जोड़कर) जाने की सलाह देता हूं। लेकिन ... कई व्यस्ततम व्यवस्थाओं में, दोनों ही करना होगा: अतिथि पर 4 vHBAs डालें, और 32 के लिए रिस्ट्रिंजिंग बढ़ाएँ।
बहुत सारे अन्य विचार भी हैं। अगर वीएमडीके का उपयोग किया जाता है, तो सीओसी और एडेप्टिव कतार डेप्थ थ्रॉटलिंग जैसी चीजें, मल्टीथैथिंग का कॉन्फ़िगरेशन, एलएनयूआई एडाप्टर की कॉन्फ़िगरेशन एलयूएन क्यू गहराई से परे, आदि।
लेकिन मैं अपने स्वागत को खत्म नहीं करना चाहता हूं :-)
लोनी Niederstadt @sqL_handLe