SCUMM डैशबोर्ड के साथ MySQL की प्रभावी निगरानी:भाग 3

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

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

आइए रेखांकन के माध्यम से चलना शुरू करें।

MySQL InnoDB मेट्रिक्स

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

इनोडब चेकपॉइंट आयु

मैनुअल के अनुसार, चेकपॉइंटिंग को इस प्रकार परिभाषित किया गया है:"चूंकि डेटा पृष्ठों में परिवर्तन किए जाते हैं जो बफर पूल में कैश्ड होते हैं। , वे परिवर्तन डेटा फ़ाइलों . में लिखे जाते हैं कुछ समय बाद, एक प्रक्रिया जिसे फ्लशिंग . के रूप में जाना जाता है . चेकपॉइंट नवीनतम परिवर्तनों का एक रिकॉर्ड है (एक LSN . द्वारा दर्शाया गया है) value) को सफलतापूर्वक डेटा फ़ाइलों में लिखा गया है " यह ग्राफ़ तब उपयोगी होता है जब आप यह निर्धारित करना चाहते हैं कि आपका सर्वर आपकी डिस्क पर चेकपॉइंटिंग डेटा का प्रदर्शन कैसे कर रहा है। यह एक अच्छा संदर्भ हो सकता है यदि आपका लेन-देन लॉग (फिर से करें लॉग या ib_logfile0) बहुत बड़ा है। यदि आपको innodb_log_file_size, innodb_log_buffer_size, innodb_max_dirty_pages_pct, या innodb_adaptive_flushing_method जैसे चरों को समायोजित करने की आवश्यकता है तो यह ग्राफ़ भी एक अच्छा संकेतक है। चेकपॉइंट की उम्र अधिकतम चेकपॉइंट की उम्र के करीब है, लॉग अधिक भरे हुए हैं और लॉग में कुछ खाली स्थान बनाए रखने के लिए InnoDB अधिक I/O कर रहा होगा। Percona XtraDB- आधारित फ्लेवर, MariaDB और Oracle के संस्करण के बीच सूक्ष्म विवरण में चेकपॉइंटिंग तंत्र भिन्न है, आप MySQL संस्करणों के बीच इसके कार्यान्वयन में अंतर भी पा सकते हैं।
InnoDB लेनदेन

जब भी आपके MySQL सर्वर में कोई बड़ा लेन-देन होता है, तो यह ग्राफ़ एक अच्छा संदर्भ होता है। यह उन लेन-देन की गणना करेगा जो एक विशिष्ट समय पर बनाए गए थे, और इतिहास की लंबाई (या वास्तव में SHOW ENGINE INNODB STATUS में मिली इतिहास सूची की लंबाई) पूर्ववत लॉग में पृष्ठों की संख्या है। आप यहां जो रुझान देखेंगे, वह यह जांचने के लिए एक अच्छा संसाधन है कि क्या इसका मतलब हो सकता है, उदाहरण के लिए, डेटा को फिर से लोड करने की बहुत अधिक डालने की दर के कारण या लंबे समय तक चलने वाले लेन-देन के कारण, या यदि पर्ज आसानी से हो सकता है 'आपके $DATADIR के वॉल्यूम में उच्च डिस्क I/O के कारण जारी न रहें।
इनोडब पंक्ति संचालन

कुछ डीबीए कार्यों के लिए, आप हटाए गए, सम्मिलित करने, पढ़ने और अपडेट की गई पंक्तियों की संख्या निर्धारित करना चाह सकते हैं। फिर इस ग्राफ़ का उपयोग आप इन्हें जांचने के लिए कर सकते हैं।
इनोडब रो लॉक टाइम

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

जब भी आप InnoDB डेटा रीड, डिस्क फ्लश, राइट और लॉग राइट की मात्रा निर्धारित करना चाहते हैं, तो इस ग्राफ में वह है जो आपको देखने की आवश्यकता है। आप इस ग्राफ का उपयोग यह निर्धारित करने के लिए कर सकते हैं कि आपकी विशिष्ट आवश्यकताओं को संभालने के लिए आपके InnoDB चर अच्छी तरह से ट्यून किए गए हैं या नहीं। उदाहरण के लिए, यदि आपके पास बैटरी बैकअप मॉड्यूल कैश है, लेकिन आप इसके अधिकतम प्रदर्शन को प्राप्त नहीं कर रहे हैं, तो आप यह निर्धारित करने के लिए इस ग्राफ़ पर भरोसा कर सकते हैं कि क्या आपके fsyncs () अपेक्षा से अधिक हैं। फिर वेरिएबल innodb_flush_method को बदलने और O_DSYNC का उपयोग करने से समस्या का समाधान हो सकता है।
InnoDB लॉग फ़ाइल उपयोग प्रति घंटा

यह ग्राफ़ केवल InnoDB रीडो लॉग फ़ाइलों में लिखे गए बाइट्स की संख्या और वर्तमान दिनांक की 24-घंटे की समय सीमा के आधार पर आपकी InnoDB लॉग फ़ाइलों की वृद्धि को दर्शाता है।
InnoDB लॉगिंग प्रदर्शन

यह ग्राफ़ InnoDB लॉग फ़ाइल उपयोग प्रति घंटा ग्राफ़ से निकटता से संबंधित है। जब भी आपको यह निर्धारित करने की आवश्यकता हो कि आपका innodb_log_file_size कितना बड़ा होना चाहिए, आपको इस ग्राफ का उपयोग करना होगा। आप यह निर्धारित कर सकते हैं कि InnoDB रीडो लॉग फ़ाइलों में लिखे गए बाइट्स की संख्या और आपका MySQL कितनी कुशलता से मेमोरी से डिस्क पर डेटा फ्लश करता है। जब भी आपको अपने रीडो लॉग स्पेस का उपयोग करने के लिए कम समय का अनुभव हो, तो यह संकेत देगा कि आपको अपना innodb_log_file आकार बढ़ाना होगा। उस स्थिति में, यह ग्राफ़ आपको बताएगा कि आपको ऐसा करने की आवश्यकता है। हालाँकि, आपको अपने innodb_log_file के लिए कितनी आवश्यकता है, इस बारे में अधिक जानने के लिए, इंजन INNODB स्थिति दिखाएं में LSN (लॉग अनुक्रम संख्या) की जांच करना अधिक समझ में आता है। Percona का इससे संबंधित एक अच्छा ब्लॉग है जो देखने के लिए एक अच्छा स्रोत है।
InnoDB गतिरोध

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

इस ग्राफ को देखते समय सावधानी के एक छोटे से शब्द। सबसे पहले, आपको यह निर्धारित करना होगा कि आपके पास अपना MySQL वैश्विक चर innodb_monitor_enable सही मान पर सेट है जो कि मॉड्यूल_आईसीपी है। अन्यथा, आपको नीचे दिखाए गए अनुसार "नो डेटा पॉइंट्स" का अनुभव होगा:

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

मुझे इस ग्राफ के बारे में थोड़ा विस्तार से बताएं, मान लें कि मेरे पास एक टेबल है जिसका नाम है:
```
mysql> show create table a\G
*************************** 1. row ***************************
       Table: a
Create Table: CREATE TABLE `a` (
  `id` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
```
और इसमें कुछ छोटा डेटा है:
```
mysql> select * from a;
+----+-----+
| id | age |
+----+-----+
|  1 |   1 |
|  2 |   1 |
|  3 |   1 |
|  3 |  41 |
|  4 |  41 |
|  5 |   4 |
|  4 |   4 |
|  4 |   4 |
+----+-----+
8 rows in set (0.00 sec)
```
जब ICP सक्षम होता है, तो परिणाम अधिक कुशल और व्यवहार्य होते हैं:
```
mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
1 row in set, 2 warnings (0.00 sec)
```
आईसीपी के बिना,
```
mysql> set optimizer_switch='index_condition_pushdown=off';
Query OK, 0 rows affected (0.00 sec)

mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 2 warnings (0.00 sec)
```
यह ICP का एक सरल उदाहरण है, और यह ग्राफ़ किसी DBA को कैसे लाभ पहुंचा सकता है।
InnoDB बफर पूल सामग्री

MySQL के साथ काम करते समय और InnoDB इंजन का उपयोग करते समय, यह ग्राफ़ सबसे सामान्य मानों में से एक है (innodb_buffer_pool*) जिसे आपको MySQL के प्रदर्शन को अनुकूलित करने के लिए ट्यून करना होगा। विशेष रूप से इसकी बफर पूल सामग्री पर बोलते हुए, यह कुल बफर पूल सामग्री के विरुद्ध गंदे पृष्ठों के रुझान प्रदर्शित करता है। कुल बफर पूल सामग्री में गंदे पृष्ठों के अलावा साफ पृष्ठ शामिल हैं। यह निर्धारित करते हुए कि आपका MySQL बफर पूल को कितनी कुशलता से संभाल रहा है, यह ग्राफ अपने उद्देश्य को पूरा करता है।
InnoDB बफर पूल पेज

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

जब आपको InnoDB तालिकाओं पर बनाए गए और लिखे गए पृष्ठों की संख्या की जाँच करनी होती है या InnoDB तालिकाओं पर संचालन द्वारा पृष्ठ InnoDB बफर पूल में पढ़ता है।
InnoDB बफर पूल अनुरोध

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

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

जब आपके पास Percona Server 5.7 चल रहा होता है, तो यह ग्राफ़ यह निगरानी करते समय उपयोगी होता है कि InnoDB ने परिवर्तन बफ़रिंग को कितनी अच्छी तरह आवंटित किया है। इस परिवर्तन में वे इंसर्ट, अपडेट और डिलीट शामिल हैं जो innodb_change_buffering चर द्वारा निर्दिष्ट हैं। बफ़रिंग बदलें क्वेरीज़ को तेज़ करने में मदद करता है, पर्याप्त रैंडम एक्सेस I/O से बचता है जो डिस्क से सेकेंडरी इंडेक्स पेजों को पढ़ने के लिए आवश्यक होगा।
InnoDB बफ़र गतिविधि बदलें

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

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

MySQL प्रदर्शन स्कीमा एक जटिल विषय है। यह एक लंबा और कठिन है, लेकिन मैं केवल उस जानकारी पर चर्चा करने जा रहा हूं जो हमारे पास SCUMM में मौजूद ग्राफ़ के लिए विशिष्ट है। कुछ निश्चित चर भी हैं जिन पर आपको विचार करना चाहिए और सुनिश्चित करना चाहिए कि वे ठीक से सेट हैं। सुनिश्चित करें कि आपके ग्राफ़ में डेटा बिंदु देखने के लिए आपके पास अपना चर innodb_monitor_enable =all और userstat=1 है। एक नोट के रूप में, जब मैं यहां "ईवेंट" शब्द का उपयोग कर रहा हूं, तो इसका मतलब यह नहीं है कि यह MySQL इवेंट शेड्यूलर से संबंधित है। मैं विशिष्ट घटनाओं के बारे में बात कर रहा हूं जैसे कि MySQL एक क्वेरी को पार्स करता है, MySQL रिले/बाइनरी लॉग फ़ाइल को पढ़ रहा है या लिख रहा है, आदि।

आइए फिर रेखांकन के साथ आगे बढ़ें।

प्रदर्शन स्कीमा फ़ाइल IO (ईवेंट)

यह ग्राफ़ MySQL में होने वाली किसी भी घटना से संबंधित डेटा पॉइंट प्राप्त करता है, जो कि इंस्ट्रूमेंटेड ऑब्जेक्ट के कई इंस्टेंस बनाने के लिए इंस्ट्रुमेंटेड हो सकता है (जैसे बाइनरी लॉग रीड्स या InnoDB डेटा फ़ाइल रीड्स)। प्रत्येक पंक्ति किसी दिए गए ईवेंट नाम के लिए ईवेंट को सारांशित करती है। उदाहरण के लिए, यदि एक म्यूटेक्स के लिए एक उपकरण है जो प्रत्येक कनेक्शन के लिए बनाया गया है, तो इस इंस्ट्रूमेंटेड घटना के कई उदाहरण हो सकते हैं क्योंकि कई कनेक्शन हैं। साधन के लिए सारांश पंक्ति इन सभी उदाहरणों का सार प्रस्तुत करती है। अधिक जानकारी के लिए आप प्रदर्शन स्कीमा सारांश तालिका के लिए MySQL मैनुअल में इन घटनाओं की जांच कर सकते हैं।
प्रदर्शन स्कीमा फ़ाइल IO (लोड)

यह ग्राफ़ "प्रदर्शन स्कीमा फ़ाइल IO (ईवेंट)" ग्राफ़ जैसा ही है, सिवाय इसके कि यह लोड के आधार पर यंत्रीकृत है।
प्रदर्शन स्कीमा फ़ाइल IO (बाइट्स)

यह ग्राफ़ "प्रदर्शन स्कीमा फ़ाइल IO (ईवेंट)" ग्राफ़ के समान है, सिवाय इसके कि यह बाइट्स में आकार के आधार पर यंत्रीकृत है। उदाहरण के लिए, जब MySQL ने प्रतीक्षा/io/file/innodb/innodb_data_file ईवेंट ट्रिगर किया, तो किसी विशिष्ट ईवेंट को कितना समय लगा।
प्रदर्शन स्कीमा प्रतीक्षा (ईवेंट)

इस ग्राफ़ में किसी विशिष्ट ईवेंट पर खर्च किए गए सभी प्रतीक्षाओं का डेटा ग्राफ़ है। अधिक जानकारी के लिए आप मैनुअल में इवेंट सारांश सारणी प्रतीक्षा करें देख सकते हैं।
प्रदर्शन स्कीमा प्रतीक्षा कर रहा है (लोड)

"प्रदर्शन स्कीमा प्रतीक्षा (ईवेंट)" ग्राफ़ के समान लेकिन इस बार यह लोड के रुझान दिखाता है।
इंडेक्स एक्सेस ऑपरेशंस (लोड)

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

"इंडेक्स एक्सेस ऑपरेशंस (लोड)" ग्राफ के समान, यह सभी तालिका I / O प्रतीक्षा ईवेंट समूह का एक एकत्रीकरण है, जैसा कि प्रतीक्षा / io / तालिका / sql / हैंडलर उपकरण द्वारा उत्पन्न होता है। यह डीबीए के लिए बहुत उपयोगी है। उदाहरण के लिए, आप यह पता लगाना चाहेंगे कि किसी विशिष्ट तालिका तक पहुँचने (लाने) या अद्यतन (सम्मिलित करने, हटाने, अद्यतन करने) में कितनी तेजी आती है। आप अधिक जानकारी के लिए प्रदर्शन स्कीमा तालिका तालिका_io_waits_summary_by_table के बारे में MySQL मैनुअल में देख सकते हैं।
प्रदर्शन स्कीमा SQL और बाहरी लॉक (ईवेंट)

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

ग्राफ "प्रदर्शन स्कीमा एसक्यूएल और बाहरी ताले (ईवेंट)" के समान, लेकिन सेकंड में निर्दिष्ट। यदि आप अपने टेबल लॉक को सेकंड के आधार पर देखना चाहते हैं, तो यह ग्राफ़ आपके लिए अच्छा संसाधन है।

निष्कर्ष

InnoDB मेट्रिक्स और MySQL प्रदर्शन स्कीमा MySQL डोमेन में सबसे गहन और जटिल भागों में से कुछ हैं, खासकर जब व्याख्या की सहायता के लिए कोई विज़ुअलाइज़ेशन नहीं है। इस प्रकार, मैन्युअल ट्रेस और जांच में जाने में आपका कुछ समय और कड़ी मेहनत लग सकती है। SCUMM डैशबोर्ड इन्हें संभालने और किसी भी DBA नियमित कार्य पर अतिरिक्त भार को कम करने के लिए एक बहुत ही कुशल और व्यवहार्य तरीका प्रदान करते हैं।

इस ब्लॉग में, आपने सीखा कि डेटाबेस के प्रदर्शन को बेहतर बनाने के लिए InnoDB और प्रदर्शन स्कीमा के लिए डैशबोर्ड का उपयोग कैसे करें। ये डैशबोर्ड आपको प्रदर्शन का विश्लेषण करने में अधिक कुशल बना सकते हैं।