2010-10-02 9 views
51

MySQL वर्कबेंच सर्वर स्वास्थ्य के साथ "कुंजी दक्षता" नामक एक मान की रिपोर्ट करता है। इसका क्या अर्थ है और इसका क्या प्रभाव है?MySQL "कुंजी दक्षता"

alt text

MySQL.com से, "कुंजी क्षमता" है:

... key_read_requests की संख्या का एक संकेत है कि वास्तविक key_reads में हुई।

ठीक है, तो इसका क्या अर्थ है। यह मुझे बताता है कि मुझे सर्वर को कैसे ट्यून करना है?

+0

क्या आप MyISAM टेबल या इनोडब का उपयोग कर रहे हैं? – Martin

+0

@ मार्टिन मैं मूल्यों के निहितार्थ के बारे में पूछ रहा हूं, किसी भी विशिष्ट MySQL उदाहरण को ट्यून करने की कोशिश नहीं कर रहा हूं। चित्र केवल एक उदाहरण है जो यह दिखाने के लिए है कि जानकारी कहां मिलें। – tylerl

+3

सर्वर को ट्यून करने के मामले में, आप जिस स्टोरेज इंजन का उपयोग कर रहे हैं (MyISAM बनाम InnoDB बनाम ...) उन चर को प्रभावित करेगा जिन्हें आपको ट्यून करने की आवश्यकता है। माईसाम के लिए, कुंजी-बफर-आकार महत्वपूर्ण है। InnoDB के लिए, यह innodb_buffer_pool_size है। ये प्रभावित करता है कि MySQL पता स्थान के भीतर कितनी कुंजियों को कैश किया जा सकता है। आम तौर पर, बेहतर होगा। हालांकि, जैसा कि माइकल ईकिन्स बताते हैं, अगर आपके सिस्टम में बहुत मेमोरी है, तो फाइल सिस्टम किसी भी मामले में इंडेक्स का अधिकतर कैश करेगा। – Martin

उत्तर

73

"कुंजी क्षमता" कितना मूल्य तुम MySQL की स्मृति के भीतर आयोजित सूचकांक कैश से हो रही है का एक संकेत है।यदि आपकी मुख्य दक्षता अधिक है, तो अक्सर माईएसक्यूएल मेमोरी स्पेस के भीतर से मुख्य लुकअप कर रहा है, जो डिस्क से संबंधित इंडेक्स ब्लॉक को पुनर्प्राप्त करने से कहीं अधिक तेज़ है।

कुंजी दक्षता में सुधार करने का तरीका है MySQL के इंडेक्स कैश में अपनी सिस्टम मेमोरी को अधिक समर्पित करना। आप यह कैसे करते हैं आपके द्वारा उपयोग किए जाने वाले स्टोरेज इंजन पर निर्भर करता है। MyISAM के लिए, कुंजी-बफर-आकार के मान को बढ़ाएं। InnoDB के लिए, innodb-buffer-pool-size के मान को बढ़ाएं।

हालांकि, जैसा कि माइकल ईकिन्स बताते हैं, ऑपरेटिंग सिस्टम में डिस्क ब्लॉक के कैश भी हैं जिन्हें हाल ही में एक्सेस किया गया है। आपके ऑपरेटिंग सिस्टम की जितनी अधिक मेमोरी उपलब्ध है, उतना अधिक डिस्क ब्लॉक कैश कर सकता है। इसके अलावा, डिस्क स्वयं (और कुछ मामलों में डिस्क नियंत्रक) ड्राइव करती है, इसमें कैश भी होते हैं - जो डिस्क से डेटा पुनर्प्राप्त करने में तेजी ला सकता है। पदानुक्रम इस तरह थोड़ा है:

  1. सबसे तेज़ - MySQL के इंडेक्स कैश के भीतर से इंडेक्स डेटा पुनर्प्राप्त करना। लागत कुछ मेमोरी ऑपरेशंस है।
  2. ओएस फ़ाइल सिस्टम कैश में रखे गए इंडेक्स डेटा को पुनर्प्राप्त करना। लागत एक सिस्टम कॉल (पढ़ने के लिए), और कुछ स्मृति संचालन है।
  3. डिस्क सिस्टम कैश (नियंत्रक और ड्राइव) में रखे गए इंडेक्स डेटा को पुनर्प्राप्त करना। लागत एक सिस्टम कॉल (पढ़ने के लिए), डिस्क डिवाइस के साथ संचार, और कुछ स्मृति संचालन है।
  4. सबसे धीमा - डिस्क सतह से सूचकांक डेटा पुनर्प्राप्त करना। लागत एक सिस्टम कॉल, डिवाइस के साथ संचार, डिस्क के भौतिक आंदोलन (हाथ आंदोलन + रोटेशन) है।

अभ्यास में, 1 और 2 के बीच का अंतर लगभग अनजान है जब तक कि आपका सिस्टम बहुत व्यस्त न हो। साथ ही, यह असंभव है (जब तक आपके सिस्टम में आपके डिस्क नियंत्रक की तुलना में कम अतिरिक्त रैम नहीं है) कि परिदृश्य 3 खेल में आ जाएगा।

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

एक दिलचस्प अभ्यास (यदि आपके पास समय है) यह धीमा चलाने के लिए आपके सिस्टम के साथ टिंकर करना है। बड़े टेबल पर मानक वर्कलोड चलाना, जब तक प्रभाव ध्यान देने योग्य न हो जाए, MySQL बफर को कम करें। अपने फ़ाइल सिस्टम (बिल्ली बड़ी फ़ाइल>/dev/null) के माध्यम से अप्रासंगिक डेटा की विशाल मात्रा (रैम से अधिक) पंप करके अपने फ़ाइल सिस्टम कैश को फ़्लश करें। अपने प्रश्नों के चलते iostat देखें।

"कुंजी दक्षता" यह नहीं है कि आपकी चाबियां कितनी अच्छी हैं। अच्छी तरह से डिजाइन की चाबियाँ उच्च "कुंजी दक्षता" की तुलना में प्रदर्शन पर बहुत अधिक प्रभाव डालती हैं। दुर्भाग्यवश, MySQL में आपकी सहायता करने के लिए बहुत कुछ नहीं है।

+1

अनुसंधान के लिए धन्यवाद! – tylerl

7

Key_read_requests कैश से एक प्रमुख ब्लॉक पढ़ने के अनुरोधों की संख्या है। जबकि key_reads डिस्क से किसी कुंजी ब्लॉक के भौतिक पाठों की संख्या है। तो ये 2 चर स्वतंत्र रूप से बढ़ सकते हैं। (http://bugs.mysql.com/bug.php?id=28384)

अभी भी कीचड़ के रूप में स्पष्ट है कौन सा।

explaination के अगले बिट के लिए पर: Key_reads की

एक आंशिक रूप से वैध उपयोग Key_reads जांच करने के लिए, शारीरिक की संख्या के बारे में सोचते हैं कि हम देखभाल

वहाँ एक आंशिक रूप से वैध कारण है ऐसा होता है, क्योंकि हम जानते हैं कि डिस्क कंप्यूटर के अन्य भागों के सापेक्ष बहुत धीमी हैं। और यहां है जहां मैं "अधिकतर तथ्यात्मक" कहलाता हूं, क्योंकि Key_reads वास्तव में भौतिक डिस्क बिल्कुल नहीं पढ़ता है। यदि अनुरोध किया गया डेटा का ब्लॉक ऑपरेटिंग सिस्टम के कैश में नहीं है, तो एक की_read डिस्क पढ़ने के लिए है - लेकिन यदि यह कैश किया गया है, तो यह केवल एक सिस्टम कॉल है। हालांकि, की हमारी पहली मुश्किल से साबित धारणा बनाते हैं:

हार्ड करने वाली साबित धारणा # 1: एक Key_read, एक भौतिक डिस्क रीड के अनुरूप हो सकता है हो सकता है। अगर हम को सत्य मानते हैं, तो अन्य कारणों से हमें की देखभाल करने के लिए Key_reads की आवश्यकता हो सकती है? यह धारणा पर "कैश मिस महत्वपूर्ण है कैश हिट से धीमी है," जो समझ में आता है। यदि यह Key_read को Key_read_request के रूप में करने के लिए तेज़ था, तो क्या उपयोग कुंजी बफर वैसे भी होगा? चलिए इस पर MyISAM के निर्माता पर भरोसा करते हैं, क्योंकि उन्होंने किसी कैश को को मिस से तेज़ होने के लिए डिज़ाइन किया है। (http://planet.mysql.com/entry/?id=23679)