मारियाडीबी के लिए डेटाबेस प्रदर्शन ट्यूनिंग

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

इसके बावजूद, मारियाडीबी और माईएसक्यूएल के बीच अभी भी कोई वास्तविक बताने वाला अंतर नहीं है, क्योंकि दोनों में ऐसे इंजन हैं जो संगत हैं और एक दूसरे के साथ मूल रूप से चल सकते हैं। तो आश्चर्यचकित न हों अगर आपके मारियाडीबी सेटअप की ट्यूनिंग में एक ट्यूनिंग MySQL के समान दृष्टिकोण है।

यह ब्लॉग मारियाडीबी की ट्यूनिंग पर चर्चा करेगा, विशेष रूप से वे सिस्टम जो लिनक्स वातावरण में चल रहे हैं।

MariaDB हार्डवेयर और सिस्टम ऑप्टिमाइज़ेशन

MariaDB अनुशंसा करता है कि आप निम्न प्राथमिकता क्रम में अपने हार्डवेयर में सुधार करें...

स्मृति

मेमोरी डेटाबेस के लिए सबसे महत्वपूर्ण कारक है क्योंकि यह आपको सर्वर सिस्टम वेरिएबल को समायोजित करने की अनुमति देता है। अधिक मेमोरी का अर्थ है बड़ी कुंजी और टेबल कैश, जो मेमोरी में संग्रहीत होते हैं ताकि डिस्क एक्सेस कर सकें, परिमाण का एक क्रम धीमा हो जाता है, बाद में कम हो जाता है।

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

मदरबोर्ड पर अधिक RAM स्लॉट का उपयोग करने से बस की आवृत्ति बढ़ जाती है, और RAM और CPU के बीच अधिक विलंबता होगी। इसका मतलब है कि प्रति स्लॉट उच्चतम रैम आकार का उपयोग करना बेहतर है।

डिस्क

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

तेज़ ईथरनेट

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

CPU

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

अपना डिस्क I/O शेड्यूलर सेट करना

I/O शेड्यूलर डिस्क एक्सेस अनुरोधों को अनुकूलित करने के तरीके के रूप में मौजूद हैं। यह डिस्क पर समान स्थानों पर I/O अनुरोधों को मर्ज करता है। इसका मतलब यह है कि डिस्क ड्राइव को बार-बार खोजने की आवश्यकता नहीं है और एक विशाल समग्र प्रतिक्रिया समय में सुधार करता है और डिस्क संचालन को बचाता है। I/O प्रदर्शन के लिए अनुशंसित मान noop और समय सीमा हैं।

noop यह जांचने के लिए उपयोगी है कि क्या अन्य शेड्यूलर्स के जटिल I/O शेड्यूलिंग निर्णय I/O प्रदर्शन प्रतिगमन का कारण नहीं बन रहे हैं। कुछ मामलों में यह उन उपकरणों के लिए मददगार हो सकता है जो I/O शेड्यूलिंग स्वयं करते हैं, जैसे कि बुद्धिमान भंडारण, या ऐसे उपकरण जो यांत्रिक गति पर निर्भर नहीं हैं, जैसे SSDs। आमतौर पर, DEADLINE I/O अनुसूचक इन उपकरणों के लिए एक बेहतर विकल्प है, लेकिन कम ओवरहेड के कारण NOOP कुछ कार्यभार पर बेहतर प्रदर्शन कर सकता है।

समय सीमा के लिए, यह एक विलंबता-उन्मुख I/O अनुसूचक है। प्रत्येक I/O अनुरोध को एक समय सीमा सौंपी गई है। आमतौर पर, अनुरोधों को सेक्टर नंबरों द्वारा क्रमबद्ध कतारों (पढ़ने और लिखने) में संग्रहीत किया जाता है। DEADLINE एल्गोरिथम दो अतिरिक्त कतारों (पढ़ने और लिखने) को बनाए रखता है जहां अनुरोधों को समय सीमा के अनुसार क्रमबद्ध किया जाता है। जब तक कोई अनुरोध समय समाप्त नहीं हो जाता, तब तक "सेक्टर" कतार का उपयोग किया जाता है। यदि टाइमआउट होता है, तो "समय सीमा" कतार से अनुरोध तब तक प्रस्तुत किए जाते हैं जब तक कि कोई और समय समाप्त अनुरोध न हो। आम तौर पर, एल्गोरिथम पढ़ने के बजाय लिखने को तरजीह देता है।

PCIe उपकरणों (NVMe SSD ड्राइव) के लिए, उनके पास तेज सेवा के साथ अपनी बड़ी आंतरिक कतारें होती हैं और I/O अनुसूचक सेट करने की आवश्यकता या लाभ नहीं होता है। यह अनुशंसा की जाती है कि कोई स्पष्ट शेड्यूलर-मोड कॉन्फ़िगरेशन पैरामीटर न हो।

आप इसके साथ अपनी शेड्यूलर सेटिंग की जांच कर सकते हैं:

cat /sys/block/${DEVICE}/queue/scheduler

उदाहरण के लिए, यह इस आउटपुट जैसा दिखना चाहिए:

cat /sys/block/sda/queue/scheduler

[noop] deadline cfq

इसे स्थायी बनाने के लिए, /etc/default/grub कॉन्फ़िगरेशन फ़ाइल को संपादित करें, चर GRUB_CMDLINE_LINUX की तलाश करें और नीचे की तरह लिफ्ट जोड़ें:

GRUB_CMDLINE_LINUX="elevator=noop"

खुली फ़ाइलें सीमा बढ़ाएं

सर्वर का अच्छा प्रदर्शन सुनिश्चित करने के लिए, क्लाइंट कनेक्शन, डेटाबेस फ़ाइलों और लॉग फ़ाइलों की कुल संख्या ऑपरेटिंग सिस्टम (ulimit -n) पर अधिकतम फ़ाइल डिस्क्रिप्टर सीमा से अधिक नहीं होनी चाहिए। लिनक्स सिस्टम फाइल डिस्क्रिप्टर की संख्या को सीमित करता है जो कि कोई एक प्रक्रिया प्रति प्रक्रिया 1,024 तक खुल सकती है। सक्रिय डेटाबेस सर्वर (विशेषकर उत्पादन वाले) पर यह आसानी से डिफ़ॉल्ट सिस्टम सीमा तक पहुँच सकता है।

इसे बढ़ाने के लिए, /etc/security/limits.conf संपादित करें और निम्नलिखित निर्दिष्ट करें या जोड़ें:

mysql soft nofile 65535

mysql hard nofile 65535

इसके लिए सिस्टम पुनरारंभ की आवश्यकता है। बाद में, आप निम्नलिखित को चलाकर पुष्टि कर सकते हैं:

$ ulimit -Sn

65535

$ ulimit -Hn

65535

वैकल्पिक रूप से, यदि आप mysqld_safe के माध्यम से mysqld प्रक्रिया शुरू कर रहे हैं, तो आप इसे mysqld_safe के माध्यम से सेट कर सकते हैं,

[mysqld_safe]

open_files_limit=4294967295

या यदि आप systemd का उपयोग कर रहे हैं,

sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF

[Service]



LimitNOFILE=infinity

EOF

sudo systemctl daemon-reload

MariaDB के लिए Linux पर स्वैपनेस सेट करना

Linux Swap डेटाबेस सिस्टम में एक बड़ी भूमिका निभाता है। यह आपके वाहन में आपके स्पेयर टायर की तरह काम करता है, जब खराब मेमोरी लीक आपके काम में बाधा डालती है, तो मशीन धीमी हो जाएगी...

अपने स्वपन में परिवर्तन लागू करने के लिए, बस दौड़ें,

sysctl -w vm.swappiness=1

यह गतिशील रूप से होता है, सर्वर को रीबूट करने की कोई आवश्यकता नहीं है। इसे स्थायी बनाने के लिए /etc/sysctl.conf संपादित करें और लाइन जोड़ें,

vm.swappiness=1

स्वैपनेस =0 सेट करना बहुत आम है, लेकिन नए कर्नेल (यानी कर्नेल> 2.6.32-303) के जारी होने के बाद से, परिवर्तन किए गए हैं, इसलिए आपको vm.swappiness=1 सेट करने की आवश्यकता है।

मारियाडीबी के लिए फाइलसिस्टम अनुकूलन

MariaDB चलाने वाले Linux वातावरण में उपयोग की जाने वाली सबसे आम फ़ाइल सिस्टम ext4 और XFS हैं। ZFS और BRTFS का उपयोग करके आर्किटेक्चर को लागू करने के लिए कुछ निश्चित सेटअप भी उपलब्ध हैं (जैसा कि MariaDB दस्तावेज़ में संदर्भित है)।

इसके अलावा, अधिकांश डेटाबेस सेटअप को फ़ाइल एक्सेस समय रिकॉर्ड करने की आवश्यकता नहीं होती है। सिस्टम में वॉल्यूम बढ़ाते समय आप इसे अक्षम करना चाह सकते हैं। ऐसा करने के लिए, अपनी फ़ाइल संपादित करें /etc/fstab. उदाहरण के लिए, /dev/md2 नामक वॉल्यूम पर, यह इस तरह दिखता है:

/dev/md2 / ext4 defaults,noatime 0 0

एक इष्टतम मारियाडीबी इंस्टेंस बनाना

डेटा को एक अलग वॉल्यूम में संग्रहित करें

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

मेमोरी का कुशलतापूर्वक उपयोग करने के लिए मारियाडीबी को ट्यूनअप करें

innodb_buffer_pool_size

पूरी तरह/मुख्य रूप से XtraDB/InnoDB तालिकाओं वाले डेटाबेस सर्वर पर समायोजित करने के लिए प्राथमिक मान, इन परिवेशों में कुल मेमोरी का 80% तक सेट किया जा सकता है। यदि 2 जीबी या अधिक पर सेट है, तो आप शायद innodb_buffer_pool_instances को भी समायोजित करना चाहेंगे। यदि आप मारियाडीबी>=10.2.2 संस्करण का उपयोग कर रहे हैं तो आप इसे गतिशील रूप से सेट कर सकते हैं। अन्यथा, इसके लिए सर्वर पुनरारंभ की आवश्यकता होती है।

tmp_memory_table_size/max_heap_table_size

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

जबकि max_heap_table_size,  यह उपयोगकर्ता द्वारा बनाई गई MEMORY तालिकाओं के लिए अधिकतम आकार है। इस वेरिएबल पर सेट किया गया मान केवल नए बनाए गए या फिर से बनाए गए टेबल के लिए लागू होता है न कि मौजूदा के लिए। max_heap_table_size और tmp_table_size से छोटा आंतरिक इन-मेमोरी टेबल को भी सीमित करता है। जब अधिकतम आकार तक पहुँच जाता है, तो डेटा सम्मिलित करने का कोई और प्रयास "तालिका ... पूर्ण है" त्रुटि प्राप्त करेगा। CREATE TEMPORARY के साथ बनाई गई अस्थायी तालिकाओं को Aria में नहीं बदला जाएगा, जैसा कि आंतरिक अस्थायी तालिकाओं के साथ होता है, लेकिन उन्हें एक तालिका पूर्ण त्रुटि भी प्राप्त होगी।

innodb_log_file_size

उच्च गति प्रसंस्करण और तेज़ I/O डिस्क के साथ बड़ी यादें नई नहीं हैं और इसकी उचित कीमत है जैसा कि यह अनुशंसा करता है। यदि आप विशेष रूप से अपने InnoDB लेनदेन के दौरान और अधिक प्रदर्शन लाभ पसंद कर रहे हैं, तो चर innodb_log_file_size को 5Gib या 10GiB जैसे बड़े मान पर सेट करना उचित है। बढ़ाने का मतलब है कि बड़े लेनदेन को करने से पहले डिस्क I/O करने की आवश्यकता के बिना चल सकता है।

join_buffer_size

कुछ मामलों में, आपके प्रश्नों में उचित अनुक्रमण के उपयोग की कमी होती है या बस, ऐसे उदाहरण हैं कि आपको इस क्वेरी को चलाने की आवश्यकता है। तब तक नहीं जब तक कि इसे क्लाइंट के नजरिए से भारी रूप से कॉल या इनवाइट नहीं किया जाता है, इस वेरिएबल को सेट करना सत्र स्तर पर सबसे अच्छा है। इंडेक्स जोड़ना संभव नहीं होने पर तेजी से पूर्ण जुड़ने के लिए इसे बढ़ाएं, हालांकि स्मृति मुद्दों से अवगत रहें, क्योंकि जुड़ने से हमेशा न्यूनतम आकार आवंटित होगा।

अपना max_allowed_packet सेट करें

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

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

थ्रेडपूल का उपयोग करना

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

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

आप थ्रेड की अधिकतम और न्यूनतम संख्या के लिए thread_pool_max_threads, thread_pool_min_threads सेट कर सकते हैं। MySQL के विपरीत, यह केवल MariaDB में मौजूद है।

वेरिएबल थ्रेड_हैंडलिंग सेट करें जो यह निर्धारित करता है कि सर्वर क्लाइंट कनेक्शन के लिए थ्रेड्स को कैसे हैंडल करता है। क्लाइंट कनेक्शन के लिए थ्रेड्स के अलावा, यह कुछ आंतरिक सर्वर थ्रेड्स पर भी लागू होता है, जैसे गैलेरा स्लेव थ्रेड्स।

अपना टेबल कैश ट्यून करें + max_connections

यदि आपको ओपनिंग टेबल और क्लोजिंग टेबल की स्थिति के बारे में प्रक्रिया सूची में कभी-कभार होने वाली घटनाओं का सामना करना पड़ रहा है, तो यह संकेत दे सकता है कि आपको अपना टेबल कैश बढ़ाने की आवश्यकता है। आप 'ओपन% टेबल%' की तरह वैश्विक स्थिति दिखाएँ चलाकर mysql क्लाइंट प्रॉम्प्ट के माध्यम से भी इसकी निगरानी कर सकते हैं; और स्थिति चर की निगरानी करें।

max_connections के लिए, यदि आपको एप्लिकेशन के लिए बहुत सारे समवर्ती कनेक्शन की आवश्यकता है, तो आप इसे 500 पर सेट करना शुरू कर सकते हैं। 

table_open_cache के लिए, यह आपकी तालिकाओं की कुल संख्या होगी, लेकिन यह सबसे अच्छा है कि आप जिस प्रकार की क्वेरी प्रदान करते हैं, उसके आधार पर आप अधिक जोड़ते हैं क्योंकि अस्थायी तालिकाओं को भी कैश किया जाएगा। उदाहरण के लिए, यदि आपके पास 500 टेबल हैं, तो यह उचित होगा कि आप 1500 से शुरू करें। 

अपनी तालिका_ओपन_कैश_इंस्टेंस के दौरान, इसे 8 पर सेट करना प्रारंभ करें। यह सत्रों के बीच विवाद को कम करके मापनीयता में सुधार कर सकता है, खुले टेबल कैश को आकार के कई छोटे कैश उदाहरणों में विभाजित किया जा सकता है table_open_cache / table_open_cache_instances।

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

MIN(400 + table_open_cache / 2, 2000)

यदि ओपन टेबल इंस्टेंस की संख्या टेबल_डेफिनिशन_कैश सेटिंग से अधिक है, तो एलआरयू मैकेनिज्म टेबल इंस्टेंस को बेदखली के लिए चिह्नित करना शुरू कर देता है और अंततः उन्हें डेटा डिक्शनरी कैश से हटा देता है। सीमा पता स्थितियों में मदद करती है जिसमें अगले सर्वर के पुनरारंभ होने तक शायद ही कभी उपयोग किए गए टेबल इंस्टेंस को कैश करने के लिए महत्वपूर्ण मात्रा में मेमोरी का उपयोग किया जाएगा। कैश्ड मेटाडेटा के साथ टेबल इंस्टेंस की संख्या table_definition_cache द्वारा परिभाषित सीमा से अधिक हो सकती है, क्योंकि पैरेंट और चाइल्ड टेबल इंस्टेंस विदेशी कुंजी संबंधों के साथ LRU सूची में नहीं रखे जाते हैं और मेमोरी से निष्कासन के अधीन नहीं होते हैं।

table_open_cache के विपरीत, table_definition_cache फ़ाइल डिस्क्रिप्टर का उपयोग नहीं करता है, और बहुत छोटा है।

क्वेरी कैश से निपटना

अधिमानतः, हम आपके सभी MariaDB सेटअप में क्वेरी कैश को अक्षम करने की अनुशंसा करते हैं। अक्षम क्वेरी कैश को पूरा करने के लिए आपको यह सुनिश्चित करना होगा कि query_cache_type=OFF और query_cache_size=0. MySQL के विपरीत, मारियाडीबी अभी भी पूरी तरह से क्वेरी कैश का समर्थन कर रहा है और क्वेरी कैश का उपयोग करने के लिए इसके समर्थन को वापस लेने की कोई योजना नहीं है। कुछ लोग दावा कर रहे हैं कि क्वेरी कैश अभी भी उनके लिए प्रदर्शन लाभ प्रदान करता है। हालाँकि, Percona The MySQL क्वेरी कैशे की यह पोस्ट:सबसे खराब दुश्मन या सबसे अच्छा दोस्त उस क्वेरी कैश को प्रकट करता है, यदि सक्षम किया जाता है, तो इसका परिणाम ओवरहेड होता है और सर्वर का प्रदर्शन खराब होता है।

यदि आप क्वेरी कैश का उपयोग करना चाहते हैं, तो सुनिश्चित करें कि आप 'Qcache%' की तरह वैश्विक स्थिति दिखाएँ चलाकर अपने क्वेरी कैश की निगरानी करते हैं;। Qcache_inserts में क्वेरी कैश में जोड़े गए प्रश्नों की संख्या होती है, Qcache_hits में क्वेरी कैश का उपयोग करने वाले प्रश्नों की संख्या होती है, जबकि Qcache_lowmem_prunes में मेमोरी की कमी के कारण कैश से हटाए गए प्रश्नों की संख्या होती है। नियत समय में, क्वेरी कैश का उपयोग और सक्षम करना खंडित हो सकता है। Qcache_total_blocks के सापेक्ष एक उच्च Qcache_free_blocks विखंडन का संकेत दे सकता है। इसे डीफ़्रैग्मेन्ट करने के लिए, फ्लश क्वेरी कैश चलाएँ। यह बिना किसी प्रश्न को छोड़े क्वेरी कैश को डीफ़्रैग्मेन्ट कर देगा।

हमेशा अपने सर्वर की निगरानी करें

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

निष्कर्ष

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