लिनक्स में MySQL स्टोरेज परफॉर्मेंस को बेंचमार्क करते समय याद रखने वाली एक महत्वपूर्ण बात कैश है। मैं खुद उसी टेस्ट केस को लेकर उत्सुक था। जब कोई उपयोगकर्ता धीमी क्वेरी के बारे में शिकायत करता है तो यह हमेशा मज़ेदार होता है। वे आपको कॉल करते हैं और केवल अपनी 50+ मिनट की क्वेरी को खोजने के लिए फिर से दौड़ते हैं जो अब क्वेरी कैश के कारण 30 सेकंड में पूरी होती है। हमेशा एक
. चलाएंmysql> reset query cache;
MySQL में प्रश्नों को अनुकूलित करने का प्रयास करते समय। उस ने कहा, SSD की पारंपरिक स्पिंडल से तुलना करते समय एक और कदम है:डिस्क कैश। जब OS अपने आप मेमोरी में डिस्क को कैश कर रहा हो, तो एक्सेस समय या IOps की तुलना करना मुश्किल होता है। डिस्क कैश साफ़ करने के लिए, शेल से निम्नलिखित चलाएँ:
$ sync && sysctl -w vm.drop_caches=3
आपके प्रत्येक बेंचमार्क क्वेरी से पहले चलने वाले ये कमांड आपको उस 7k2 SATA स्लोपोक की तुलना में आपके SSD की क्षमता का एहसास करने में मदद करेंगे। कैश को फ्लश किए बिना और क्वेरी समय को देखे बिना एक ही क्वेरी को दो बार चलाकर इसे सत्यापित करें। इस बिंदु पर, अनुक्रमणिका के साथ और बिना कुछ प्रश्नों का प्रयास करना एक अच्छा विचार है, साथ ही यदि संभव हो तो कुछ जुड़ते हैं। यह सत्यापित करने के लिए कि किसी अनुक्रमणिका का उपयोग किया गया है, प्रत्येक क्वेरी पर EXPLAIN PLAN का उपयोग करें। इंडेक्स और डेटा फ़ाइलों के बीच पढ़ने की यादृच्छिक पहुंच धीमी डिस्क पर बाधाओं को उजागर करेगी। सुनिश्चित करें कि आपका my.cnf आपके SSD बेंचमार्क और आपकी थाली के बीच सुसंगत है। मैंने एक साधारण डेस्कटॉप OCZ SSD पर कुछ चीजों का परीक्षण किया और देखा कि मेरी 7200rpm SATA डिस्क जितनी तेजी से 10x के आसपास क्वेरी प्रदर्शन में वृद्धि हुई है। SSD- आधारित ट्रांजेक्शनल डेटाबेस में, मैं OPTIMIZE TABLE का उपयोग करते समय सावधान रहूंगा क्योंकि SSD TRIM के साथ संयुक्त डेटाबेस संघनन डिस्क जीवन को प्रभावित कर सकता है। हालांकि यह सैद्धांतिक है, और मुझे अभी तक इसका समर्थन करने के लिए सबूत देखना बाकी है।
उम्मीद है ये मदद करेगा! मैं उन दिनों का इंतजार नहीं कर सकता जब चुंबकीय एचडी टेप को बैकअप माध्यम के रूप में बदल देते हैं और अधिकांश हार्डवेयर में खुद को एसएसडी द्वारा पूरी तरह से बदल देते हैं।
