प्रत्येक MySQL समर्थित एप्लिकेशन एक बारीक ट्यून किए गए डेटाबेस सर्वर से लाभ उठा सकता है। लिक्विड वेब हीरोइक सपोर्ट टीम ने पिछले कुछ वर्षों में कई स्थितियों का सामना किया है जब कुछ मामूली समायोजनों ने वेबसाइट और एप्लिकेशन प्रदर्शन में अंतर की दुनिया बना दी है। लेखों की इस श्रृंखला में, हमने कुछ अधिक सामान्य अनुशंसाओं को रेखांकित किया है जिनका प्रदर्शन पर सबसे अधिक प्रभाव पड़ा है।
पूर्व उड़ान जांच
यह आलेख अधिकांश Linux-आधारित MySQL VPS सर्वर पर लागू होता है। इसमें पारंपरिक समर्पित और क्लाउड वीपीएस सर्वर दोनों शामिल हैं, जो विभिन्न प्रकार के सामान्य लिनक्स वितरण चला रहे हैं। लेख का उपयोग निम्नलिखित लिक्विड वेब सिस्टम प्रकारों के साथ किया जा सकता है:
- कोर-प्रबंधित CentOS 6x/7x
- कोर-प्रबंधित Ubuntu 14.04/16.04
- पूरी तरह से प्रबंधित CentOS 6/7 cPanel
- पूरी तरह से प्रबंधित CentOS 7 Plesk Onyx 17
- स्व-प्रबंधित Linux सर्वर
लेखों की यह श्रृंखला निम्नलिखित बुनियादी प्रणाली प्रशासन अवधारणाओं से परिचित है:
- SSH कनेक्शन और मानक Linux कमांड लाइन शेल वातावरण का बुनियादी नेविगेशन।
- विम या चुने हुए सिस्टम संपादक में फ़ाइलें खोलना, संपादित करना और सहेजना।
- MySQL इंटरैक्टिव मोड और सामान्य MySQL क्वेरी सिंटैक्स।
MySQL ऑप्टिमाइज़ेशन क्या है?
MySQL ऑप्टिमाइज़ेशन शब्द की कोई स्पष्ट रूप से परिभाषित परिभाषा नहीं है। व्यक्ति, व्यवस्थापक, समूह या कंपनी के आधार पर इसका अर्थ कुछ अलग हो सकता है। MySQL ऑप्टिमाइज़ेशन पर लेखों की इस श्रृंखला के लिए, हम MySQL ऑप्टिमाइज़ेशन को इस प्रकार परिभाषित करेंगे: एक MySQL या MariaDB सर्वर का कॉन्फ़िगरेशन जिसे लेखों की इस श्रृंखला में चर्चा की गई आम तौर पर आने वाली बाधाओं से बचने के लिए कॉन्फ़िगर किया गया है।
बाधा क्या है?
सोडा बोतल पर गर्दन के समान, तकनीकी शब्द के रूप में एक अड़चन एक एप्लिकेशन या सर्वर कॉन्फ़िगरेशन में एक बिंदु है जहां थोड़ी मात्रा में ट्रैफ़िक या डेटा बिना किसी समस्या के गुजर सकता है। हालाँकि, एक ही प्रकार के ट्रैफ़िक या डेटा की एक बड़ी मात्रा बाधित या अवरुद्ध है और सफलतापूर्वक संचालित नहीं हो सकती है। कॉन्फ़िगरेशन अड़चन का निम्न उदाहरण देखें:
इस उदाहरण में, सर्वर एक साथ 10 कनेक्शनों को संभालने में सक्षम है। हालाँकि, कॉन्फ़िगरेशन केवल 5 कनेक्शन स्वीकार करता है। यह समस्या तब तक प्रकट नहीं होगी जब तक एक ही बार में 5 या उससे कम कनेक्शन थे। हालाँकि, जब ट्रैफ़िक 10 कनेक्शन तक रैंप करता है, तो सर्वर कॉन्फ़िगरेशन में अप्रयुक्त संसाधनों के कारण उनमें से आधे विफल होने लगते हैं। ऊपर दिए गए उदाहरण टोंटी के आकार को दर्शाते हैं जहां यह अपना नाम प्राप्त करता है बनाम एक अनुकूलित कॉन्फ़िगरेशन जो अड़चन को ठीक करता है।
मुझे अपने MySQL डेटाबेस को कब अनुकूलित करना चाहिए?
आदर्श रूप से, डेटाबेस प्रदर्शन ट्यूनिंग नियमित रूप से और उत्पादकता प्रभावित होने से पहले होनी चाहिए। अनुप्रयोगों को प्रतिकूल रूप से प्रभावित करने वाली समस्याओं को रोकने के लिए डेटाबेस प्रदर्शन का साप्ताहिक या मासिक ऑडिट करना सर्वोत्तम अभ्यास व्यवहार है। प्रदर्शन समस्याओं के सबसे स्पष्ट लक्षण हैं:
- क्वेरी MySQL प्रोसेस टेबल में ढेर हो जाती हैं और कभी पूरी नहीं होती हैं।
- डेटाबेस का उपयोग करने वाले एप्लिकेशन या वेबसाइट सुस्त हो जाते हैं।
- कनेक्शन टाइमआउट त्रुटियां, विशेष रूप से व्यस्त समय के दौरान।
जबकि एक व्यस्त सिस्टम पर एक साथ कई समवर्ती प्रश्नों का चलना सामान्य है, यह एक समस्या बन जाती है जब इन प्रश्नों को नियमित रूप से समाप्त होने में बहुत अधिक समय लगता है। हालांकि विशिष्ट सीमा प्रति सिस्टम और प्रति एप्लिकेशन भिन्न होती है, कई सेकंड से अधिक औसत क्वेरी समय संलग्न वेबसाइटों और एप्लिकेशन के भीतर मंदी के रूप में प्रकट होगा। ये मंदी कभी-कभी छोटे से शुरू हो सकती हैं और तब तक किसी का ध्यान नहीं जाता जब तक कि एक बड़ा ट्रैफ़िक उछाल किसी विशेष बाधा को प्रभावित नहीं करता।
प्रदर्शन समस्याओं की पहचान करना
विशिष्ट अड़चन का निदान करने के लिए MySQL प्रक्रिया तालिका की जांच करने का तरीका जानना महत्वपूर्ण है। आपके विशेष सर्वर और वरीयता के आधार पर प्रक्रिया तालिका को देखने के कई तरीके हैं। संक्षिप्तता के लिए यह श्रृंखला सिक्योर शेल (SSH) एक्सेस के माध्यम से उपयोग की जाने वाली सबसे सामान्य विधियों पर ध्यान केंद्रित करेगी:
विधि 1. MySQL प्रक्रिया तालिका का उपयोग करना
'mysqladmin . का प्रयोग करें 'प्रक्रिया सूची . ध्वज के साथ कमांड लाइन टूल ' या 'खरीदें ' छोटे के लिए। (ध्वज जोड़ना 'आंकड़े ' या 'आंकड़े ' संक्षेप में MySQL के अंतिम पुनरारंभ के बाद से प्रश्नों के लिए चल रहे आंकड़े दिखाएगा।)
कमांड:
mysqladmin proc stat
आउटपुट:
+-------+------+-----------+-----------+---------+------+-------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
| 77255 | root | localhost | employees | Query | 150 | | call While_Loop2() | 0.000 |
| 77285 | root | localhost | | Query | 0 | init | show processlist | 0.000 |
+-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
Uptime: 861755 Threads: 2 Questions: 20961045 Slow queries: 0 Opens: 2976 Flush tables: 1 Open tables: 1011 Queries per second avg: 24.323
नोट:प्रो :शेल इंटरफ़ेस पर उपयोग किया जाता है, यह अन्य स्क्रिप्ट और टूल के लिए पाइपिंग आउटपुट को आसान बनाता है।Con :प्रक्रिया तालिका का जानकारी कॉलम हमेशा छोटा होता है, इसलिए लंबी क्वेरी पर पूर्ण क्वेरी प्रदान नहीं करता है विधि 2:MySQL प्रक्रिया तालिका का उपयोग करना
MySQL इंटरेक्टिव मोड प्रॉम्प्ट के भीतर से 'शो प्रोसेसलिस्ट;' क्वेरी चलाएँ। (ए‘ जोड़ना पूर्ण ' कमांड का संशोधक . के काट-छांट को अक्षम करता है जानकारी कॉलम। लंबी क्वेरी देखते समय यह आवश्यक है।)
कमांड:
show processlist;
आउटपुट:
MariaDB [(none)]> show full processlist;
+-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
| 77006 | root | localhost | employees | Query | 151 | NULL | call While_Loop2() | 0.000 |
| 77021 | root | localhost | NULL | Query | 0 | init | show full processlist | 0.000 |
+-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
प्रो :पूर्ण संशोधक का उपयोग करने से लंबी क्वेरी पर पूर्ण क्वेरी देखने की अनुमति मिलती है।Con :MySQL इंटरएक्टिव मोड शेल इंटरफेस में उपलब्ध स्क्रिप्ट और टूल्स तक नहीं पहुंच सकता है। धीमे क्वेरी लॉग का उपयोग करना
MySQL में एक और मूल्यवान टूल शामिल धीमी क्वेरी लॉगिंग सुविधा है। नियमित रूप से लंबे समय तक चलने वाली क्वेरी खोजने के लिए यह सुविधा पसंदीदा तरीका है। इस सुविधा को समायोजित करने के लिए कई निर्देश उपलब्ध हैं। हालांकि, सबसे अधिक आवश्यक सेटिंग्स हैं:
slow_query_log | धीमी क्वेरी लॉग को सक्षम/अक्षम करें |
slow_query_log_file | धीमी क्वेरी लॉग फ़ाइल का नाम और पथ |
long_query_time | सेकेंड/माइक्रोसेकंड में समय धीमी क्वेरी को परिभाषित करता है |
ये निर्देश /etc/my.cnf पर स्थित MySQL कॉन्फ़िगरेशन फ़ाइल के [mysqld] अनुभाग में सेट हैं और उनके प्रभावी होने से पहले एक MySQL सेवा पुनरारंभ की आवश्यकता होगी। फ़ॉर्मेटिंग के लिए नीचे दिया गया उदाहरण देखें:
चेतावनी:धीमी क्वेरी लॉग फ़ाइल के साथ एक बड़ा डिस्क स्थान चिंता का विषय है, जिसे धीमी क्वेरी लॉग सुविधा अक्षम होने तक लगातार ध्यान देने की आवश्यकता है। ध्यान रखें, आपका long_query_time निर्देश जितना कम होगा, धीमी क्वेरी लॉग डिस्क विभाजन को उतनी ही तेज़ी से भरता है[mysqld]
log-error=/var/lib/mysql/mysql.err
innodb_file_per_table=1
default-storage-engine=innodb
innodb_buffer_pool_size=128M
innodb_log_file_size=128M
max_connections=300
key_buffer_size = 8M
slow_query_log=1
slow_query_log_file=/var/lib/mysql/slowquery.log
long_query_time=5
एक बार धीमी क्वेरी लॉग सक्षम हो जाने पर आपको अनियंत्रित प्रश्नों की समीक्षा करने के लिए समय-समय पर इसके साथ अनुवर्ती कार्रवाई करने की आवश्यकता होगी जिन्हें बेहतर प्रदर्शन के लिए समायोजित करने की आवश्यकता है। धीमी क्वेरी लॉग फ़ाइल का विश्लेषण करने के लिए, आप इसकी सामग्री की समीक्षा करने के लिए इसे सीधे पार्स कर सकते हैं। निम्न उदाहरण नमूना क्वेरी के आंकड़े दिखाता है जो कॉन्फ़िगर किए गए 5 सेकंड से अधिक समय तक चलता है:
सावधानीधीमी क्वेरी लॉग सुविधा को सक्षम करने से प्रदर्शन प्रभावित होता है। यह प्रत्येक क्वेरी का विश्लेषण करने के लिए आवश्यक अतिरिक्त रूटीन के साथ-साथ लॉग फ़ाइल में आवश्यक क्वेरी लिखने के लिए आवश्यक I/O के कारण है। इस वजह से, धीमी क्वेरी लॉग को अक्षम करने के लिए इसे उत्पादन प्रणालियों पर सर्वोत्तम अभ्यास माना जाता है। धीमी क्वेरी लॉग केवल एक विशिष्ट अवधि के लिए सक्षम रहना चाहिए, जब सक्रिय रूप से परेशानी वाले प्रश्नों की तलाश में हो जो एप्लिकेशन या वेबसाइट को प्रभावित कर रहे हों।# Time: 180717 0:23:28
# User@Host: root[root] @ localhost []
# Thread_id: 32 Schema: employees QC_hit: No
# Query_time: 627.163085 Lock_time: 0.000021 Rows_sent: 0 Rows_examined: 0
# Rows_affected: 0
use employees;
SET timestamp=1531801408;
call While_Loop2();
वैकल्पिक रूप से, आप mysqldumpslow कमांड-लाइन टूल का उपयोग कर सकते हैं, जो धीमी क्वेरी लॉग फ़ाइल और क्वेरीज़ जैसे समूहों को संख्या और स्ट्रिंग डेटा के मानों को छोड़कर एक साथ पार्स करता है:
~ $ mysqldumpslow -a /var/lib/mysql/slowquery.log
Reading mysql slow query log from /var/lib/mysql/slowquery.log
Count: 2 Time=316.67s (633s) Lock=0.00s (0s) Rows_sent=0.5 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
call While_Loop2()
(उपयोग की जानकारी के लिए यहां MySQL के दस्तावेज़ देखें - mysqldumpslow — Slow Query Log Files को सारांशित करें)
निष्कर्ष
तो हमारी डेटाबेस ऑप्टिमाइज़ेशन श्रृंखला के पहले भाग को समाप्त करता है और हमें बेंचमार्क उद्देश्यों के संदर्भ में एक ठोस आधार देता है। हालांकि डेटाबेस के मुद्दे जटिल हो सकते हैं, हमारी श्रृंखला डेटाबेस रूपांतरण, तालिका रूपांतरण और अनुक्रमण के माध्यम से आपके डेटाबेस को अनुकूलित करने के साधन प्रदान करने के लिए इन अवधारणाओं को तोड़ देगी।
हम कैसे सहायता कर सकते हैं?
हम होस्टिंग™ में सबसे मददगार इंसान होने पर गर्व करते हैं!
हमारी सहायता टीम अनुभवी लिनक्स तकनीशियनों और प्रतिभाशाली सिस्टम प्रशासकों से भरी हुई है, जिन्हें कई वेब होस्टिंग तकनीकों का गहन ज्ञान है, विशेष रूप से इस लेख में चर्चा की गई।
यदि इस जानकारी के संबंध में आपके कोई प्रश्न हैं, तो हम इस लेख से संबंधित किसी भी प्रश्न का उत्तर देने के लिए हमेशा उपलब्ध हैं, 24 घंटे एक दिन, सप्ताह में 7 दिन एक वर्ष में 365 दिन।
अगर आप पूरी तरह से प्रबंधित VPS सर्वर, क्लाउड डेडिकेटेड, VMWare प्राइवेट क्लाउड, प्राइवेट पैरेंट सर्वर, मैनेज्ड क्लाउड सर्वर या डेडिकेटेड सर्वर के मालिक हैं और आप बताए गए किसी भी चरण को करने में असहज महसूस करते हैं, तो हम इस प्रक्रिया में आपकी सहायता करने के लिए @800.580.4985, चैट या समर्थन टिकट पर फोन के माध्यम से संपर्क किया जा सकता है।