Database
 sql >> डेटाबेस >  >> RDS >> Database

घुटने-झटका प्रदर्शन ट्यूनिंग:बस एक एसएसडी जोड़ें

मेरी 'घुटने-झटका प्रदर्शन ट्यूनिंग' श्रृंखला की निरंतरता में, मैं सॉलिड स्टेट डिस्क (एसएसडी) और SQL सर्वर वातावरण में उनके उपयोग के साथ कुछ समस्याओं पर चर्चा करना चाहता हूं। SSDs के गहन विवरण के लिए, इस विकिपीडिया लेख को देखें।

एसएसडी SQL सर्वर प्रदर्शन के लिए क्या करते हैं?

SSD में कोई गतिमान भाग नहीं होता है, इसलिए जब कोई पढ़ना या लिखना होता है, तो लगभग कोई I/O विलंबता नहीं होती है। कताई ड्राइव में विलंबता दो चीजों से आती है:

  • डिस्क की सतह पर डिस्क हेड को सही ट्रैक पर ले जाना (जिसे सीक टाइम कहा जाता है)
  • डिस्क के ट्रैक पर सही बिंदु पर घूमने की प्रतीक्षा करना (जिसे घूर्णी विलंबता के रूप में जाना जाता है)

इसका मतलब यह है कि आई/ओ बाधा होने पर एसएसडी एक बड़ा प्रदर्शन बढ़ावा देते हैं।

यह इतना आसान है।

थोड़ी सी जटिलता है जो ध्यान देने योग्य है लेकिन गहराई में जाने के लिए इस लेख के दायरे से परे है:SSD का प्रदर्शन ख़राब होना शुरू हो सकता है क्योंकि ड्राइव वास्तव में पूर्ण हो जाती है (AnandTech के इस लेख में विस्तार से जांच और व्याख्या की गई है)। SSD ड्राइवर के लिए वियर लेवलिंग (SSD में NAND कोशिकाओं के जीवन को लम्बा करना) में मदद करने के लिए कुछ सिस्टम मेमोरी की आवश्यकता हो सकती है, और यह विक्रेता द्वारा अलग-अलग होने वाला है। बस इतना ही - SQL सर्वर सामग्री पर वापस।

खराब इंटरनेट सलाह से बचें

इंटरनेट पर SQL सर्वर और SSD के आस-पास बहुत खराब सलाह के दो अंश हैं।
पहला यह है कि SSD पर क्या रखा जाए, जहाँ सलाह है कि SSDs पर हमेशा tempdb और अपने लेन-देन लॉग डालें। पहली नज़र में यह अच्छी सलाह लगती है, क्योंकि लेन-देन लॉग और tempdb आमतौर पर सिस्टम में अड़चनें हैं।

लेकिन क्या होगा अगर वे नहीं हैं?

आपका कार्यभार अधिकतर पढ़ा जा सकता है, इस स्थिति में लेन-देन लॉग संभवतः कार्यभार की अड़चन नहीं होगी और इसलिए इसे SSD पर रखना एक महंगे SSD की बर्बादी हो सकती है।
आपका tempdb बहुत अधिक उपयोग नहीं किया जा सकता है आपके कार्यभार से, इसलिए इसे SSD पर रखना एक महंगे SSD की बर्बादी हो सकती है।

जब आप एसएसडी में जाने के लिए SQL सर्वर वातावरण के किस हिस्से पर विचार कर रहे हैं, तो आप जांच करना चाहते हैं कि I/O बाधाएं कहां हैं। यह मेरे द्वारा पिछले सप्ताह पोस्ट किए गए कोड का उपयोग करके बहुत आसानी से किया जा सकता है जो उदाहरण पर सभी डेटाबेस में सभी फ़ाइलों के लिए I/O विलंबता का एक स्नैपशॉट प्रदान करने के लिए sys.dm_io_virtual_file_stats DMV का उपयोग करता है। अपनी विलंबता संख्याओं को समझने के लिए, और उनकी तुलना अच्छे/बुरे मूल्यों से करने के लिए, इस लंबी पोस्ट के माध्यम से पढ़ें जो मैंने विशेष रूप से tempdb और लेनदेन लॉग I/O विलंबता के आसपास की थी।

और फिर भले ही आपके पास उच्च विलंबता हो, घुटने के बल न झुकें और सोचें कि खराब प्रदर्शन करने वाली फ़ाइल (फ़ाइलों) को SSD में स्थानांतरित करना ही एकमात्र उपाय है:

  • डेटा फ़ाइल के लिए विलंबता पढ़ने के लिए, जांच करें कि इतने सारे पठन क्यों हो रहे हैं। मैं इसे यहां कवर करता हूं।
  • लॉग फ़ाइल लिखने में विलंब के लिए, लॉग के प्रदर्शन को ट्यून करने के सभी तरीकों पर विचार करें और क्या लॉग किया जा रहा है। मैं इसे यहां, यहां और यहां कवर करता हूं।

सबसे खराब स्थिति यह है कि आपको एसएसडी का एक गुच्छा दिया जाता है, tempdb और अपनी लॉग फ़ाइलों को स्थानांतरित करने के लिए इंटरनेट सलाह का पालन करें, और फिर कोई कार्यभार प्रदर्शन लाभ नहीं होता है। यह आपके प्रबंधन को आपको अधिक महंगे SSD प्रदान करने के लिए प्रोत्साहित नहीं करेगा।

खराब सलाह का दूसरा हिस्सा इंडेक्स फ़्रेग्मेंटेशन के आसपास है, जहां सलाह यह है कि क्योंकि एसएसडी इतने तेज़ हैं, आपको एसएसडी का उपयोग करते समय इंडेक्स फ़्रेग्मेंटेशन के बारे में चिंता करने की ज़रूरत नहीं है।

क्या बकवास है!

मैं उस बुरी सलाह का खंडन करने के तीन तरीके हैं:

  1. एसएसडी किसी भी तरह से इंडेक्स फ्रैगमेंटेशन के कारण को नहीं रोकता है:पेज उन पेजों से अलग हो जाता है जिन्हें रैंडम इंसर्ट या रो साइज बढ़ाने के लिए फ्री स्पेस की जरूरत होती है। एक पृष्ठ विभाजन समान मात्रा में लेन-देन लॉग उत्पन्न करता है, संसाधन उपयोग करता है, और संभावित थ्रेड प्रतीक्षा करता है, भले ही डेटा/लॉग फ़ाइलें संग्रहीत हों।
  2. इंडेक्स फ़्रेग्मेंटेशन में कम पेज डेंसिटी वाले कई डेटा/इंडेक्स पेज शामिल हैं (यानी बहुत सारी खाली, खाली जगह)। क्या आप वाकई चाहते हैं कि आपके महंगे एसएसडी में बहुत सारी खाली जगह हो? SSD यहाँ बिल्कुल भी मदद नहीं करते हैं।
  3. मेरे सहयोगी जोनाथन केहैयस ने विशेष रूप से इस बुरी सलाह को संबोधित करने के लिए इंडेक्स फ़्रेग्मेंटेशन के आसपास I/O पैटर्न की विस्तृत घटनाओं का उपयोग करते हुए एक गहन जांच की और पाया कि एसएसडी का उपयोग करते समय इंडेक्स फ़्रेग्मेंटेशन होने से अभी भी एक प्रदर्शन हिट है। आप उनकी लंबी पोस्ट यहाँ पढ़ सकते हैं।

केवल एक चीज जो SSDs इंडेक्स फ़्रेग्मेंटेशन के आसपास करते हैं, वह है रीड्स को तेज़ करना, इसलिए इंडेक्स फ़्रेग्मेंटेशन मौजूद होने पर इंडेक्स रेंज स्कैन के लिए प्रदर्शन पेनल्टी कम होती है, लेकिन ऊपर दिए गए पॉइंट 3 से पता चलता है कि अभी भी पेनल्टी है।

SSDs आपके SQL सर्वर परिवेश में अनुक्रमणिका फ़्रेग्मेंटेशन से निपटने और/या रोकने के तरीके को नहीं बदलते हैं।

अपने डेटा की सुरक्षा सुनिश्चित करें

मुख्य पापों में से एक मैं देखता हूं कि लोग एसएसडी का उपयोग कर रहे हैं, उनमें से केवल एक का उपयोग कर रहे हैं। केवल एक ड्राइव के साथ, आप किस RAID स्तर का उपयोग कर रहे हैं? शून्य। RAID-0 कोई अतिरेक प्रदान नहीं करता है।

यदि आप SSD का उपयोग करने जा रहे हैं, तो आपको RAID-1 (मिररिंग) कॉन्फ़िगरेशन में कम से कम दो का उपयोग करने की आवश्यकता है। यदि आप ट्रेड-ऑफ़ के रूप में सिस्टम की उपलब्धता का त्याग कर रहे हैं तो प्रदर्शन को बढ़ावा देने का कोई मतलब नहीं है।

कभी-कभी कम से कम दो एसएसडी का उपयोग करने के लिए मुझे एक पुश बैक मिलता है कि एसएसडी कार्ड विंडोज़ को दो ड्राइव प्रदान करता है, और इसलिए निश्चित रूप से दो ड्राइव पर विंडोज़ मिरर वॉल्यूम बनाना दो शारीरिक रूप से अलग एसएसडी में RAID-1 जैसा ही है?

नहीं यह नहीं। यह अभी भी एक भौतिक SSD है, जिसमें कोई अतिरेक नहीं है। क्या आपने कभी SSD कार्ड के आधे हिस्से को फेल होते देखा है? नहीं, न ही मेरे पास है। इसे सही करें और उनमें से दो का उपयोग करें और अपने डेटा के लिए वास्तविक अतिरेक प्राप्त करें।

मुझे जो दूसरा पुश बैक मिलता है, वह यह है कि वे एसएसडी हैं, स्पिनिंग ड्राइव नहीं, इसलिए असफल नहीं होंगे। यह गलत है। एसएसडी स्पिनिंग ड्राइव की तरह ही विफल हो सकते हैं और कर सकते हैं। मैंने व्यक्तिगत रूप से दो एंटरप्राइज़-ग्रेड SSDs को हमारे प्रयोगशाला वातावरण में परीक्षण के दौरान विफल होते देखा है। StorageReview.com पर इस लेख के अनुसार, उपभोक्ता-ग्रेड SSD के पास उपभोक्ता-ग्रेड कताई ड्राइव के लिए 2 मिलियन घंटे बनाम 1.5 मिलियन घंटे का MTBF है, और मुझे एंटरप्राइज़-ग्रेड ड्राइव के लिए समान परिणाम की उम्मीद है, लेकिन SSD विफल हो जाते हैं।

सारांश

इस सोच के जाल में न पड़ें कि आप SSD पर जो कुछ भी डालते हैं उसका मतलब है कि आपको प्रदर्शन में बढ़ावा मिलेगा - आपको सावधानी से चुनना और चुनना होगा। और एसएसडी का उपयोग करते समय इंडेक्स विखंडन को अनदेखा करने के बारे में वहां की बकवास पर विश्वास न करें।

एसएसडी प्रदर्शन बढ़ाने का एक बहुत ही उपयोगी तरीका है, लेकिन उनकी लागत के लिए, आप यह सुनिश्चित करना चाहते हैं कि आप अपनी कंपनी के निवेश पर उनका सही और केवल उचित उपयोग करके अधिकतम लाभ प्राप्त कर रहे हैं।

श्रृंखला के अगले लेख में, मैं घुटने के बल चलने वाले प्रदर्शन ट्यूनिंग के एक अन्य सामान्य कारण पर चर्चा करूँगा। तब तक, समस्या निवारण के लिए शुभकामनाएँ!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. जावा 9 में मॉड्यूल एपीआई की खोज

  2. WHM में डेटाबेस केवल बैकअप

  3. शुरुआती के लिए एसक्यूएल कम () ऑपरेटर से कम

  4. निकटतम मैच, भाग 3

  5. यह मिथक कि DROP और TRUNCATE TABLE नॉन-लॉगेड हैं