MySQL डेटाबेस को व्यवस्थित करते समय प्रदर्शन संबंधी समस्याएं आम समस्याएं हैं। कभी-कभी ये समस्याएं, वास्तव में, धीमे प्रश्नों के कारण होती हैं। इस ब्लॉग में, हम धीमी क्वेरी और इनकी पहचान करने के तरीके के बारे में बात करेंगे।
अपने धीमे क्वेरी लॉग की जांच करना
MySQL में धीमी क्वेरी को फ़िल्टर और लॉग करने की क्षमता है। आप इनकी जांच करने के कई तरीके हैं, लेकिन धीमी क्वेरी लॉग का उपयोग करना सबसे आम और कुशल तरीका है।
आपको पहले यह निर्धारित करना होगा कि आपके धीमे क्वेरी लॉग सक्षम हैं या नहीं। इससे निपटने के लिए, आप अपने सर्वर पर जा सकते हैं और निम्नलिखित चर को क्वेरी कर सकते हैं:
MariaDB [(none)]> show global variables like 'slow%log%';
+---------------------+-------------------------------+
| Variable_name | Value |
+---------------------+-------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/log/mysql/mysql-slow.log |
+---------------------+-------------------------------+
2 rows in set (0.001 sec)आपको यह सुनिश्चित करना होगा कि वेरिएबल slow_query_log को ON पर सेट किया गया है, जबकि slow_query_log_file उस पथ को निर्धारित करता है जहां आपको अपने धीमे क्वेरी लॉग रखने की आवश्यकता है। यदि यह चर सेट नहीं है, तो यह आपकी MySQL डेटा निर्देशिका के DATA_DIR का उपयोग करेगा।
slow_query_log चर के साथ long_query_time और min_examined_row_limit हैं जो धीमी क्वेरी लॉगिंग के काम करने के तरीके को प्रभावित करते हैं। मूल रूप से, धीमी क्वेरी लॉग SQL स्टेटमेंट के रूप में काम करते हैं जो निष्पादित होने में long_query_time सेकंड से अधिक समय लेते हैं और जांच के लिए कम से कम min_examined_row_limit पंक्तियों की भी आवश्यकता होती है। इसका उपयोग उन प्रश्नों को खोजने के लिए किया जा सकता है जिन्हें निष्पादित करने में लंबा समय लगता है और इसलिए अनुकूलन के लिए उम्मीदवार हैं और फिर आप अपने लिए रिपोर्ट लाने के लिए बाहरी उपकरणों का उपयोग कर सकते हैं, जो बाद में बात करेंगे।
डिफ़ॉल्ट रूप से, व्यवस्थापकीय विवरण (ALTER TABLE, ANALYZE TABLE, CHECK TABLE, CREATE INDEX, DROP INDEX, OPTIMIZE TABLE, and REPAIR TABLE) धीमी क्वेरी लॉग में नहीं आते हैं। ऐसा करने के लिए, आपको चर log_slow_admin_statements को सक्षम करने की आवश्यकता है।
क्वेरी प्रक्रिया सूची और InnoDB स्थिति मॉनिटर
एक सामान्य डीबीए रूटीन में, यह चरण लंबे समय तक चलने वाली क्वेरी या सक्रिय चल रही क्वेरी को निर्धारित करने का सबसे सामान्य तरीका है जो प्रदर्शन में गिरावट का कारण बनता है। यह आपके सर्वर के अटकने का कारण भी बन सकता है, जिसके बाद ढेर सारी कतारें लग सकती हैं जो एक चल रही क्वेरी द्वारा कवर किए गए लॉक के कारण धीरे-धीरे बढ़ रही हैं। आप बस दौड़ सकते हैं,
SHOW [FULL] PROCESSLIST;या
SHOW ENGINE INNODB STATUS \Gयदि आप ClusterControl का उपयोग कर रहे हैं, तो आप इसे <अपने MySQL क्लस्टर का चयन करें> → प्रदर्शन → नीचे की तरह InnoDB स्थिति का उपयोग करके पा सकते हैं,
या <अपने MySQL क्लस्टर का चयन करें> → क्वेरी मॉनिटर → रनिंग क्वेरीज़ ( जो बाद में चर्चा करेगा) सक्रिय प्रक्रियाओं को देखने के लिए, ठीक उसी तरह जैसे एक SHOW PROCESSLIST कैसे काम करता है लेकिन प्रश्नों के बेहतर नियंत्रण के साथ।
MySQL क्वेरी का विश्लेषण करना
धीमे क्वेरी लॉग आपको उन क्वेरी की एक सूची दिखाएगा जिन्हें पहले बताए गए सिस्टम वैरिएबल में दिए गए मानों के आधार पर धीमे के रूप में पहचाना गया है। धीमी क्वेरी की परिभाषा अलग-अलग मामलों में भिन्न हो सकती है क्योंकि कुछ अवसर ऐसे होते हैं कि 10 सेकंड की क्वेरी भी स्वीकार्य होती है और फिर भी धीमी नहीं होती है। हालाँकि, यदि आपका एप्लिकेशन एक OLTP है, तो यह बहुत सामान्य है कि 10 सेकंड या 5 सेकंड की क्वेरी एक समस्या है या आपके डेटाबेस के प्रदर्शन में गिरावट का कारण बनती है। MySQL क्वेरी लॉग आपको इसमें मदद करता है लेकिन लॉग फ़ाइल को खोलने के लिए यह पर्याप्त नहीं है क्योंकि यह आपको उन प्रश्नों का अवलोकन प्रदान नहीं करता है, वे कैसे प्रदर्शन करते हैं, और उनकी घटना की आवृत्ति क्या है। इसलिए, तीसरे पक्ष के टूल इनमें आपकी मदद कर सकते हैं।
pt-query-digest
पेरकोना टूलकिट का उपयोग करना, जिसे मैं सबसे सामान्य डीबीए उपकरण कह सकता हूं, पीटी-क्वेरी-डाइजेस्ट का उपयोग करना है। पीटी-क्वेरी-डाइजेस्ट आपको आपके धीमे क्वेरी लॉग से आने वाली विशिष्ट रिपोर्ट का एक स्पष्ट अवलोकन प्रदान करता है। उदाहरण के लिए, यह विशिष्ट रिपोर्ट किसी विशिष्ट नोड में धीमी क्वेरी रिपोर्ट को समझने का एक स्पष्ट परिप्रेक्ष्य दिखाती है:
# A software update is available:
# 100ms user time, 100ms system time, 29.12M rss, 242.41M vsz
# Current date: Mon Feb 3 20:26:11 2020
# Hostname: testnode7
# Files: /var/log/mysql/mysql-slow.log
# Overall: 24 total, 14 unique, 0.00 QPS, 0.02x concurrency ______________
# Time range: 2019-12-12T10:01:16 to 2019-12-12T15:31:46
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# Exec time 345s 1s 98s 14s 30s 19s 7s
# Lock time 1s 0 1s 58ms 24ms 252ms 786us
# Rows sent 5.72M 0 1.91M 244.14k 1.86M 629.44k 0
# Rows examine 15.26M 0 1.91M 651.23k 1.86M 710.58k 961.27k
# Rows affecte 9.54M 0 1.91M 406.90k 961.27k 546.96k 0
# Bytes sent 305.81M 11 124.83M 12.74M 87.73M 33.48M 56.92
# Query size 1.20k 25 244 51.17 59.77 40.60 38.53
# Profile
# Rank Query ID Response time Calls R/Call V/M
# ==== ================================ ============= ===== ======= =====
# 1 0x00C8412332B2795DADF0E55C163... 98.0337 28.4% 1 98.0337 0.00 UPDATE sbtest?
# 2 0xDEF289292EA9B2602DC12F70C7A... 74.1314 21.5% 3 24.7105 6.34 ALTER TABLE sbtest? sbtest3
# 3 0x148D575F62575A20AB9E67E41C3... 37.3039 10.8% 6 6.2173 0.23 INSERT SELECT sbtest? sbtest
# 4 0xD76A930681F1B4CC9F748B4398B... 32.8019 9.5% 3 10.9340 4.24 SELECT sbtest?
# 5 0x7B9A47FF6967FD905289042DD3B... 20.6685 6.0% 1 20.6685 0.00 ALTER TABLE sbtest? sbtest3
# 6 0xD1834E96EEFF8AC871D51192D8F... 19.0787 5.5% 1 19.0787 0.00 CREATE
# 7 0x2112E77F825903ED18028C7EA76... 18.7133 5.4% 1 18.7133 0.00 ALTER TABLE sbtest? sbtest3
# 8 0xC37F2569578627487D948026820... 15.0177 4.3% 2 7.5088 0.00 INSERT SELECT sbtest? sbtest
# 9 0xDE43B2066A66AFA881D6D45C188... 13.7180 4.0% 1 13.7180 0.00 ALTER TABLE sbtest? sbtest3
# MISC 0xMISC 15.8605 4.6% 5 3.1721 0.0 <5 ITEMS>
# Query 1: 0 QPS, 0x concurrency, ID 0x00C8412332B2795DADF0E55C1631626D at byte 5319
# Scores: V/M = 0.00
# Time range: all events occurred at 2019-12-12T13:23:15
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 4 1
# Exec time 28 98s 98s 98s 98s 98s 0 98s
# Lock time 1 25ms 25ms 25ms 25ms 25ms 0 25ms
# Rows sent 0 0 0 0 0 0 0 0
# Rows examine 12 1.91M 1.91M 1.91M 1.91M 1.91M 0 1.91M
# Rows affecte 20 1.91M 1.91M 1.91M 1.91M 1.91M 0 1.91M
# Bytes sent 0 67 67 67 67 67 0 67
# Query size 7 89 89 89 89 89 0 89
# String:
# Databases test
# Hosts localhost
# Last errno 0
# Users root
# Query_time distribution
# 1us
# 10us
# 100us
# 1ms
# 10ms
# 100ms
# 1s
# 10s+ ################################################################
# Tables
# SHOW TABLE STATUS FROM `test` LIKE 'sbtest3'\G
# SHOW CREATE TABLE `test`.`sbtest3`\G
update sbtest3 set c=substring(MD5(RAND()), -16), pad=substring(MD5(RAND()), -16) where 1\G
# Converted for EXPLAIN
# EXPLAIN /*!50100 PARTITIONS*/
select c=substring(MD5(RAND()), -16), pad=substring(MD5(RAND()), -16) from sbtest3 where 1\G
# Query 2: 0.00 QPS, 0.01x concurrency, ID 0xDEF289292EA9B2602DC12F70C7A041A9 at byte 3775
# Scores: V/M = 6.34
# Time range: 2019-12-12T12:41:47 to 2019-12-12T15:25:14
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 12 3
# Exec time 21 74s 6s 36s 25s 35s 13s 30s
# Lock time 0 13ms 1ms 8ms 4ms 8ms 3ms 3ms
# Rows sent 0 0 0 0 0 0 0 0
# Rows examine 0 0 0 0 0 0 0 0
# Rows affecte 0 0 0 0 0 0 0 0
# Bytes sent 0 144 44 50 48 49.17 3 49.17
# Query size 8 99 33 33 33 33 0 33
# String:
# Databases test
# Hosts localhost
# Last errno 0 (2/66%), 1317 (1/33%)
# Users root
# Query_time distribution
# 1us
# 10us
# 100us
# 1ms
# 10ms
# 100ms
# 1s ################################
# 10s+ ################################################################
# Tables
# SHOW TABLE STATUS FROM `test` LIKE 'sbtest3'\G
# SHOW CREATE TABLE `test`.`sbtest3`\G
ALTER TABLE sbtest3 ENGINE=INNODB\Gperformance_schema का उपयोग करना
यदि आपके पास RDS का उपयोग करने या Google Cloud SQL या Azure SQL जैसी पूरी तरह से प्रबंधित डेटाबेस सेवाओं का उपयोग करने जैसी फ़ाइल तक सीधी पहुंच नहीं है, तो धीमी क्वेरी लॉग एक समस्या हो सकती है। हालाँकि इन सुविधाओं को सक्षम करने के लिए आपको कुछ चरों की आवश्यकता हो सकती है, यह आपके सिस्टम में लॉग इन किए गए प्रश्नों के लिए क्वेरी करते समय काम आता है। आंशिक परिणाम प्राप्त करने के लिए आप मानक SQL कथन का उपयोग करके इसे ऑर्डर कर सकते हैं। उदाहरण के लिए,
mysql> SELECT SCHEMA_NAME, DIGEST, DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT/1000000000000 SUM_TIMER_WAIT_SEC, MIN_TIMER_WAIT/1000000000000 MIN_TIMER_WAIT_SEC, AVG_TIMER_WAIT/1000000000000 AVG_TIMER_WAIT_SEC, MAX_TIMER_WAIT/1000000000000 MAX_TIMER_WAIT_SEC, SUM_LOCK_TIME/1000000000000 SUM_LOCK_TIME_SEC, FIRST_SEEN, LAST_SEEN FROM events_statements_summary_by_digest;
+--------------------+----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+--------------------+--------------------+--------------------+--------------------+-------------------+---------------------+---------------------+
| SCHEMA_NAME | DIGEST | DIGEST_TEXT | COUNT_STAR | SUM_TIMER_WAIT_SEC | MIN_TIMER_WAIT_SEC | AVG_TIMER_WAIT_SEC | MAX_TIMER_WAIT_SEC | SUM_LOCK_TIME_SEC | FIRST_SEEN | LAST_SEEN |
+--------------------+----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+--------------------+--------------------+--------------------+--------------------+-------------------+---------------------+---------------------+
| NULL | 390669f3d1f72317dab6deb40322d119 | SELECT @@`skip_networking` , @@`skip_name_resolve` , @@`have_ssl` = ? , @@`ssl_key` , @@`ssl_ca` , @@`ssl_capath` , @@`ssl_cert` , @@`ssl_cipher` , @@`ssl_crl` , @@`ssl_crlpath` , @@`tls_version` | 1 | 0.0373 | 0.0373 | 0.0373 | 0.0373 | 0.0000 | 2020-02-03 20:22:54 | 2020-02-03 20:22:54 |
| NULL | fba95d44e3d0a9802dd534c782314352 | SELECT `UNIX_TIMESTAMP` ( ) | 2 | 0.0002 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 18c649da485456d6cdf12e4e6b0350e9 | SELECT @@GLOBAL . `SERVER_ID` | 2 | 0.0001 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | dd356b8a5a6ed0d7aee2abd939cdb6c9 | SET @? = ? | 6 | 0.0003 | 0.0000 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 1c5ae643e930af6d069845d74729760d | SET @? = @@GLOBAL . `binlog_checksum` | 2 | 0.0001 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | ad5208ffa004a6ad7e26011b73cbfb4c | SELECT @? | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | ed0d1eb982c106d4231b816539652907 | SELECT @@GLOBAL . `GTID_MODE` | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | cb47e22372fdd4441486b02c133fb94f | SELECT @@GLOBAL . `SERVER_UUID` | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 73301368c301db5d2e3db5626a21b647 | SELECT @@GLOBAL . `rpl_semi_sync_master_enabled` | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 0ff7375c5f076ba5c040e78a9250a659 | SELECT @@`version_comment` LIMIT ? | 1 | 0.0001 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:45:59 | 2020-02-03 20:45:59 |
| NULL | 5820f411e67a393f987c6be5d81a011d | SHOW TABLES FROM `performance_schema` | 1 | 0.0008 | 0.0008 | 0.0008 | 0.0008 | 0.0002 | 2020-02-03 20:46:11 | 2020-02-03 20:46:11 |
| NULL | a022a0ab966c51eb820da1521349c7ef | SELECT SCHEMA ( ) | 1 | 0.0005 | 0.0005 | 0.0005 | 0.0005 | 0.0000 | 2020-02-03 20:46:29 | 2020-02-03 20:46:29 |
| performance_schema | e4833a7c1365b0b4492e9a514f7b3bd4 | SHOW SCHEMAS | 1 | 0.1167 | 0.1167 | 0.1167 | 0.1167 | 0.0001 | 2020-02-03 20:46:29 | 2020-02-03 20:46:29 |
| performance_schema | 1107f048fe6d970cb6a553bd4727a1b4 | SHOW TABLES | 1 | 0.0002 | 0.0002 | 0.0002 | 0.0002 | 0.0000 | 2020-02-03 20:46:29 | 2020-02-03 20:46:29 |
...आप तालिका का उपयोग performance_schema.events_statements_summary_by_digest कर सकते हैं। हालांकि इस बात की संभावना है कि परफॉरमेंस_स्कीमा से टेबल पर एंट्री फ्लश हो जाएगी, आप इसे एक विशिष्ट टेबल में सेव करने का फैसला कर सकते हैं। प्रदर्शन स्कीमा के साथ Percona MySQL क्वेरी डाइजेस्ट की इस बाहरी पोस्ट पर एक नज़र डालें।
यदि आप सोच रहे हैं कि हमें प्रतीक्षा समय कॉलम (SUM_TIMER_WAIT, MIN_TIMER_WAIT_SEC, AVG_TIMER_WAIT_SEC) को विभाजित करने की आवश्यकता क्यों है, तो ये कॉलम पिकोसेकंड का उपयोग कर रहे हैं, इसलिए आपको कुछ गणित या कुछ राउंड अप करने की आवश्यकता हो सकती है यह आपके लिए अधिक पठनीय है।
ClusterControl का उपयोग करके धीमी क्वेरी का विश्लेषण करना
यदि आप ClusterControl का उपयोग कर रहे हैं, तो इससे निपटने के विभिन्न तरीके हैं। उदाहरण के लिए, मेरे पास नीचे दिए गए एक मारियाडीबी क्लस्टर में, यह आपको निम्न टैब (क्वेरी मॉनिटर) और यह ड्रॉप-डाउन आइटम दिखाता है (टॉप क्वेरीज़, रनिंग क्वेरीज़, क्वेरी आउटलेयर):
- शीर्ष क्वेरी - आपके डेटाबेस क्लस्टर के सभी नोड्स पर चलने वाली आपकी सभी शीर्ष क्वेरी की समेकित सूची
- रनिंग क्वेरीज़ - MySQL में SHOW FULL PROCESSLIST कमांड के समान अपने डेटाबेस क्लस्टर पर वर्तमान रनिंग क्वेरीज़ देखें
- क्वेरी आउटलेयर - उन क्वेरी को दिखाता है जो आउटलेयर हैं। एक बाहरी एक ऐसी क्वेरी है जो उस प्रकार की सामान्य क्वेरी से अधिक समय लेती है।
उसके ऊपर, ClusterControl ग्राफ़ का उपयोग करके क्वेरी प्रदर्शन को भी कैप्चर करता है जो आपको क्वेरी प्रदर्शन के संबंध में आपका डेटाबेस सिस्टम कैसा प्रदर्शन करता है, इसकी एक त्वरित अनदेखी प्रदान करता है। नीचे देखें,
रुको, यह अभी खत्म नहीं हुआ है। ClusterControl प्रोमेथियस का उपयोग करके एक उच्च रिज़ॉल्यूशन मीट्रिक भी प्रदान करता है और बहुत विस्तृत मीट्रिक दिखाता है और सर्वर से रीयल-टाइम आंकड़े कैप्चर करता है। हमने अपने पिछले ब्लॉगों में इस पर चर्चा की है जो ब्लॉग के दो भाग श्रृंखला में विभाजित हैं। भाग 1 और फिर भाग 2 ब्लॉग देखें। यह आपको न केवल धीमी क्वेरी बल्कि आपके MySQL, MariaDB, या Percona डेटाबेस सर्वर के समग्र प्रदर्शन की कुशलता से निगरानी करने की पेशकश करता है।
ClusterControl में अन्य टूल भी हैं जो पॉइंटर्स और संकेत प्रदान करते हैं जो धीमी क्वेरी प्रदर्शन का कारण बन सकते हैं, भले ही यह अभी तक नहीं हुआ हो या धीमी क्वेरी लॉग द्वारा कैप्चर किया गया हो। नीचे देखे गए प्रदर्शन टैब को देखें,
ये आइटम आपको निम्नलिखित प्रदान करते हैं:
- अवलोकन - आप इस पृष्ठ पर विभिन्न डेटाबेस काउंटरों के ग्राफ़ देख सकते हैं
- सलाहकार - ClusterControl> मैनेज> ClusterControl DSL का उपयोग करके डेवलपर स्टूडियो में बनाए गए शेड्यूल किए गए सलाहकारों के परिणामों की सूची।
- DB स्थिति - DB स्थिति SHOW STATUS स्टेटमेंट के समान, आपके सभी डेटाबेस नोड्स में MySQL स्थिति का त्वरित अवलोकन प्रदान करती है
- DB चर - DB चर MySQL चर का एक त्वरित अवलोकन प्रदान करते हैं जो आपके सभी डेटाबेस नोड्स में सेट होते हैं, जैसे SHOW GLOBAL VARIABLES कथन
- DB ग्रोथ - पिछले 30 दिनों के लिए दैनिक आधार पर आपके डेटाबेस और टेबल ग्रोथ का सारांश प्रदान करता है।
- InnoDB Status - SHOW ENGINE INNODB STATUS कमांड के समान, चयनित होस्ट के लिए वर्तमान InnoDB मॉनिटर आउटपुट प्राप्त करता है।
- स्कीमा एनालाइज़र - MyISAM स्टोरेज इंजन का उपयोग करके अनुपलब्ध प्राथमिक कुंजी, अनावश्यक अनुक्रमणिका और तालिकाओं के लिए आपके डेटाबेस स्कीमा का विश्लेषण करता है।
- लेन-देन लॉग - डेटाबेस क्लस्टर में लंबे समय से चल रहे लेन-देन और गतिरोध को सूचीबद्ध करता है जहां आप आसानी से देख सकते हैं कि कौन से लेनदेन गतिरोध पैदा कर रहे हैं। डिफ़ॉल्ट क्वेरी समय सीमा 30 सेकंड है।
निष्कर्ष
MySQL के साथ अपने MySQL प्रदर्शन समस्या का पता लगाना वास्तव में कठिन नहीं है। ऐसे कई बाहरी उपकरण हैं जो आपको वह दक्षता और क्षमताएं प्रदान करते हैं जिनकी आप तलाश कर रहे हैं। सबसे महत्वपूर्ण बात यह है कि, इसका उपयोग करना आसान है और आप काम पर उत्पादकता प्रदान करने में सक्षम हैं। सबसे बकाया मुद्दों को ठीक करें या किसी आपदा के घटित होने से पहले ही उससे बचें।
