MySQL प्रदर्शन धोखा पत्र

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

यहाँ MySQL के प्रमुख क्षेत्र हैं जो मैंने MySQL दुनिया के विभिन्न विशेषज्ञ स्रोतों से लिए हैं, साथ ही साथ हमारे अपने अनुभव यहाँ कईनीन्स में हैं। यह ब्लॉग प्रदर्शन को बेहतर बनाने और आपके MySQL को फिर से शानदार बनाने के लिए आपकी चीट शीट के रूप में काम करेगा :-)

आइए MySQL में प्रमुख क्षेत्रों को रेखांकित करके इन पर एक नज़र डालें।

सिस्टम वेरिएबल

MySQL में बहुत सारे वेरिएबल्स हैं जिन्हें आप बदलने पर विचार कर सकते हैं। कुछ चर गतिशील होते हैं, जिसका अर्थ है कि उन्हें SET कथन का उपयोग करके सेट किया जा सकता है। कॉन्फ़िगरेशन फ़ाइल (उदा. /etc/my.cnf, etc/mysql/my.cnf) में सेट होने के बाद दूसरों को सर्वर पुनरारंभ की आवश्यकता होती है। हालांकि, मैं उन सामान्य चीजों पर चर्चा करूंगा जो सर्वर को अनुकूलित करने के लिए ट्यून करने के लिए काफी सामान्य हैं।

सॉर्ट_बफ़र_साइज़

यह चर नियंत्रित करता है कि आपका फाइलसॉर्ट बफर कितना बड़ा है, जिसका अर्थ है कि जब भी किसी क्वेरी को पंक्तियों को क्रमबद्ध करने की आवश्यकता होती है, तो इस चर के मान का उपयोग उस आकार को सीमित करने के लिए किया जाता है जिसे आवंटित करने की आवश्यकता होती है। ध्यान दें कि यह चर प्रति-क्वेरी है जो संसाधित (या प्रति-कनेक्शन) आधार पर है, जिसका अर्थ है कि जब आप इसे उच्च सेट करते हैं तो यह एक मेमोरी भूखा होगा और यदि आपके पास एकाधिक कनेक्शन हैं जिन्हें आपकी पंक्तियों को सॉर्ट करने की आवश्यकता है। हालाँकि, आप वैश्विक स्थिति चर Sort_merge_passes की जाँच करके अपनी आवश्यकताओं की निगरानी कर सकते हैं। यदि यह मान बड़ा है, तो आपको सॉर्ट_बफ़र_साइज़ सिस्टम चर के मान को बढ़ाने पर विचार करना चाहिए। अन्यथा, इसे उस मध्यम सीमा तक ले जाएं जिसकी आपको आवश्यकता है। यदि आप इसे बहुत कम सेट करते हैं या यदि आपके पास संसाधित करने के लिए बड़ी क्वेरी हैं, तो आपकी पंक्तियों को सॉर्ट करने का प्रभाव अपेक्षा से धीमा हो सकता है क्योंकि डेटा को डिस्क डाइव करते हुए बेतरतीब ढंग से पुनर्प्राप्त किया जाता है। यह प्रदर्शन में गिरावट का कारण बन सकता है। हालांकि, अपने प्रश्नों को ठीक करना सबसे अच्छा है। अन्यथा, यदि आपका एप्लिकेशन बड़े प्रश्नों को खींचने के लिए डिज़ाइन किया गया है और सॉर्टिंग की आवश्यकता है, तो यह उन टूल का उपयोग करने में कुशल है जो रेडिस जैसे क्वेरी कैशिंग को संभालते हैं। डिफ़ॉल्ट रूप से, MySQL 8.0 में, वर्तमान मान सेट 256 KiB है। इसे उसी के अनुसार सेट करें जब आपके पास ऐसे प्रश्न हों जो अत्यधिक उपयोग या कॉलिंग प्रकार हैं।

read_buffer_size

MySQL प्रलेखन में उल्लेख किया गया है कि प्रत्येक अनुरोध के लिए जो एक तालिका का अनुक्रमिक स्कैन करता है, यह एक पठन बफर आवंटित करता है। read_buffer_size सिस्टम चर बफर आकार निर्धारित करता है। यह MyISAM के लिए भी उपयोगी है, लेकिन यह चर सभी स्टोरेज इंजनों को भी प्रभावित करता है। मेमोरी टेबल के लिए, इसका उपयोग मेमोरी ब्लॉक के आकार को निर्धारित करने के लिए किया जाता है।

मूल रूप से, प्रत्येक थ्रेड जो एक MyISAM तालिका के लिए अनुक्रमिक स्कैन करता है, इस आकार का एक बफर आवंटित करता है (बाइट्स में) प्रत्येक तालिका के लिए यह स्कैन करता है। यह सभी स्टोरेज इंजन (जिसमें InnoDB शामिल है) के लिए भी लागू होता है, इसलिए यह उन प्रश्नों के लिए मददगार है जो ORDER BY का उपयोग करके पंक्तियों को सॉर्ट कर रहे हैं और एक अस्थायी फ़ाइल में इसकी अनुक्रमणिका को कैशिंग कर रहे हैं। यदि आप कई अनुक्रमिक स्कैन करते हैं, विभाजन तालिका में बल्क इंसर्ट करते हैं, नेस्टेड क्वेरी के परिणाम कैशिंग करते हैं, तो इसके मान को बढ़ाने पर विचार करें। इस वेरिएबल का मान 4KB का गुणज होना चाहिए। यदि इसे किसी ऐसे मान पर सेट किया जाता है जो 4KB का गुणज नहीं है, तो इसका मान 4KB के निकटतम गुणज में पूर्णांकित कर दिया जाएगा। ध्यान रखें कि इसे उच्च मान पर सेट करने से आपके सर्वर की मेमोरी का एक बड़ा हिस्सा खर्च हो जाएगा। मेरा सुझाव है कि अपने परिवेश की उचित बेंचमार्किंग और निगरानी के बिना इसका उपयोग न करें।

read_rnd_buffer_size

यह चर एक कुंजी-सॉर्टिंग ऑपरेशन के बाद क्रमबद्ध क्रम में MyISAM तालिका से पंक्तियों को पढ़ने से संबंधित है, डिस्क की तलाश से बचने के लिए पंक्तियों को इस बफर के माध्यम से पढ़ा जाता है। दस्तावेज़ीकरण कहता है, जब एक कुंजी-सॉर्टिंग ऑपरेशन के बाद एक मनमाने क्रम में या MyISAM तालिका से पंक्तियों को क्रमबद्ध क्रम में पढ़ते हैं, तो डिस्क की तलाश से बचने के लिए पंक्तियों को इस बफर (और इस बफर आकार के माध्यम से निर्धारित) के माध्यम से पढ़ा जाता है। वेरिएबल को बड़े मान पर सेट करने से ORDER BY प्रदर्शन में काफी सुधार हो सकता है। हालांकि, यह प्रत्येक क्लाइंट के लिए आवंटित बफर है, इसलिए आपको वैश्विक चर को बड़े मान पर सेट नहीं करना चाहिए। इसके बजाय, सत्र चर को केवल उन क्लाइंट के भीतर से बदलें जिन्हें बड़ी क्वेरी चलाने की आवश्यकता है। हालांकि, आपको यह ध्यान रखना चाहिए कि यह मारियाडीबी पर लागू नहीं होता है, खासकर जब एमआरआर का लाभ उठाते हैं। मारियाडीबी mrr_buffer_size का उपयोग करता है जबकि MySQL read_buffer_size read_rnd_buffer_size का उपयोग करता है।

join_buffer_size

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

max_heap_table_size

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

tmp_table_size

अस्थायी तालिकाओं के लिए सबसे बड़ा आकार इन-मेमोरी (मेमोरी टेबल नहीं) हालांकि अगर max_heap_table_size छोटा है तो निचली सीमा लागू होगी। यदि इन-मेमोरी अस्थायी तालिका सीमा से अधिक है, तो MySQL स्वचालित रूप से इसे ऑन-डिस्क अस्थायी तालिका में परिवर्तित कर देता है। tmp_table_size (और यदि आवश्यक हो तो max_heap_table_size) का मान बढ़ाएँ यदि आप कई उन्नत GROUP BY प्रश्न करते हैं और आपके पास बड़ी उपलब्ध मेमोरी स्पेस है। आप Created_tmp_disk_tables और Created_tmp_tables वैरिएबल के मानों की तुलना करके बनाई गई आंतरिक ऑन-डिस्क अस्थायी तालिकाओं की संख्या की तुलना आंतरिक अस्थायी तालिकाओं की कुल संख्या से कर सकते हैं। ClusterControl में, आप डैशबोर्ड -> अस्थायी ऑब्जेक्ट ग्राफ़ के माध्यम से इसकी निगरानी कर सकते हैं।

table_open_cache

आप इस चर के मान को बढ़ा सकते हैं यदि आपके पास बड़ी संख्या में टेबल हैं जो आपके डेटा सेट में अक्सर एक्सेस की जाती हैं। यह सभी थ्रेड्स के लिए लागू किया जाएगा, अर्थात प्रति कनेक्शन के आधार पर। मान इंगित करता है कि सर्वर किसी एक टेबल कैश इंस्टेंस में अधिकतम कितनी टेबल खोल सकता है। हालांकि इस मान को बढ़ाने से mysqld के लिए आवश्यक फ़ाइल डिस्क्रिप्टर की संख्या बढ़ जाती है, इसलिए आप अपने open_files_limit मान की जाँच करने पर विचार कर सकते हैं या जाँच सकते हैं कि आपके *nix ऑपरेटिंग सिस्टम में SOFT और HARD की सीमा कितनी बड़ी है। आप इस पर नजर रख सकते हैं कि क्या आपको Opened_tables स्थिति चर की जाँच करके तालिका कैश बढ़ाने की आवश्यकता है। यदि Opened_tables का मान बड़ा है और आप अक्सर FLUSH TABLES का उपयोग नहीं करते हैं (जो सभी तालिकाओं को बंद करने और फिर से खोलने के लिए बाध्य करता है), तो आपको table_open_cache चर का मान बढ़ाना चाहिए। यदि आपके पास table_open_cache के लिए एक छोटा मान है, और बड़ी संख्या में तालिकाओं का अक्सर उपयोग किया जाता है, तो यह आपके सर्वर के प्रदर्शन को प्रभावित कर सकता है। यदि आप "ओपनिंग टेबल" या "क्लोजिंग टेबल" स्थिति के साथ MySQL प्रक्रिया सूची में कई प्रविष्टियाँ देखते हैं, तो इस चर के मान को समायोजित करने का समय आ गया है, लेकिन पहले बताई गई चेतावनी पर ध्यान दें। ClusterControl में, आप इसे डैशबोर्ड -> टेबल ओपन कैशे स्टेटस या डैशबोर्ड -> ओपन टेबल्स के तहत देख सकते हैं। अधिक जानकारी के लिए आप इसे यहां देख सकते हैं।

table_open_cache_instances

इस चर को सेट करने से मापनीयता में सुधार करने में मदद मिलेगी, और निश्चित रूप से, प्रदर्शन जो सत्रों के बीच विवाद को कम करेगा। आपके द्वारा यहां सेट किया गया मान ओपन टेबल कैश इंस्टेंस की संख्या को सीमित करता है। खुले टेबल कैश को आकार के कई छोटे कैश उदाहरणों में विभाजित किया जा सकता है table_open_cache / table_open_cache_instances । एक सत्र को डीएमएल स्टेटमेंट के लिए इसे एक्सेस करने के लिए केवल एक इंस्टेंस को लॉक करने की आवश्यकता होती है। यह सेगमेंट एक्सेस को उदाहरणों के बीच कैश करता है, जिससे कई सत्र एक्सेस टेबल होने पर कैश का उपयोग करने वाले संचालन के लिए उच्च प्रदर्शन की अनुमति मिलती है। (डीडीएल स्टेटमेंट को अभी भी पूरे कैश पर लॉक की आवश्यकता होती है, लेकिन ऐसे स्टेटमेंट डीएमएल स्टेटमेंट की तुलना में बहुत कम होते हैं।) सिस्टम पर 8 या 16 के मान की सिफारिश की जाती है जो नियमित रूप से 16 या अधिक कोर का उपयोग करते हैं।

table_definition_cache

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

The number of user-defined tables + 10% unless 50K+ tables

लेकिन ध्यान दें कि डिफ़ॉल्ट मान 2000 की सीमा तक सीमित निम्न सूत्र पर आधारित है।

MIN(400 + table_open_cache / 2, 2000)

इसलिए यदि आपके पास डिफ़ॉल्ट की तुलना में बड़ी संख्या में टेबल हैं, तो यह उचित है कि आप इसका मूल्य बढ़ा दें। ध्यान रखें कि InnoDB के साथ, इस चर का उपयोग डेटा डिक्शनरी कैश के लिए ओपन टेबल इंस्टेंस की संख्या की एक नरम सीमा के रूप में किया जाता है। इस चर के वर्तमान मूल्य से अधिक होने पर यह LRU तंत्र को लागू करेगा। सीमा पता स्थितियों में मदद करती है जिसमें अगले सर्वर के पुनरारंभ होने तक शायद ही कभी उपयोग किए गए टेबल इंस्टेंस को कैश करने के लिए महत्वपूर्ण मात्रा में मेमोरी का उपयोग किया जाएगा। इसलिए, विदेशी कुंजी संबंधों के साथ पैरेंट और चाइल्ड टेबल इंस्टेंस को LRU सूची में नहीं रखा गया है और यह table_definition_cache द्वारा परिभाषित सीमा से अधिक लगा सकता है और LRU के दौरान मेमोरी में बेदखली के अधीन नहीं हैं। इसके अतिरिक्त, table_definition_cache InnoDB फ़ाइल-प्रति-तालिका तालिकाओं की संख्या के लिए एक नरम सीमा को परिभाषित करता है जो एक समय में खुली हो सकती है, जिसे innodb_open_files द्वारा भी नियंत्रित किया जाता है और वास्तव में, इन चरों के बीच उच्चतम सेटिंग का उपयोग किया जाता है, यदि दोनों सेट हैं . यदि कोई भी चर सेट नहीं है, तो table_definition_cache, जिसका डिफ़ॉल्ट मान अधिक है, का उपयोग किया जाता है। यदि खुले टेबलस्पेस फ़ाइल हैंडल की संख्या table_definition_cache या innodb_open_files द्वारा परिभाषित सीमा से अधिक है, तो LRU तंत्र पूरी तरह से फ़्लश की गई फ़ाइलों के लिए टेबलस्पेस फ़ाइल LRU सूची की खोज करता है और वर्तमान में विस्तारित नहीं किया जा रहा है। यह प्रक्रिया हर बार एक नया टेबलस्पेस खोले जाने पर की जाती है। यदि कोई "निष्क्रिय" टेबलस्पेस नहीं है, तो कोई टेबलस्पेस फाइल बंद नहीं होती है। तो इसे ध्यान में रखें।

max_allowed_packet

यह प्रति-कनेक्शन किसी SQL क्वेरी या वापस की गई पंक्ति का अधिकतम आकार है। मान को पिछली बार MySQL 5.6 में बढ़ाया गया था। हालाँकि MySQL 8.0 (कम से कम 8.0.3 पर) में, वर्तमान डिफ़ॉल्ट मान 64 MiB है। आप इसे समायोजित करने पर विचार कर सकते हैं यदि आपके पास बड़ी BLOB पंक्तियाँ हैं जिन्हें बाहर निकालने (या पढ़ने) की आवश्यकता है, अन्यथा आप इस डिफ़ॉल्ट सेटिंग्स को 8.0 के साथ छोड़ सकते हैं, लेकिन पुराने संस्करणों में, डिफ़ॉल्ट 4 MiB है, इसलिए आप इसका ध्यान रख सकते हैं। ER_NET_PACKET_TOO_LARGE त्रुटि का सामना करें। MySQL 8.0 सर्वर या क्लाइंट को या उससे प्रेषित किया जा सकने वाला सबसे बड़ा संभावित पैकेट 1GB है।

अधिकतम_कनेक्शन

यह आपके MySQL सर्वर के लिए अनुमत कनेक्शनों की संख्या है। यदि आपको MySQL 'बहुत सारे कनेक्शन' में त्रुटि मिलती है, तो आप इसे उच्चतर सेट करने पर विचार कर सकते हैं। डिफ़ॉल्ट रूप से, 151 का मान विशेष रूप से उत्पादन डेटाबेस पर पर्याप्त नहीं है, और यह देखते हुए कि आपके पास सर्वर के अधिक संसाधन हैं (अपने सर्वर संसाधनों को बर्बाद न करें, खासकर यदि यह एक समर्पित MySQL सर्वर है)। हालाँकि, आपके पास पर्याप्त फ़ाइल डिस्क्रिप्टर होने चाहिए अन्यथा आप उनमें से समाप्त हो जाएंगे। उस स्थिति में, अपने *nix ऑपरेटिंग सिस्टम की अपनी SOFT और HARD सीमा को समायोजित करने पर विचार करें और MySQL में open_files_limit का उच्च मान सेट करें (5000 डिफ़ॉल्ट सीमा है)। ध्यान रखें कि यह बहुत बार होता है कि एप्लिकेशन डेटाबेस से कनेक्शन को सही ढंग से बंद नहीं करता है, और एक उच्च max_connections सेट करने से आपके सर्वर का कुछ अनुत्तरदायी या उच्च लोड हो सकता है। एप्लिकेशन स्तर पर कनेक्शन पूल का उपयोग करने से यहां समस्या को हल करने में मदद मिल सकती है।

thread_cache_size

अत्यधिक थ्रेड निर्माण को रोकने के लिए यह कैश है। जब कोई क्लाइंट डिस्कनेक्ट करता है, तो क्लाइंट के थ्रेड कैश में डाल दिए जाते हैं यदि वहां थ्रेड_कैश_साइज़ थ्रेड से कम हैं। यदि संभव हो तो कैश से लिए गए थ्रेड्स का पुन:उपयोग करके थ्रेड के लिए अनुरोध संतुष्ट होते हैं, और केवल जब कैश खाली होता है तो एक नया थ्रेड बनाया जाता है। यदि आपके पास बहुत से नए कनेक्शन हैं, तो प्रदर्शन को बेहतर बनाने के लिए इस चर को बढ़ाया जा सकता है। आम तौर पर, यदि आपके पास अच्छा थ्रेड कार्यान्वयन है तो यह उल्लेखनीय प्रदर्शन सुधार प्रदान नहीं करता है। हालाँकि, यदि आपका सर्वर प्रति सेकंड सैकड़ों कनेक्शन देखता है, तो आपको सामान्य रूप से पर्याप्त थ्रेड_कैश_साइज़ सेट करना चाहिए ताकि अधिकांश नए कनेक्शन कैश्ड थ्रेड्स का उपयोग करें। कनेक्शन और थ्रेड_क्रिएटेड स्थिति चर के बीच अंतर की जांच करके, आप देख सकते हैं कि थ्रेड कैश कितना कुशल है। दस्तावेज़ीकरण में बताए गए सूत्र का उपयोग करना, 8+ (max_connections / 100) काफी अच्छा है।

query_cache_size

कुछ सेटअप के लिए, यह चर उनका सबसे बड़ा दुश्मन है। कुछ सिस्टम के लिए जो उच्च लोड का अनुभव कर रहे हैं और उच्च रीड में व्यस्त हैं, यह चर आपको नीचे गिरा देगा। ऐसे बेंचमार्क रहे हैं जिन्हें पेरकोना द्वारा अच्छी तरह से और परीक्षण किया गया था। इसे बंद करने के लिए इस चर को query_cache_type =0 के साथ-साथ 0 पर सेट किया जाना चाहिए। MySQL 8.0 में अच्छी खबर यह है कि, MySQL टीम ने इसका समर्थन करना बंद कर दिया है, क्योंकि यह चर वास्तव में प्रदर्शन समस्याओं का कारण बन सकता है। मुझे उनके ब्लॉग पर सहमत होना होगा कि प्रदर्शन की भविष्यवाणी में सुधार की संभावना नहीं है। यदि आप क्वेरी कैशिंग का उपयोग करने के लिए लगे हुए हैं, तो मेरा सुझाव है कि आप Redis या ProxySQL का उपयोग करें।

स्टोरेज इंजन - InnoDB

InnoDB एक एसीआईडी-संगत स्टोरेज इंजन है जिसमें विदेशी कुंजी समर्थन (डिक्लेरेटिव रेफरेंशियल इंटीग्रिटी) के साथ-साथ विभिन्न सुविधाओं की पेशकश की जाती है। यहां कहने के लिए बहुत सी बातें हैं लेकिन ट्यूनिंग के लिए विचार करने के लिए कुछ चर हैं:

innodb_buffer_pool_size

यह चर MyISAM के एक प्रमुख बफर की तरह कार्य करता है लेकिन इसमें बहुत सी चीजें हैं। चूंकि InnoDB बफर पूल पर बहुत अधिक निर्भर करता है, इसलिए आप इस मान को अपने सर्वर की मेमोरी के 70% -80% पर सेट करने पर विचार करेंगे। यह भी अनुकूल है कि आपके पास अपने डेटा सेट की तुलना में एक बड़ा मेमोरी स्पेस है, और अपने बफर पूल के लिए एक उच्च मूल्य निर्धारित करना है, लेकिन बहुत अधिक नहीं। ClusterControl में, हमारे डैशबोर्ड -> InnoDB मेट्रिक्स -> InnoDB बफर पूल पेज ग्राफ़ का उपयोग करके इसकी निगरानी की जा सकती है। आप Innodb_buffer_pool_pages* वेरिएबल का उपयोग करके SHOW GLOBAL STATUS के साथ भी इसकी निगरानी कर सकते हैं।

innodb_buffer_pool_instances

आपके समवर्ती कार्यभार के लिए, इस चर को सेट करने से संगामिति में सुधार हो सकता है और कैश्ड पृष्ठों पर पढ़ने/लिखने के विभिन्न थ्रेड्स के रूप में विवाद कम हो सकता है। न्यूनतम innodb_buffer_pool_instances 1 (न्यूनतम) और 64 (अधिकतम) के बीच होना चाहिए। बफ़र पूल में संग्रहीत या पढ़े जाने वाले प्रत्येक पृष्ठ को हैशिंग फ़ंक्शन का उपयोग करके बेतरतीब ढंग से बफ़र पूल इंस्टेंस में से एक को असाइन किया जाता है। प्रत्येक बफर पूल अपनी स्वयं की मुफ्त सूचियों, फ्लश सूचियों, एलआरयू, और बफर पूल से जुड़े अन्य सभी डेटा संरचनाओं का प्रबंधन करता है, और अपने स्वयं के बफर पूल म्यूटेक्स द्वारा संरक्षित है। ध्यान दें कि यह विकल्प तभी प्रभावी होता है जब innodb_buffer_pool_size>=1GiB और इसके आकार को बफ़र पूल इंस्टेंस के बीच विभाजित किया जाता है।

innodb_log_file_size

यह चर एक लॉग समूह में लॉग फ़ाइल है। लॉग फ़ाइलों का संयुक्त आकार (innodb_log_file_size * innodb_log_files_in_group) अधिकतम मान से अधिक नहीं हो सकता जो 512GB से थोड़ा कम हो। वादिम के अनुसार, एक बड़ा लॉग फ़ाइल आकार प्रदर्शन के लिए बेहतर है, लेकिन इसमें एक खामी (एक महत्वपूर्ण) है जिसके बारे में आपको चिंता करने की आवश्यकता है:दुर्घटना के बाद पुनर्प्राप्ति समय। चरम संचालन के दौरान अधिकतम थ्रूपुट बनाम क्रैश पुनर्प्राप्ति की दुर्लभ घटना में आपको पुनर्प्राप्ति समय को संतुलित करने की आवश्यकता है। यह सीमा 20x लंबी क्रैश पुनर्प्राप्ति प्रक्रिया में बदल सकती है!

इसे विस्तृत करने के लिए, InnoDB लेनदेन लॉग के लिए एक बड़ा मूल्य अच्छा होगा और अच्छे और स्थिर लेखन प्रदर्शन के लिए महत्वपूर्ण हैं। मूल्य जितना बड़ा होगा, बफर पूल में कम चेकपॉइंट फ्लश गतिविधि की आवश्यकता होती है, डिस्क I/O को सहेजना। हालाँकि, आपका डेटाबेस असामान्य रूप से बंद हो जाने के बाद पुनर्प्राप्ति प्रक्रिया बहुत धीमी है (दुर्घटना या मारे गए, या तो OOM या आकस्मिक)। आदर्श रूप से, आपके पास उत्पादन में 1-2GiB हो सकता है लेकिन निश्चित रूप से आप इसे समायोजित कर सकते हैं। इस बदलाव को बेंचमार्क करना एक बड़ा फायदा हो सकता है यह देखने के लिए कि यह विशेष रूप से क्रैश के दौरान कैसा प्रदर्शन करता है।

innodb_log_buffer_size

डिस्क I/O को बचाने के लिए, InnoDB परिवर्तन डेटा को lt के लॉग बफर में लिखता है और यह innodb_log_buffer_size के मान का उपयोग करता है जिसका डिफ़ॉल्ट मान 8MiB है। यह विशेष रूप से बड़े लेनदेन के लिए फायदेमंद है क्योंकि इसे लेन-देन करने से पहले डिस्क में परिवर्तनों का लॉग लिखने की आवश्यकता नहीं होती है। यदि आपका लिखने का ट्रैफ़िक बहुत अधिक है (सम्मिलित करता है, हटाता है, अपडेट करता है), तो बफर को बड़ा करने से डिस्क I/O की बचत होती है।

innodb_flush_log_at_trx_commit

जब innodb_flush_log_at_trx_commit को 1 पर सेट किया जाता है, तो लॉग बफर डिस्क पर लॉग फ़ाइल के लिए प्रतिबद्ध प्रत्येक लेनदेन पर फ्लश हो जाता है और अधिकतम डेटा अखंडता प्रदान करता है लेकिन इसका प्रदर्शन प्रभाव भी होता है। इसे 2 पर सेट करने का मतलब है कि लॉग बफर को हर ट्रांजैक्शन कमिट पर OS फाइल कैश में फ्लश कर दिया जाता है। 2 का निहितार्थ इष्टतम है और यदि आप अपनी ACID आवश्यकताओं को शिथिल कर सकते हैं, और OS क्रैश होने की स्थिति में अंतिम या दो के लिए लेन-देन खोने का जोखिम उठा सकते हैं तो प्रदर्शन में सुधार होता है।

innodb_thread_concurrency

InnoDB इंजन में सुधार के साथ, यह अनुशंसा की जाती है कि इंजन को डिफ़ॉल्ट मान (जो शून्य है) पर रखकर समवर्ती को नियंत्रित करने की अनुमति दी जाए। यदि आप समवर्ती मुद्दों को देखते हैं, तो आप इस चर को ट्यून कर सकते हैं। अनुशंसित मान CPU की संख्या और डिस्क की संख्या का 2 गुना है। यह गतिशील चर का अर्थ है कि यह MySQL सर्वर को पुनरारंभ किए बिना सेट कर सकता है।

innodb_flush_method

हालांकि इस चर को आजमाया जाना चाहिए और परीक्षण किया जाना चाहिए कि कौन सा हार्डवेयर आपको सबसे अच्छा लगता है। यदि आप बैटरी-समर्थित कैश के साथ RAID का उपयोग कर रहे हैं, तो DIRECT_IO I/O दबाव को कम करने में मदद करता है। डायरेक्ट I/O कैश नहीं है इसलिए यह बफर पूल और फाइल सिस्टम कैश के साथ डबल बफरिंग से बचा जाता है। यदि आपकी डिस्क SAN में संग्रहीत है, तो O_DSYNC अधिक से अधिक SELECT कथनों के साथ पढ़ने-भारी कार्यभार के लिए तेज़ हो सकता है।

innodb_file_per_table

innodb_file_per_table MySQL 5.6 से डिफ़ॉल्ट रूप से चालू है। आमतौर पर इसकी अनुशंसा की जाती है क्योंकि यह एक विशाल साझा तालिका स्थान से बचा जाता है और जब आप किसी तालिका को छोड़ते या काटते हैं तो यह आपको स्थान पुनः प्राप्त करने की अनुमति देता है। एक्स्ट्राबैकअप आंशिक बैकअप योजना के लिए अलग टेबलस्पेस भी लाभ देता है।

innodb_stats_on_metadata

यह गंदे पृष्ठों के प्रतिशत को नियंत्रण में रखने का प्रयास करता है, और इनोडब प्लगइन से पहले, यह वास्तव में गंदे बफर फ्लशिंग को ट्यून करने का एकमात्र तरीका था। हालाँकि, मैंने 3% गंदे बफ़र्स वाले सर्वर देखे हैं और वे अपनी अधिकतम चेकपॉइंट आयु को मार रहे हैं। जिस तरह से यह गंदे बफर फ्लशिंग को बढ़ाता है वह उच्च io सबसिस्टम पर भी अच्छी तरह से स्केल नहीं करता है, यह प्रभावी रूप से प्रति सेकंड गंदे बफर फ्लशिंग को दोगुना कर देता है जब% गंदे पृष्ठ इस राशि से अधिक हो जाते हैं।

innodb_io_क्षमता

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

innodb_write_io_threads

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

innodb_adaptive_flushing

निर्दिष्ट करता है कि कार्यभार के आधार पर InnoDB बफर पूल में गंदे पृष्ठों को फ्लश करने की दर को गतिशील रूप से समायोजित करना है या नहीं। फ्लश दर को गतिशील रूप से समायोजित करने का उद्देश्य I/O गतिविधि के फटने से बचना है। आमतौर पर, यह डिफ़ॉल्ट रूप से सक्षम होता है। सक्षम होने पर यह चर, गंदे पृष्ठों की संख्या और लेन-देन लॉग वृद्धि की दर के आधार पर अधिक आक्रामक तरीके से फ़्लश करने के बारे में होशियार होने का प्रयास करता है।

innodb_dedicated_server

यह वैरिएबल MySQL 8.0 में नया है जिसे वैश्विक स्तर पर लागू किया जाता है और इसके लिए MySQL रीस्टार्ट की आवश्यकता होती है क्योंकि यह डायनेमिक वैरिएबल नहीं है। हालाँकि, जैसा कि प्रलेखन में कहा गया है कि यह चर केवल तभी सक्षम होना चाहता है जब आपका MySQL एक समर्पित सर्वर पर चल रहा हो। अन्यथा, इसे किसी साझा होस्ट पर सक्षम न करें या अन्य अनुप्रयोगों के साथ सिस्टम संसाधनों को साझा न करें। जब इसे सक्षम किया जाता है, तो InnoDB चर के लिए खोजी गई मेमोरी की मात्रा के लिए एक स्वचालित कॉन्फ़िगरेशन करेगा innodb_buffer_pool_size, innodb_log_file_size, innodb_flush_method। केवल नकारात्मक पक्ष यह है कि आपके पास बताए गए चरों पर अपने वांछित मूल्यों को लागू करने की व्यवहार्यता नहीं हो सकती है।

MyISAM

key_buffer_size

InnoDB अब MySQL का डिफॉल्ट स्टोरेज इंजन है, key_buffer_size के लिए डिफॉल्ट शायद तब तक कम किया जा सकता है जब तक कि आप MyISAM को अपने एप्लिकेशन के हिस्से के रूप में उत्पादक रूप से उपयोग नहीं कर रहे हैं (लेकिन अब उत्पादन में MyISAM का उपयोग कौन करता है?) यदि आपके पास बड़ी मेमोरी है और शेष मेमोरी को अपने OS कैश और InnoDB बफर पूल के लिए समर्पित करते हैं, तो मैं शुरुआत में शायद 1% RAM या 256 MiB सेट करने का सुझाव दूंगा।

प्रदर्शन के लिए अन्य प्रावधान

slow_query_log

बेशक, यह चर आपके MySQL सर्वर को बढ़ावा देने में मदद नहीं करता है। हालांकि, यह वेरिएबल धीमी प्रदर्शन करने वाली क्वेरी का विश्लेषण करने में आपकी सहायता कर सकता है। लॉगिंग को अक्षम करने के लिए मान को 0 या बंद पर सेट किया जा सकता है। इसे सक्षम करने के लिए इसे 1 या चालू पर सेट करना। डिफ़ॉल्ट मान इस पर निर्भर करता है कि --slow_query_log विकल्प दिया गया है या नहीं। लॉग आउटपुट के लिए गंतव्य को log_output सिस्टम चर द्वारा नियंत्रित किया जाता है; यदि वह मान कोई नहीं है, तो लॉग सक्षम होने पर भी कोई लॉग प्रविष्टियाँ नहीं लिखी जाती हैं। आप वेरिएबल slow_query_log_file को सेट करके क्वेरी लॉग फ़ाइल का फ़ाइल नाम या गंतव्य सेट कर सकते हैं।

long_query_time

यदि कोई क्वेरी कई सेकंड से अधिक समय लेती है, तो सर्वर Slow_queries स्थिति चर को बढ़ा देता है। यदि धीमी क्वेरी लॉग सक्षम है, तो धीमी क्वेरी लॉग फ़ाइल में क्वेरी लॉग की जाती है। यह मान वास्तविक समय में मापा जाता है, CPU समय में नहीं, इसलिए एक क्वेरी जो हल्के लोड किए गए सिस्टम पर थ्रेशोल्ड के नीचे है, वह भारी लोड वाले सिस्टम पर थ्रेशोल्ड से ऊपर हो सकती है। long_query_time के न्यूनतम और डिफ़ॉल्ट मान क्रमशः 0 और 10 हैं। यह भी ध्यान रखें कि यदि चर min_examined_row_limit सेट> 0 है, तो यह क्वेरी लॉग नहीं करेगा, भले ही इसमें बहुत अधिक समय लगे, यदि लौटाई गई पंक्तियों की संख्या min_examined_row_limit में निर्धारित मान से कम है।

अपनी धीमी क्वेरी लॉगिंग को ट्यून करने के बारे में अधिक जानकारी के लिए, दस्तावेज़ीकरण यहाँ देखें।

sync_binlog

यह चर नियंत्रित करता है कि MySQL कितनी बार बिनलॉग को डिस्क से सिंक करेगा। डिफ़ॉल्ट रूप से (>=5.7.7), यह 1 पर सेट होता है, जिसका अर्थ है कि लेन-देन करने से पहले यह डिस्क से सिंक हो जाएगा। हालाँकि, यह लिखने की संख्या में वृद्धि के कारण प्रदर्शन पर नकारात्मक प्रभाव डालता है। लेकिन यह सबसे सुरक्षित सेटिंग है यदि आप अपने दासों के साथ सख्ती से एसीआईडी ​​​​अनुपालन चाहते हैं। वैकल्पिक रूप से, आप इसे 0 पर सेट कर सकते हैं यदि आप डिस्क सिंक्रोनाइज़ेशन को अक्षम करना चाहते हैं और समय-समय पर बाइनरी लॉग को डिस्क पर फ्लश करने के लिए ओएस पर भरोसा करते हैं। इसे 1 से ऊपर सेट करने का मतलब है कि बिनलॉग एन बाइनरी लॉग कमिट समूहों को एकत्र करने के बाद डिस्क से सिंक हो गया है, जहां एन> 1 है।

बफर पूल को डंप/पुनर्स्थापित करें

यह बहुत सामान्य बात है कि आपके उत्पादन डेटाबेस को ठंडे प्रारंभ/पुनरारंभ से गर्म होने की आवश्यकता है। पुनरारंभ करने से पहले वर्तमान बफर पूल को डंप करके, यह सामग्री को बफर पूल से बचाएगा और एक बार यह हो जाएगा, यह सामग्री को बफर पूल में वापस लोड करेगा .. इस प्रकार, यह आपके डेटाबेस को वापस गर्म करने की आवश्यकता से बचाता है कैश। ध्यान दें कि, यह संस्करण तब से 5.6 में पेश किया गया था, लेकिन Percona Server 5.5 में यह पहले से ही उपलब्ध है, बस अगर आपको आश्चर्य हो। इस सुविधा को सक्षम करने के लिए, दोनों चर innodb_buffer_pool_dump_at_shutdown =ON और innodb_buffer_pool_load_at_startup =ON पर सेट करें।

हार्डवेयर

अब हम 2019 में हैं, कई नए हार्डवेयर सुधार हुए हैं। आमतौर पर, MySQL को एक विशिष्ट हार्डवेयर की आवश्यकता नहीं होती है, लेकिन यह इस बात पर निर्भर करता है कि आपको डेटाबेस को क्या करने की आवश्यकता है। मुझे उम्मीद है कि आप इस ब्लॉग को नहीं पढ़ रहे हैं क्योंकि आप एक परीक्षण कर रहे हैं यदि यह इंटेल पेंटियम 200 मेगाहर्ट्ज पर चलता है।

सीपीयू के लिए, कई कोर वाले तेज प्रोसेसर कम से कम 5.6 के बाद से सबसे हाल के संस्करणों में MySQL के लिए इष्टतम होंगे। Intel के Xeon/Itanium प्रोसेसर महंगे हो सकते हैं लेकिन स्केलेबल और विश्वसनीय कंप्यूटिंग प्लेटफॉर्म के लिए परीक्षण किए जाते हैं। अमेज़ॅन एआरएम आर्किटेक्चर पर चल रहे अपने ईसी 2 इंस्टेंस को शिपिंग कर रहा है। हालाँकि मैंने व्यक्तिगत रूप से एआरएम आर्किटेक्चर पर MySQL को चलाने या याद करने की कोशिश नहीं की है, लेकिन ऐसे बेंचमार्क हैं जो सालों पहले बनाए गए थे। आधुनिक सीपीयू तापमान, भार और ओएस बिजली बचत नीतियों के आधार पर अपनी आवृत्तियों को ऊपर और नीचे बढ़ा सकते हैं। हालाँकि, एक मौका है कि आपके लिनक्स ओएस में आपकी सीपीयू सेटिंग्स एक अलग गवर्नर के लिए सेट हो। आप निम्न कार्य करके इसे देख सकते हैं या "प्रदर्शन" गवर्नर के साथ सेट कर सकते हैं:

echo performance | sudo tee /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor

मेमोरी के लिए, यह बहुत महत्वपूर्ण है कि आपकी मेमोरी बड़ी हो और आपके डेटासेट के आकार की बराबरी कर सके। सुनिश्चित करें कि आपके पास स्वैपनेस =1 है। आप sysctl की जाँच करके या procfs में फ़ाइल की जाँच करके इसे देख सकते हैं। यह निम्न कार्य करके प्राप्त किया जाता है:

$ sysctl -e vm.swappiness
vm.swappiness = 1

या इसे निम्नानुसार 1 के मान पर सेट करना

$ sudo sysctl vm.swappiness=1
vm.swappiness = 1

आपके मेमोरी प्रबंधन पर विचार करने के लिए एक और बढ़िया बात THP (ट्रांसपेरेंट विशाल पेज) को बंद करने पर विचार कर रही है। अतीत में, मुझे याद है कि हमारे पास सीपीयू उपयोग के साथ कुछ अजीब मुद्दे थे और सोचा था कि यह डिस्क I/O के कारण था। यह पता चला, समस्या कर्नेल खुगेपेजेड थ्रेड के साथ थी जो रनटाइम के दौरान गतिशील रूप से मेमोरी आवंटित करता है। इतना ही नहीं, जब कर्नेल डीफ़्रैग्मेन्टेशन के लिए जाता है, तो आपकी मेमोरी जल्दी से आवंटित हो जाएगी क्योंकि यह इसे THP में भेजती है। मानक HugePages मेमोरी स्टार्टअप पर पूर्व-आवंटित होती है, और रनटाइम के दौरान नहीं बदलती है। आप निम्न कार्य करके इसे सत्यापित और अक्षम कर सकते हैं:

$ cat /sys/kernel/mm/transparent_hugepage/enabled
$ echo "never" > /sys/kernel/mm/transparent_hugepage/enabled

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

ऑपरेटिंग सिस्टम

MySQL पर चलने वाले अधिकांश प्रोडक्शन सिस्टम Linux पर चलते हैं। ऐसा इसलिए है क्योंकि MySQL का लिनक्स पर परीक्षण और बेंचमार्क किया गया था, और लगता है कि यह MySQL इंस्टॉलेशन के लिए वास्तविक मानक है। हालाँकि, निश्चित रूप से, आपको यूनिक्स या विंडोज प्लेटफॉर्म पर इसका उपयोग करने से कोई रोक नहीं सकता है। यह आसान होगा यदि आपके मंच का परीक्षण किया गया है और यदि आप कुछ परेशानी का अनुभव करते हैं तो सहायता के लिए एक विस्तृत समुदाय है। अधिकांश सेटअप आरएचईएल/सेंटोस/फेडोरा और डेबियन/उबंटू सिस्टम पर चलते हैं। AWS में, Amazon का अपना Amazon Linux है, जिसे मैं कुछ लोगों द्वारा उत्पादन में उपयोग किए जाने के रूप में देखता हूं।

अपने सेटअप पर विचार करने के लिए सबसे महत्वपूर्ण यह है कि आपका फाइल सिस्टम या तो XFS या Ext4 का उपयोग कर रहा है। निश्चित रूप से, इन दो फाइल सिस्टमों के बीच पेशेवरों और विपक्ष हैं, लेकिन मैं यहां विवरण में नहीं जाऊंगा। कुछ लोग कहते हैं कि XFS Ext4 से बेहतर प्रदर्शन करता है, लेकिन ऐसी रिपोर्टें भी हैं कि Ext4 XFS से बेहतर प्रदर्शन करता है। ZFS भी एक वैकल्पिक फाइल सिस्टम के लिए एक अच्छे उम्मीदवार के रूप में तस्वीर से बाहर आ रहा है। जर्विन रियल (पेरकोना से) के पास इस पर बहुत अच्छा संसाधन है, आप इस प्रस्तुति को ZFS सम्मेलन के दौरान देख सकते हैं।

बाहरी लिंक

https://developer.okta.com/blog/2015/05/22/tcmalloc

https://www.percona.com/blog/2012/07/05/impact-of-memory-allocators-on-mysql-performance/

https://www.percona.com/live/18/sessions/benchmark-noise-reduction-how-to-configure-your-machines-for-stable-results

https://zfs.datto.com/2018_slides/real.pdf

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/ladbi/disabling-transparent-hugepages.html#GUID-02E9147D-D565-4AF8-B12A-8E6E9F74BEEA