MySQL लॉन्ग रनिंग क्वेरीज़ से निपटना

एक MySQL वातावरण में लंबे समय तक चलने वाले प्रश्न/कथन/लेनदेन कभी-कभी अनिवार्य होते हैं। कुछ मौकों पर, एक लंबे समय तक चलने वाली क्वेरी एक विनाशकारी घटना के लिए उत्प्रेरक हो सकती है। यदि आप अपने डेटाबेस की परवाह करते हैं, तो क्वेरी प्रदर्शन को अनुकूलित करना और लंबे समय तक चलने वाली क्वेरी का पता लगाना नियमित रूप से किया जाना चाहिए। हालांकि जब किसी समूह या क्लस्टर में कई उदाहरण शामिल होते हैं तो चीजें कठिन हो जाती हैं।

कई नोड्स के साथ काम करते समय, हर एक नोड की जांच करने के लिए दोहराए जाने वाले कार्य कुछ ऐसा है जिससे हमें बचना है। ClusterControl प्रश्नों सहित आपके डेटाबेस सर्वर के कई पहलुओं पर नज़र रखता है। ClusterControl कार्यभार का एक केंद्रीकृत दृश्य प्रदान करने के लिए समूह या क्लस्टर में सभी नोड्स से सभी क्वेरी-संबंधित जानकारी एकत्र करता है। कम से कम प्रयास के साथ अपने क्लस्टर को समग्र रूप से समझने का एक शानदार तरीका है।

इस ब्लॉग पोस्ट में, हम आपको दिखाते हैं कि ClusterControl का उपयोग करके MySQL के लंबे समय तक चलने वाले प्रश्नों का पता कैसे लगाया जाए।

क्यों एक प्रश्न अधिक समय लेता है?

सबसे पहले, हमें क्वेरी की प्रकृति को जानना होगा, चाहे वह लंबी चलने वाली हो या छोटी चलने वाली क्वेरी हो। कुछ विश्लेषणात्मक और बैच संचालन लंबे समय तक चलने वाले प्रश्न माने जाते हैं, इसलिए हम उन्हें अभी के लिए छोड़ सकते हैं। साथ ही, तालिका के आकार के आधार पर, ALTER कमांड के साथ तालिका संरचना को संशोधित करना एक लंबा चलने वाला ऑपरेशन हो सकता है।

एक छोटी अवधि के लेन-देन के लिए, इसे जितनी जल्दी हो सके निष्पादित किया जाना चाहिए, आमतौर पर सबसेकंड के मामले में। जितना छोटा उतना अच्छा। यह क्वेरी बेस्ट-प्रैक्टिस नियमों के एक सेट के साथ आता है जिसका उपयोगकर्ताओं को पालन करना होता है, जैसे WHERE या JOIN स्टेटमेंट में उचित इंडेक्सिंग का उपयोग करना, सही स्टोरेज इंजन का उपयोग करना, उचित डेटा प्रकार चुनना, ऑफ-पीक घंटों के दौरान बैच ऑपरेशन को शेड्यूल करना, विश्लेषणात्मक को लोड करना / समर्पित प्रतिकृतियों को ट्रैफ़िक की रिपोर्ट करना, और इसी तरह।

ऐसी कई चीजें हैं जिनके कारण किसी क्वेरी को निष्पादित होने में अधिक समय लग सकता है:

• अक्षम क्वेरी - लुकअप या जॉइन करते समय गैर-अनुक्रमित कॉलम का उपयोग करें, इस प्रकार MySQL को स्थिति से मेल खाने में अधिक समय लगता है।
• टेबल लॉक - जब क्वेरी इसे एक्सेस करने का प्रयास कर रही हो, तो टेबल को ग्लोबल लॉक या स्पष्ट टेबल लॉक द्वारा लॉक किया जाता है।
• डेडलॉक - एक क्वेरी उन्हीं पंक्तियों तक पहुंचने की प्रतीक्षा कर रही है जो किसी अन्य क्वेरी द्वारा लॉक की गई हैं।
• डेटासेट RAM में फ़िट नहीं होता - यदि आपका कार्य सेट डेटा उस कैश में फ़िट हो जाता है, तो SELECT क्वेरीज़ आमतौर पर अपेक्षाकृत तेज़ होंगी।
• उप-इष्टतम हार्डवेयर संसाधन - यह धीमी डिस्क, RAID पुनर्निर्माण, संतृप्त नेटवर्क आदि हो सकता है।
• रखरखाव ऑपरेशन - mysqldump चलाने से बड़ी मात्रा में अन्यथा अप्रयुक्त डेटा बफ़र पूल में आ सकता है, और साथ ही (संभावित रूप से उपयोगी) डेटा जो पहले से मौजूद है उसे निकाल दिया जाएगा और डिस्क पर फ़्लश कर दिया जाएगा।

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

कैसे जांचें?

प्रक्रिया सूची

MySQL लंबे समय तक चलने वाले लेन-देन की जांच के लिए कई अंतर्निहित टूल प्रदान करता है। सबसे पहले, SHOW PROCESSLIST या SHOW FULL PROCESSLIST कमांड वास्तविक समय में चल रहे प्रश्नों को उजागर कर सकते हैं। यहाँ ClusterControl रनिंग क्वेरीज़ फीचर का एक स्क्रीनशॉट है, जो SHOW FULL PROCESSLIST कमांड के समान है (लेकिन ClusterControl क्लस्टर में सभी नोड्स के लिए सभी प्रोसेस को एक व्यू में एग्रीगेट करता है):

जैसा कि आप देख सकते हैं, हम तुरंत आउटपुट से आपत्तिजनक क्वेरी देख सकते हैं। लेकिन हम कितनी बार उन प्रक्रियाओं को देखते हैं? यह तभी उपयोगी है जब आप लंबे समय से चल रहे लेनदेन के बारे में जानते हों। अन्यथा, आपको तब तक पता नहीं चलेगा जब तक कि कुछ न हो जाए - जैसे कनेक्शन जमा हो रहे हैं, या सर्वर सामान्य से धीमा हो रहा है।

धीमी क्वेरी लॉग

धीमी क्वेरी लॉग धीमी क्वेरी को कैप्चर करता है (SQL कथन जो long_query_time से अधिक समय लेते हैं निष्पादित करने के लिए सेकंड), या क्वेरी जो लुकअप के लिए अनुक्रमणिका का उपयोग नहीं करती हैं (log_queries_not_using_indexes ) यह सुविधा डिफ़ॉल्ट रूप से सक्षम नहीं है और इसे सक्षम करने के लिए बस निम्नलिखित पंक्तियों को सेट करें और MySQL सर्वर को पुनरारंभ करें:

[mysqld]
slow_query_log=1
long_query_time=0.1
log_queries_not_using_indexes=1

धीमी क्वेरी लॉग का उपयोग उन प्रश्नों को खोजने के लिए किया जा सकता है जो निष्पादित होने में लंबा समय लेते हैं और इसलिए अनुकूलन के लिए उम्मीदवार हैं। हालाँकि, एक लंबे धीमे क्वेरी लॉग की जाँच करना एक समय लेने वाला कार्य हो सकता है। MySQL धीमी क्वेरी लॉग फ़ाइलों को पार्स करने और उनकी सामग्री को संक्षेप में प्रस्तुत करने के लिए उपकरण हैं जैसे mysqldumpslow, pt-query-digest या ClusterControl Top Queries।

ClusterControl शीर्ष क्वेरीज़ दो विधियों का उपयोग करके धीमी क्वेरी को सारांशित करती है - MySQL धीमी क्वेरी लॉग या प्रदर्शन स्कीमा:

आप सामान्यीकृत स्टेटमेंट डाइजेस्ट का सारांश आसानी से देख सकते हैं, जिसे कई मानदंडों के आधार पर क्रमबद्ध किया गया है:

• होस्ट
• घटनाएं
• कुल निष्पादन समय
• अधिकतम निष्पादन समय
• औसत निष्पादन समय
• मानक विचलन समय

हमने इस ब्लॉग पोस्ट में इस सुविधा को विस्तार से कवर किया है, MySQL, MariaDB और Percona सर्वर के लिए ClusterControl Query Monitor का उपयोग कैसे करें।

प्रदर्शन स्कीमा

प्रदर्शन स्कीमा निम्न स्तर पर MySQL सर्वर आंतरिक और निष्पादन विवरण की निगरानी के लिए उपलब्ध एक महान उपकरण है। धीमी क्वेरी खोजने के लिए प्रदर्शन स्कीमा में निम्न तालिकाओं का उपयोग किया जा सकता है:

• events_statements_current
• events_statements_history
• events_statements_history_long
• events_statements_summary_by_digest
• events_statements_summary_by_user_by_event_name
• events_statements_summary_by_host_by_event_name

MySQL 5.7.7 और उच्चतर में sys स्कीमा शामिल है, वस्तुओं का एक सेट जो DBA और डेवलपर्स को प्रदर्शन स्कीमा द्वारा एकत्र किए गए डेटा को अधिक आसानी से समझने योग्य रूप में व्याख्या करने में मदद करता है। Sys स्कीमा ऑब्जेक्ट का उपयोग विशिष्ट ट्यूनिंग और निदान उपयोग मामलों के लिए किया जा सकता है।

ClusterControl सलाहकार प्रदान करता है, जो मिनी-प्रोग्राम हैं जिन्हें आप ClusterControl DSL (जावास्क्रिप्ट के समान) का उपयोग करके लिख सकते हैं ताकि ClusterControl निगरानी क्षमताओं को आपकी आवश्यकताओं के अनुसार विस्तारित किया जा सके। प्रदर्शन स्कीमा के आधार पर कई स्क्रिप्ट शामिल हैं जिनका उपयोग आप क्वेरी प्रदर्शन की निगरानी के लिए कर सकते हैं जैसे I/O प्रतीक्षा, लॉक प्रतीक्षा समय और इसी तरह। उदाहरण के लिए प्रबंधित करें -> डेवलपर स्टूडियो . के अंतर्गत , s9s -> mysql -> p_s -> top_tables_by_iowait.js पर जाएं और "संकलन और चलाएँ" बटन पर क्लिक करें। आपको प्रति सर्वर I/O प्रतीक्षा द्वारा क्रमबद्ध शीर्ष 10 तालिकाओं के लिए संदेश टैब के अंतर्गत आउटपुट देखना चाहिए:

ऐसी कई स्क्रिप्ट हैं जिनका उपयोग आप निम्न-स्तरीय जानकारी को समझने के लिए कर सकते हैं कि धीमापन कहां और क्यों होता है जैसे top_tables_by_lockwait.js , top_accessed_db_files.js और इसी तरह।

ClusterControl - लंबे समय तक चलने वाली क्वेरी का पता लगाना और सतर्क करना

ClusterControl के साथ, आपको अतिरिक्त शक्तिशाली सुविधाएँ मिलेंगी जो आपको मानक MySQL स्थापना में नहीं मिलेंगी। ClusterControl को चल रही प्रक्रियाओं की लगातार निगरानी करने के लिए कॉन्फ़िगर किया जा सकता है, और एक अलार्म बढ़ा सकता है और उपयोगकर्ता को सूचना भेज सकता है यदि लंबी क्वेरी सीमा पार हो गई है। इसे सेटिंग्स के अंतर्गत रनटाइम कॉन्फ़िगरेशन का उपयोग करके कॉन्फ़िगर किया जा सकता है:

पूर्व 1.7.1 के लिए, query_monitor_alert_long_running_query के लिए डिफ़ॉल्ट मान गलत है। हम उपयोगकर्ता को इसे 1 (सत्य) पर सेट करके इसे सक्षम करने के लिए प्रोत्साहित करते हैं। इसे स्थिर बनाने के लिए, निम्न पंक्ति को /etc/cmon.d/cmon_X.cnf में जोड़ें:

query_monitor_alert_long_running_query=1
query_monitor_long_running_query_ms=30000

रनटाइम कॉन्फ़िगरेशन में किए गए किसी भी परिवर्तन को तुरंत लागू किया जाता है और किसी पुनरारंभ की आवश्यकता नहीं होती है। यदि कोई क्वेरी 30000ms (30 सेकंड) की सीमा से अधिक है, तो आपको अलार्म अनुभाग के अंतर्गत कुछ ऐसा दिखाई देगा:

यदि आप DbComponent प्लस क्रिटिकल गंभीरता श्रेणी के लिए मेल प्राप्तकर्ता सेटिंग्स को "डिलीवर" के रूप में कॉन्फ़िगर करते हैं (जैसा कि निम्नलिखित स्क्रीनशॉट में दिखाया गया है):

आपको इस अलार्म की एक प्रति अपने ईमेल में मिलनी चाहिए। अन्यथा, इसे "ईमेल भेजें" बटन पर क्लिक करके मैन्युअल रूप से अग्रेषित किया जा सकता है।

इसके अलावा, आप किसी भी प्रकार के प्रक्रिया सूची संसाधनों को फ़िल्टर कर सकते हैं जो नियमित अभिव्यक्ति (रेगेक्स) के साथ कुछ मानदंडों से मेल खाते हैं। उदाहरण के लिए, यदि आप चाहते हैं कि ClusterControl 'sbtest', 'myshop' और 'db_user1' नामक तीन MySQL उपयोगकर्ताओं के लिए लंबे समय तक चलने वाली क्वेरी का पता लगाए, तो निम्न कार्य करना चाहिए:

रनटाइम कॉन्फ़िगरेशन में किए गए किसी भी परिवर्तन को तुरंत लागू किया जाता है और किसी पुनरारंभ की आवश्यकता नहीं होती है।

इसके अतिरिक्त, ClusterControl सभी गतिरोध लेनदेन को InnoDB स्थिति के साथ सूचीबद्ध करेगा जब यह प्रदर्शन -> लेनदेन लॉग के अंतर्गत हो रहा था। :

यह सुविधा डिफ़ॉल्ट रूप से सक्षम नहीं है, क्योंकि डेडलॉक डिटेक्शन डेटाबेस नोड्स पर CPU उपयोग को प्रभावित करेगा। इसे सक्षम करने के लिए, बस "लेन-देन लॉग सक्षम करें" चेकबॉक्स पर टिक करें और अपने इच्छित अंतराल को निर्दिष्ट करें। इसे स्थिर बनाने के लिए, /etc/cmon.d/cmon_X.cnf:

db_deadlock_check_interval=30

इसी तरह, यदि आप InnoDB स्थिति देखना चाहते हैं, तो बस प्रदर्शन -> InnoDB स्थिति पर जाएं। , और ड्रॉपडाउन से MySQL सर्वर चुनें। उदाहरण के लिए:

वहाँ हम जाते हैं - सभी आवश्यक जानकारी कुछ ही क्लिक में आसानी से प्राप्त की जा सकती है।

सारांश

लंबे समय तक चलने वाले लेन-देन से प्रदर्शन में गिरावट, सर्वर डाउन, कनेक्शन अधिकतम और गतिरोध हो सकता है। ClusterControl के साथ, आप सीधे UI से लंबे समय तक चलने वाली क्वेरी का पता लगा सकते हैं, क्लस्टर में हर एक MySQL नोड की जांच करने की आवश्यकता के बिना।