लंबे समय तक चलने वाली क्वेरीज़ आपके MySQL डेटाबेस प्रदर्शन के लिए एक गंभीर कांटा हो सकती हैं, जिससे सुस्त प्रतिक्रिया समय से लेकर पूर्ण विकसित बाधाओं तक सब कुछ हो सकता है जो हर उपयोगकर्ता को प्रभावित करता है। इन परेशान करने वाले प्रश्नों पर नियंत्रण पाना—यह जानना कि वे क्या हैं, वे क्यों होते हैं, और उन्हें कैसे प्रबंधित करना है—आपके डेटाबेस को सुचारू रूप से चालू रखने की कुंजी है।
चाहे उन्हें जल्दी पहचानना हो, उन्हें उनके ट्रैक में रोकना हो, या उन्हें स्वचालित रूप से संभालने का कोई तरीका स्थापित करना हो, यह मार्गदर्शिका आपको कवर करेगी।
MySQL में लंबे समय तक चलने वाली क्वेरी एक ऐसी क्वेरी है जिसे निष्पादित होने में असामान्य रूप से लंबी अवधि लगती है।
किसी क्वेरी को "लंबे समय तक चलने वाली" के रूप में वर्गीकृत करने वाली विशिष्ट अवधि आपके एप्लिकेशन के प्रदर्शन मानकों के आधार पर भिन्न हो सकती है। आम तौर पर, यदि कोई क्वेरी सामान्य से अधिक समय तक चल रही है और आपके डेटाबेस को धीमा करना शुरू कर देती है, तो इसे लंबे समय तक चलने वाला माना जाता है।
लंबे समय तक चलने वाली क्वेरी के कारण विविध हो सकते हैं:
उचित अनुक्रमण का अभाव - उचित अनुक्रमण के बिना, MySQL को आवश्यक डेटा पुनर्प्राप्त करने के लिए संपूर्ण तालिका को स्कैन करना होगा। यह प्रक्रिया अत्यधिक अक्षम है, विशेष रूप से बड़ी तालिकाओं के लिए, क्योंकि इसमें पर्याप्त समय और संसाधनों की खपत होती है।
भारी लोड स्थिति - जब सर्वर बड़ी मात्रा में प्रश्नों को संभालता है या कुछ जटिल प्रश्नों को एक साथ संसाधित करता है, तो उपलब्ध संसाधन (जैसे सीपीयू और मेमोरी) कम हो जाते हैं। संसाधनों के लिए यह प्रतिस्पर्धा प्रश्नों के निष्पादन में देरी कर सकती है, जिससे चलने में लंबा समय लग सकता है, खासकर चरम उपयोग अवधि के दौरान।
लॉक विवाद - यह तब होता है जब एकाधिक लेनदेन को एक ही डेटा तक एक साथ पहुंच की आवश्यकता होती है लेकिन अवरुद्ध हो जाते हैं क्योंकि अन्य परिचालन आवश्यक लॉक रखते हैं। उदाहरण के लिए, यदि एक लेनदेन एक पंक्ति को अपडेट कर रहा है, तो दूसरा लेनदेन जो उसी पंक्ति को पढ़ना या अपडेट करना चाहता है, उसे पहले लेनदेन के पूरा होने और लॉक जारी करने तक इंतजार करना होगा।
अनुचित सामान्यीकरण - जबकि सामान्यीकरण डेटा अतिरेक से बचने में मदद करता है और डेटा अखंडता में सुधार करता है, अत्यधिक सामान्यीकृत डेटाबेस कई जोड़ों से जुड़े जटिल प्रश्नों को जन्म दे सकता है। ये प्रदर्शन को ख़राब कर सकते हैं. दूसरी ओर, सामान्यीकरण के तहत अत्यधिक डेटा दोहराव हो सकता है, जिसके परिणामस्वरूप बड़ी तालिकाएँ और धीमी क्वेरीज़ हो सकती हैं।
बड़े जोड़ - बड़ी तालिकाओं को जोड़ने वाली क्वेरीज़, विशेष रूप से उचित अनुक्रमणिका के बिना, धीमी हो सकती हैं। डेटाबेस को जुड़ने की शर्तों के आधार पर तालिकाओं में पंक्तियों से मेल खाना चाहिए, एक प्रक्रिया जो कुशल अनुक्रमण के बिना अत्यधिक संसाधन-गहन और धीमी हो सकती है।
लंबे समय से चल रही क्वेरी को प्रभावी ढंग से प्रबंधित करने के लिए, आपको सबसे पहले उन्हें पहचानने की आवश्यकता है। यहां कुछ विधियां दी गई हैं:
प्रक्रिया सूची दिखाएं; कमांड आपके सर्वर पर चल रहे सभी सक्रिय प्रश्नों का स्नैपशॉट प्राप्त करने का एक त्वरित तरीका है। यह कमांड प्रत्येक क्वेरी को महत्वपूर्ण जानकारी के कई टुकड़ों के साथ प्रदर्शित करता है, जिसमें यह भी शामिल है कि प्रत्येक क्वेरी कितने समय से चल रही है। उच्च "समय" मान वाले लोग संभवतः आपके लंबे समय तक चलने वाले प्रश्न हैं। यहां बताया गया है कि आप इस कमांड का उपयोग कैसे कर सकते हैं:
पूर्ण प्रक्रिया सूची दिखाएं;
यह कमांड सभी मौजूदा प्रक्रियाओं को सूचीबद्ध करेगा, दिखाएगा कि उन्हें किसने शुरू किया, वे किस प्रकार का कमांड चला रहे हैं, और, महत्वपूर्ण रूप से, वे कितने समय से इस पर काम कर रहे हैं। यदि आप असामान्य रूप से लंबे समय से चल रहे किसी प्रश्न को देखते हैं, तो वे आपके लंबे समय से चल रहे प्रश्न हैं। फिर आप यह निर्णय ले सकते हैं कि क्या उन्हें अनुकूलित करने में गहराई से उतरना है या यदि वे आपके सिस्टम के प्रदर्शन को नीचे खींच रहे हैं तो उन्हें मार देना है।
धीमी क्वेरी लॉग सेट करना उन समस्याग्रस्त प्रश्नों को पकड़ने के लिए एक और बढ़िया रणनीति है। यह आसान MySQL सुविधा किसी भी क्वेरी को लॉग करती है जिसे निष्पादित करने में एक निश्चित सीमा से अधिक समय लगता है। यह केवल लंबे समय से चल रहे प्रश्नों को पकड़ने के बारे में नहीं है - यह आपको उन प्रश्नों की पहचान करने में भी मदद कर सकता है जो इंडेक्स का कुशलतापूर्वक उपयोग नहीं कर रहे हैं।
धीमी क्वेरी लॉग अप और चलाने के लिए, आपको अपनी MySQL कॉन्फ़िगरेशन फ़ाइल (या तो my.cnf या my.ini) में कुछ सेटिंग्स को बदलने की आवश्यकता होगी:
MySQL की प्रदर्शन स्कीमा अधिक विस्तृत जांच के लिए अमूल्य है। यह टूल सर्वर ईवेंट की निगरानी करने और प्रदर्शन मेट्रिक्स को ट्रैक करने के लिए डिज़ाइन किया गया है, जो आपको क्वेरी निष्पादन और समग्र सिस्टम प्रदर्शन का स्पष्ट दृश्य प्रदान करता है।
निम्न पंक्ति जोड़कर सुनिश्चित करें कि यह आपके MySQL कॉन्फ़िगरेशन में सक्षम है:
[mysqld]
Performance_schema = चालू
एक बार यह सक्रिय हो जाए, तो आप अपने प्रश्नों के प्रदर्शन का विश्लेषण करने के लिए विभिन्न प्रकार की प्रदर्शन स्कीमा तालिकाओं का पता लगा सकते हैं। उदाहरण के लिए, यदि आप लंबे समय से चल रहे प्रश्नों को इंगित करना चाहते हैं, तो आप events_statements_history_long तालिका पर गौर करना चाहेंगे। यहां बताया गया है कि आप इसे कैसे क्वेरी कर सकते हैं:
EVENT_ID, SQL_TEXT, TIMER_WAIT/1000000000 को 'अवधि (सेकंड)' के रूप में चुनें
Performance_schema.events_statements_history_long से
जहां TIMER_WAIT > 10000000000;
यह क्वेरी आपको 10 सेकंड से अधिक समय से चल रही किसी भी क्वेरी को ढूंढने में मदद करती है। यह आपको SQL टेक्स्ट और प्रत्येक क्वेरी कितने समय से चल रही है जैसे विवरण देता है।
जब आपने एक ऐसी क्वेरी की पहचान की है जो बहुत अधिक समय ले रही है और आपके सिस्टम के संसाधनों पर दबाव डाल रही है, तो आपके पास इसे मैन्युअल रूप से समाप्त करने का विकल्प है। यह क्वेरी की विशिष्ट प्रक्रिया आईडी के बाद KILL कमांड का उपयोग करके किया जाता है।
आप SHOW PROCESSLIST कमांड चलाकर प्रक्रिया आईडी पा सकते हैं, जो सभी मौजूदा चल रही प्रक्रियाओं और उनकी संबंधित आईडी को प्रदर्शित करता है। किसी भी प्रश्न के लिए सूची देखें जो उच्च "समय" मान दिखाता है, जो दर्शाता है कि वे कितने समय से चल रहे हैं।
एक बार जब आप एक समस्याग्रस्त क्वेरी की पहचान कर लेते हैं और उसकी प्रक्रिया आईडी नोट कर लेते हैं, तो आप KILL कमांड का उपयोग करके इसे समाप्त कर सकते हैं:
मारें [प्रक्रिया आईडी];
SHOW PROCESSLIST आउटपुट से [प्रोसेस आईडी] को वास्तविक संख्या से बदलें।
इस दृष्टिकोण से सावधान रहें। किसी क्वेरी को अचानक रोकने से कभी-कभी समस्याएँ पैदा हो सकती हैं, जैसे कि यदि क्वेरी जानकारी लिखने या अपडेट करने के बीच में थी तो आपके डेटा को असंगत स्थिति में छोड़ देना।
लंबे समय तक चलने वाले प्रश्नों को संभालने के लिए स्वचालन स्थापित करना एक वास्तविक जीवनरक्षक हो सकता है, जो उन सुस्त या अअनुकूलित प्रश्नों को आपके डेटाबेस संसाधनों पर कब्जा करने और पूरे सिस्टम को धीमा करने, या यहां तक कि लॉक करने से रोकता है। लेकिन सावधानी से चलें—बिना सही जांच के इस टूल का उपयोग वास्तव में गहरी प्रदर्शन समस्याओं को छुपा सकता है जिन पर आपका ध्यान देने की आवश्यकता है।
हमेशा सुनिश्चित करें कि आपके एप्लिकेशन पर मारे गए प्रश्नों के प्रभाव का विश्लेषण करने के लिए आपके पास व्यापक लॉगिंग और मॉनिटरिंग है, और उन प्रश्नों को स्वचालित रूप से खत्म करने के बजाय उनमें सुधार करने पर विचार करें। प्रदर्शन को अनुकूलित करने की एक बड़ी रणनीति के हिस्से के रूप में स्वचालित समाप्ति के बारे में सोचें, न कि सब कुछ ठीक करने वाले समाधान के रूप में।
सबसे पहले, आपको MySQL इवेंट शेड्यूलर को सक्षम करना होगा, जो डिफ़ॉल्ट रूप से अक्षम है। इवेंट शेड्यूलर आपको उन कार्यों को बनाने और शेड्यूल करने की अनुमति देता है जिन्हें आप चाहते हैं कि सर्वर पूर्वनिर्धारित समय पर स्वचालित रूप से निष्पादित करे। निम्नलिखित कमांड चलाएँ:
वैश्विक इवेंट शेड्यूलर सेट करें = चालू;
शेड्यूलर सक्षम होने के साथ, अगला कदम वास्तविक घटना को परिभाषित करना है जो लंबे समय से चल रहे प्रश्नों की निगरानी करेगा और उन्हें खत्म कर देगा। निर्दिष्ट सीमा (जैसे 60 सेकंड) से अधिक समय तक चलने वाली क्वेरी की जांच करने के लिए ईवेंट हर मिनट चलेगा। एक बार पहचाने जाने पर, यह स्वचालित रूप से इन प्रश्नों को ख़त्म कर देगा। इस ईवेंट को सेट करने के लिए SQL कोड का विवरण यहां दिया गया है:
`इवेंट बनाएं किल_लॉन्ग_रनिंग_क्वेरीज़
प्रत्येक 1 मिनट में शेड्यूल पर - निर्दिष्ट करता है कि ईवेंट कितनी बार चलता है
करना
शुरू करना
पूर्णतया गलत घोषित करें;
घोषित proc_id INT; - प्रत्येक क्वेरी की प्रक्रिया आईडी को स्टोर करने के लिए वेरिएबल
Information_schema.processlist
से चयन आईडी के लिए cur1 कर्सर घोषित करें
जहां कमांड = 'क्वेरी' और समय > 60; - सेकंड में '60' को अपनी सीमा में बदलें
सेट नहीं मिलने पर कंटीन्यू हैंडलर घोषित करें = सत्य;
खुला वक्र1;
read_loop: लूप
proc_id में cur1 प्राप्त करें;
यदि किया गया तो
read_loop छोड़ें;
समाप्त हो तो;
मार डालो proc_id; - proc_id द्वारा पहचानी गई प्रक्रिया को समाप्त कर देता है
अंत लूप;
CLOSE cur1;
END;`
किसी क्वेरी के लिए अधिकतम निष्पादन समय को नियंत्रित करने से डेटाबेस को अत्यधिक लंबे समय तक चलने वाली क्वेरी से बंधे रहने से रोकने में मदद मिलती है। यह सभी रीड-ओनली सेलेक्ट क्वेरीज़ के लिए सिस्टम-वाइड निष्पादन समय सीमा निर्धारित करके MySQL 5.7.8 और बाद के संस्करणों में max_execution_time सिस्टम वेरिएबल का उपयोग करके किया जाता है:
वैश्विक अधिकतम_निष्पादन_समय = 2000 सेट करें;
यह सीमा 2000 मिलीसेकंड (2 सेकंड) निर्धारित करता है
याद रखें, यह सेटिंग संग्रहीत प्रक्रियाओं, फ़ंक्शंस या ट्रिगर्स पर लागू नहीं होती है और सर्वर पुनरारंभ होने पर डिफ़ॉल्ट पर रीसेट हो जाती है जब तक कि इसे आपकी MySQL कॉन्फ़िगरेशन फ़ाइल में नहीं जोड़ा जाता है:
[mysqld]
अधिकतम_निष्पादन_समय = 2000
मारियाडीबी, जबकि MySQL से फोर्क किया गया है, क्वेरी निष्पादन समय को प्रबंधित करने के लिए एक समान लेकिन विशिष्ट दृष्टिकोण प्रदान करता है। MariaDB 10.1.1 से शुरू करके, आप इस उद्देश्य के लिए max_statement_time सिस्टम वेरिएबल का उपयोग कर सकते हैं:
ग्लोबल अधिकतम_स्टेटमेंट_टाइम = 2 सेट करें;
यह सभी प्रश्नों के लिए निष्पादन समय को 2 सेकंड तक सीमित करता है।
सर्वर पुनरारंभ के माध्यम से लगातार कॉन्फ़िगरेशन के लिए, इस पंक्ति को अपनी MariaDB कॉन्फ़िगरेशन फ़ाइल में जोड़ें:
[mysqld]
अधिकतम_कथन_समय = 2
रिलीम का क्वेरी एनालिटिक्स टूल आपके डेटाबेस प्रदर्शन की निगरानी और अनुकूलन करने के तरीके में क्रांतिकारी बदलाव लाता है। यह स्वचालित रूप से शीर्ष 100 प्रश्नों पर विस्तृत जानकारी एकत्र करता है, औसत निष्पादन समय और आपके डेटाबेस की परिचालन दक्षता पर प्रत्येक क्वेरी के समग्र प्रभाव जैसे प्रमुख मैट्रिक्स प्रदान करता है।
रिलीम के साथ, खराब प्रदर्शन करने वाले प्रश्नों की पहचान करने के लिए PROCESSLIST आउटपुट को मैन्युअल रूप से खंगालने या धीमी क्वेरी लॉग को देखने की कोई आवश्यकता नहीं है। टूल में एक सहज ज्ञान युक्त डैशबोर्ड है जो आपको विलंबित या अत्यधिक समय लेने वाली क्वेरी को आसानी से क्रमबद्ध करने और पहचानने की अनुमति देता है। यह तत्काल अंतर्दृष्टि आपको कुछ ही समय में बाधाओं को पहचानने और हल करने में मदद करती है।
अस्वीकरण: उपलब्ध कराए गए सभी संसाधन आंशिक रूप से इंटरनेट से हैं। यदि आपके कॉपीराइट या अन्य अधिकारों और हितों का कोई उल्लंघन होता है, तो कृपया विस्तृत कारण बताएं और कॉपीराइट या अधिकारों और हितों का प्रमाण प्रदान करें और फिर इसे ईमेल पर भेजें: [email protected] हम इसे आपके लिए यथाशीघ्र संभालेंगे।
Copyright© 2022 湘ICP备2022001581号-3