PERFORMANCE_SCHEMA का परिचय

MySQL पर कई पत्थरों को फेंक दिया गया था, सत्रों का पता लगाने की क्षमता में कमी और आँकड़े पैक रिपोर्ट को हटाने के कारण, जो वास्तव में डेटाबेस को लोड करते हैं। संस्करण 5.5 से शुरू होकर, MySQL अंततः इस समस्या को हल करने की आवश्यकता से हैरान था और उसने एक प्रोटोटाइप रखा, जो भविष्य में, MySQL में इसी तरह के उपकरणों के निर्माण का कारण बन सकता है। मेरी कहानी आज ऐसे ही शक्तिशाली (दुर्भाग्य से MySQL डेवलपर्स के लिए) टूल के बारे में होगी, जैसे कि PERFORMANCE_SCHEMA । इसलिए हम my.cnf कॉन्फ़िगरेशन फ़ाइल में performance_schema = ON सेट करते हैं, और इसकी सीमित, लेकिन पहले से ही बेहद दिलचस्प विशेषताओं का अध्ययन करना शुरू करते हैं।

पहला, थोड़ा सिद्धांत

इस योजना के साथ काम करने के तरीके पर इंतजार करने वाली रेक पर जाने से बचने के लिए, मैं सिद्धांत में एक छोटा सा भ्रमण करूंगा। यदि आप पहले से ही जानते हैं कि यह योजना कैसे काम करती है, लेकिन अभी तक यह समझ में नहीं आया है कि इसे कैसे लागू किया जा सकता है, तो आप सीधे व्यावहारिक भाग पर जा सकते हैं।
सबसे पहले। PERFORMANCE_SCHEMA स्थिर है। हमारे लिए इसका क्या मतलब है? और ऐसा क्यों हुआ? MySQL अपनी गलतियों से थोड़ा सीख रहा है, और INFORMATION_SCHEMA पर काम करने के बाद, और विशेष रूप से INFORMATION_SCHEMA.PROCESSLIST दृश्य पर, उन्होंने सिस्टम के विचारों के साथ काम करने के तरीके को बदल दिया। SHOW PROCESSLIST कमांड (और इस तरह) का उपयोग करने से सर्वर # 56299 , # 61186 फ्रीज हो सकता है। इस गलतफहमी का कारण बग # 42930 है , जो स्पष्ट रूप से बताता है कि इस कमांड को चलाने से LOCK_thread_count लॉक सेट होने का कारण बनता है। यह इस तथ्य की ओर जाता है कि MySQL नहीं कर सकता: एक नया सत्र कनेक्ट करें, समाप्त हो गया डिस्कनेक्ट करें, एक नया बाइनरी लॉग बनाएं, आदि। चूंकि इस म्यूटेक्स को लॉक करना पूरे इंजन के लिए महत्वपूर्ण है। यह थ्रेड द्वारा गतिशील मेमोरी आवंटन की संभावना के कारण किया गया था। ताकि एक बिंदु पर, सत्र के मापदंडों का अनुरोध करते समय, दृश्य मुक्त मेमोरी क्षेत्र तक पहुंच न हो, एक त्रुटि प्राप्त करें और पूरे सर्वर को भरें। स्रोत कोड PERFORMANCE_SCHEMA टाइप मॉलॉक की मेमोरी के गतिशील आवंटन के लिए आदेशों का उपयोग नहीं करता है। सर्वर स्टार्टअप के दौरान मेमोरी का आवंटन केवल एक बार किया जाता है। इसलिए, इस योजना के सभी मापदंडों को रनटाइम में नहीं बदला जा सकता है। एक ओर, यह बिना लॉक के इस सर्किट को संचालित करना संभव बनाता है, दूसरी तरफ, इसके कॉन्फ़िगरेशन के साथ कुछ समस्याएं हैं, जिनमें से कुछ को PERFORMANCE_SCHEMA इंजन में शामिल उपकरणों द्वारा बाईपास किया गया है । शुरू करने के बाद, आप सर्वर को रिबूट किए बिना इस इंजन को पूरी तरह से अक्षम नहीं कर पाएंगे।
दूसरा। चूंकि यह कार्यक्षमता पूरे डेटाबेस की निगरानी करती है, इसलिए यह स्वाभाविक रूप से कुछ संसाधनों का उपभोग करती है। खपत किए गए संसाधनों की मात्रा सर्किट के कॉन्फ़िगरेशन पर निर्भर करती है, जिसे अनुरोध को पूरा करके देखा जा सकता है।

  'प्रदर्शन%' जैसे चर दिखाएं;
 + ------------------------------------------------- - + --------- +
 |  चर_नाम |  मान |
 + ------------------------------------------------- - + --------- +
 |  performance_schema |  पर | 
 |  प्रदर्शन_सखेमा_मैक्स_कॉन्ड_स्टैंस |  1000 | 
 |  प्रदर्शन_सेहमा_मैक्स_फाइल_स्टेंस |  10000 | 
 |  प्रदर्शन_सचेमा_मैक्स_मुटेक्स_साइनेंस |  1,000,000 | 
 |  प्रदर्शन_सखेमा_मैक्स_क्रॉवल_बैंस |  1,000,000 | 
 |  प्रदर्शन_सचेमा_मैक्स_टेबल_बैंस |  50000 | 
 |  प्रदर्शन_सखेमा_मैक्स_थ्रेड_स्टेंस |  1000 | 
 |  प्रदर्शन_सखेमा_मैक्स_फाइल_हैंडल्स |  32768 | 
 |  प्रदर्शन_सखेमा_मैक्स_टेबल_हैंडल्स |  100,000 | 
 |  प्रदर्शन_सेहमा_देवता_वापस_हस्तोन_लंग_सलाई |  10000 | 
 |  प्रदर्शन_सेहमा_देवता_वात_हिस्त_न्यास |  10 | 
 |  प्रदर्शन_सखेमा_मैक्स_काण्ड_क्लास |  80 | 
 |  प्रदर्शन_सेहमा_मैक्स_फाइल_क्लास |  50 | 
 |  प्रदर्शन_सेहमा_मैक्स_मुटेक्स_क्लास |  200 | 
 |  प्रदर्शन_सखेमा_मैक्स_क्रॉल_क्लास |  30 | 
 |  प्रदर्शन_सचेमा_मैक्स_थ्रेड_क्लास |  50 | 
 + ------------------------------------------------- - + --------- + 

पहले पैरामीटर - उदाहरण सबसे महत्वपूर्ण हैं, उनकी पर्याप्त संख्या डेटाबेस के साथ होने वाली हर चीज की पूरी तरह से निगरानी करने की अनुमति देगी। हालांकि, यहां मुख्य बात यह अति नहीं है, क्योंकि बफर - पटल में प्रत्येक 16-किलोबाइट ब्लॉक के लिए एक म्यूटेक्स + rwlock जोड़ी बनाई गई है। यही है, अगर डेटाबेस पर पर्याप्त मात्रा में रैम आवंटित की जाती है, तो आप संसाधनों के डॉफिग को जला देंगे, और यदि आप इन मापदंडों को बहुत छोटा सेट करते हैं, तो आप सभी सिस्टम प्रक्रियाओं की निगरानी नहीं कर पाएंगे। कैसे समझें कि आपने उन्हें सही तरीके से सेट किया है, मैं थोड़ा कम कहूंगा।
संभाल के मापदंडों के अनुसार , मुझे लगता है कि नाम से सब कुछ स्पष्ट है। यह खुली तालिकाओं और फ़ाइलों की अधिकतम संख्या है जिन्हें आप मॉनिटर कर सकते हैं।
आकार मापदंडों का आकार आपके डेटाबेस पर लोड पर निर्भर करता है। आपको इसे खुद उठाना होगा। उदाहरण के लिए, यदि आप, क्वेरी शुरू करते समय, ईवेंट्स_वाइट्स_होस्टर_लॉन्ग में इसके आँकड़े देखने का समय नहीं रखते हैं , तो आपको इस पैरामीटर को बढ़ाने पर विचार करना चाहिए।
क्लास के पैरामीटर सिद्धांत में बहुत महत्वपूर्ण नहीं हैं, क्योंकि वे अधिकतम प्रकार के मॉनिटर किए गए ऑब्जेक्ट दिखाते हैं। यहां प्लगइन डेवलपर्स का वर्णन करना आवश्यक है। यदि वे निगरानी में कुछ प्रकार के म्यूटेक्स को शामिल करना आवश्यक मानते हैं, तो वे आमतौर पर उनकी संख्या का संकेत देते हैं। उदाहरण के लिए, InnoBD इंजन के लिए केवल 35 वर्ग हैं।
यह ध्यान रखना महत्वपूर्ण है कि इन मापदंडों को सेट करते समय आपको लालची होने की आवश्यकता नहीं है, क्योंकि यदि आप उन्हें बंद करते हैं, तो जब PERFORMANCE_SCHEMA के खाली तत्वों की खोज होती है, तो यह बहुत धीमा हो जाएगा। जो, सिद्धांत रूप में, तार्किक है, क्योंकि किसी सरणी में खाली तत्व जो 90% खाली है, उसे उस सरणी में खोजना आसान है, जो 90% पूर्ण है।
इसलिए PERFORMANCE_SCHEMA को चालू करने के बाद , यह संसाधनों को खाने लगता है ... कभी-कभी बहुत कठिन होता है। उदाहरण के लिए, यहाँ एक औद्योगिक डेटाबेस से परिणाम है।

  शो इंजन प्रदर्शन_शेष स्थिति;
 + -------------------- + ---------------------------- ---------------------------- + ----------- +
 |  प्रकार |  नाम |  स्थिति |
 + -------------------- + ---------------------------- ---------------------------- + ----------- +
 ...
 |  performance_schema |  घटनाओं_वाइट्स_हिस्ट्री मॉनीरी |  1,200,000 | 
 ...
 |  performance_schema |  इवेंट्स_वाइट्स_हिस्ट्री_लॉन्ग मॉमोरी |  1,200,000 | 
 ...
 |  performance_schema |  mutex_instances.memory |  136000000 | 
 ...
 |  performance_schema |  rwlock_instances.memory |  200000000 | 
 ...
 |  performance_schema |  file_instances.memory |  6240000 | 
 ...
 |  performance_schema |  इवेंट_वाइट्स_सुमरी_बिन_थ्रेड_बीए_वेंट_नाम.मोरी |  17280000 | 
 ...
 |  performance_schema |  (pfs_table_share) .memory |  24,400,000 | 
 ...
 |  performance_schema |  performance_schema.memory |  394468704 | 
 + -------------------- + ---------------------------- ---------------------------- + ----------- + 

यदि आपके पास 400Mb मुफ्त रैम है, तो इसे चालू करें!
मेमोरी खपत के अलावा, यह योजना क्वेरी निष्पादन की गति को भी कम करती है। कुछ अनुमानों के अनुसार, सभी ग्राहकों (जिनके बारे में मैं नीचे चर्चा करूंगा) के साथ, प्रदर्शन में गिरावट पढ़ने के लिए लगभग 25% और लेखन के लिए 19% तक पहुंच जाती है, लेकिन पढ़ने के लिए 8% की निगरानी के बिना केवल प्रदर्शन_काँटा = चालू करना। और इस तथ्य के मद्देनजर कि आप इसे वैसे ही बंद नहीं कर सकते - सावधान रहें।
तीसरी बात जिस पर ध्यान देना है वह है निगरानी की गुणवत्ता। जैसा कि मैंने ऊपर लिखा है, यदि आपके पास एक बड़ा डेटाबेस है, तो डिफ़ॉल्ट रूप से निर्धारित कई पैरामीटर आपको सूट नहीं कर सकते हैं। कमांड चलाकर आप इस कष्टप्रद गलतफहमी के बारे में जान सकते हैं

  "प्रदर्शन%" जैसी स्थिति दिखाएं;
 + ------------------------------------------ + ------ - +
 |  चर_नाम |  मान |
 + ------------------------------------------ + ------ - +
 |  प्रदर्शन_सखेमा_कांड_क्लास_लोस्ट |  0 | 
 ...
 |  प्रदर्शन_सखेमा_थ्रेड_स्टेंस_लॉस्ट |  0 | 
 + ------------------------------------------ + ------ - + 

यदि कोई भी काउंटर शून्य से ऊपर मान लेता है, तो संबंधित पैरामीटर को बढ़ाना होगा।
चौथा। यदि आप पहले ही समझ गए हैं कि आपको वास्तव में क्या मॉनिटर करना चाहिए, और इसके लिए कौन से पैरामीटर जिम्मेदार हैं, तो आप सिस्टम के कुछ संसाधनों को बचा सकते हैं। इस तालिका को अपडेट करने के लिए स्वतंत्र महसूस करें।

  setup_consumers से * का चयन करें;
 + ---------------------------------------------- + - ------- +
 |  NAME |  ENABLED |
 + ---------------------------------------------- + - ------- +
 |  event_waits_current |  हाँ | 
 |  event_waits_history |  हाँ | 
 |  घटनाएँ_वाइट्स_हिस्ट्री_लॉन्ग |  हाँ | 
 ...
 |  file_summary_by_event_name |  हाँ | 
 |  file_summary_by_instance |  हाँ | 
 + ---------------------------------------------- + - ------- + 

या यह

  setup_instenders से * का चयन करें;
 + ------------------------------------------------- ----------- + --------- + ------- +
 |  NAME |  ENABLED |  टाईमेड |
 + ------------------------------------------------- ----------- + --------- + ------- +
 |  वेट / सिंक्र / म्यूटेक्स / एसक्यूएल / पेज :: लॉक |  हाँ |  हाँ | 
 |  प्रतीक्षा करें / synch / mutex / sql / TC_LOG_MMAP :: LOCK_sync |  हाँ |  हाँ | 
 ...
 |  प्रतीक्षा करें / io / फ़ाइल / innodb / innodb_temp_file |  हाँ |  हाँ | 
 + ------------------------------------------------- ----------- + --------- + ------- + 

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

  setup_timers से * का चयन करें;
 + ------ + ------------ +
 |  NAME |  TIMER_NAME |
 + ------ + ------------ +
 |  प्रतीक्षा करें |  CYCLE | 
 + ------ + ------------ + 

एक कैवियट के साथ। यदि आप प्रोसेसर चक्रों में काम करते हैं, तो आपके पास उच्चतम संभव सटीक मान हैं, यदि आप सेकंड में स्विच करते हैं, तो आपको काफी त्रुटि मिलेगी, जिसका मूल्य प्रत्येक मशीन के लिए अद्वितीय है और तालिका से पता लगाया जा सकता है।

  प्रदर्शन * चयनकर्ताओं से * का चयन करें;
 + ------------- + ----------------- + ----------------- - + ---------------- +
 |  TIMER_NAME |  TIMER_FREQUENCY |  TIMER_RESOLUTION |  TIMER_OVERHEAD |
 + ------------- + ----------------- + ----------------- - + ---------------- +
 |  CYCLE |  2395388059 |  1 |  72 | 
 |  NANOSECOND |  1,000,000,000 |  1000 |  513 | 
 |  MICROSECOND |  1,000,000 |  1 |  207 | 
 |  MILLISECOND |  1038 |  1 |  225 | 
 |  टिक |  101 |  1 |  531 | 
 + ------------- + ----------------- + ----------------- - + ---------------- + 

अभ्यास से, मैं कह सकता हूं कि ऐसे (~ 500) चक्रों को नैनोसेकंड में परिवर्तित करने के लिए ओवरहेड्स परीक्षण के कुल समय का लगभग 5% भक्षण करेंगे। हालांकि, मैंने उन कारों को देखा, जिन पर ये ओवरहेड्स 12% से अधिक बनाते हैं। इसलिए वास्तविक समय में परिणामों की व्याख्या करते समय सावधान रहें।

और इसलिए हम सेटअप का पता लगाते हैं। अब शुरू करते हैं कि हम लोड पर डेटा को कहां देख सकते हैं और सबसे महत्वपूर्ण बात यह है कि कैसे?

  टेबल दिखाएं;
 + ---------------------------------------------- +
 |  Tables_in_performance_schema |
 + ---------------------------------------------- +
 ...
 |  event_waits_current | 
 |  event_waits_history | 
 |  घटनाएँ_वाइट्स_हिस्ट्री_लॉन्ग | 
 |  event_waits_summary_by_instance | 
 |  इवेंट्स_वाइट्स_सुमरी_बाइ_थ्रेड_बीए_वेंट_नाम | 
 |  इवेंट्स_वाइट्स_सुमरी_ग्लोबल_बीए_वेंट_नाम | 
 ...
 |  file_summary_by_event_name | 
 |  file_summary_by_instance | 
 ...
 |  धागे | 
 + ---------------------------------------------- + 

थ्रेड्स - उन प्रक्रियाओं के लिंक होते हैं जो अभी भी INFORMATION_SCHEMA.PROCESLIST में रहते हैं, यदि प्रक्रिया मर गई है, तो थ्रेड कुछ समय के लिए जीवित रहेगा, इसलिए यदि आप जुड़ते हैं, तो बाहरी कनेक्शन का उपयोग करें।
इवेंट_वाइट्स_क्रांति ( इतिहास , हेरोट्री_लंग ) - इसमें सबसे हालिया प्रतीक्षा घटनाएं शामिल हैं, तालिकाओं का आकार मापदंडों द्वारा निर्धारित किया गया है। यह सबसे आवश्यक तालिका है, उन लोगों के लिए जिन्हें समझ से बाहर ताले का सामना करना पड़ता है या यह समझने की कोशिश कर रहे हैं कि कोड का कौन सा भाग धीमा हो रहा है, क्योंकि इसमें स्रोत लाइन का लिंक है।
घटनाओं_वाइट्स_सुमरी - में ऐसी जानकारी होती है जो आपको अस्पताल में औसत तापमान प्राप्त करने की अनुमति देती है। डीबीए के लिए सबसे दिलचस्प टेबल।
file_summary - इनपुट आउटपुट पर आंकड़े, आपको सबसे हॉट टेबल प्राप्त करने की अनुमति देते हैं। यहाँ यह समझना आवश्यक है कि यदि आपने डेटाबेस बनाते समय innodb_file_per_table = 1 को सेट नहीं किया है, तो आप यहाँ InnoDB इंजन के लिए कुछ भी अच्छा नहीं देख पाएंगे।
सभी इवेंट टेबल में, इनपुट आउटपुट के बारे में सभी जानकारी भी होती है। चूंकि यह सबसे अधिक समझ में फ़ाइल_सुमरी में डुप्लिकेट हो जाएगा, इसलिए उनसे अनुरोध के लिए 'प्रतीक्षा / io / फ़ाइल /%' जैसे इवेंट_नाम को अनदेखा करना बेहतर है।
ऐसा लगता है कि हमने सिद्धांत समाप्त कर दिया है, चलो अभ्यास करने के लिए आगे बढ़ते हैं। यह सब क्यों आवश्यक है और इस योजना से क्या उपयोगिता प्राप्त की जा सकती है।

अभ्यास

दुर्भाग्य से। फिलहाल, आप इस योजना से उतनी जानकारी नहीं निकाल सकते हैं जितनी हम चाहेंगे, मैं मुख्य दृष्टिकोण का वर्णन करूंगा।

सबसे हॉट टेबल

  substring_index (file_name, '/', -1), file_name, event_name, count_read, count_write से file_summary_by_instance जहां COUNT_READ + COUNT_WRITE> 0 आर्डर द्वारा COUNT_READ + COUNT_WRITE desc 30 सीमित करें;
 + ------------------------------------- + ----------- --------------------------- + ------------ + --------- ---- +
 |  file_name |  घटना_नाम |  count_read |  count_write |
 + ------------------------------------- + ----------- --------------------------- + ------------ + --------- ---- +
 |  proc.MYD |  प्रतीक्षा करें / io / फ़ाइल / myisam / dfile |  102716781 |  0 | 
 |  ib_logfile1 |  प्रतीक्षा करें / io / फ़ाइल / innodb / innodb_log_file |  0 |  1008958 | 
 |  innodb1 |  प्रतीक्षा करें / io / फ़ाइल / innodb / innodb_data_file |  43106 |  958070 | 
 |  घटना। एमवाईडी |  प्रतीक्षा करें / io / फ़ाइल / myisam / dfile |  633053 |  126470 | 
 |  # sql149f_301db7_b.frm |  प्रतीक्षा करें / io / फ़ाइल / sql / FRM |  180012 |  0 | 
 ...
 |  घटना। एमवाई |  प्रतीक्षा करें / io / फ़ाइल / myisam / kfile |  0 |  126466 | 
 |  # sql149f_337a12_3.frm |  प्रतीक्षा करें / io / फ़ाइल / sql / FRM |  71372 |  0 | 
 ...
 |  job_events # P # job_events_201108.ibd |  प्रतीक्षा करें / io / फ़ाइल / innodb / innodb_data_file |  8 |  34662 | 
 ...
 |  olap_transactions_hourly_amount.frm |  प्रतीक्षा करें / io / फ़ाइल / sql / FRM |  3637 |  8264 | 
 + ------------------------------------- + ----------- --------------------------- + ------------ + --------- ---- +

आपको किन बातों पर ध्यान देना चाहिए:
proc.MYD - एक निर्देशिका जिसमें प्रक्रिया कोड होते हैं, कुछ भी नहीं लिखते हैं, बहुत कुछ पढ़ते हैं। यह ड्राइवर को स्थापित करने के लायक है ताकि प्रक्रियाओं को कैश किया जाए और कनेक्शन पूल चालू हो।
ib_logfile1 - ठीक है, यहाँ हम शक्तिहीन हैं, यह अभी भी InnoDB है ।
innodb1 - या तो हमने innodb_file_per_table = 1 सेट करने से पहले InnoDB टेबल बनाए या हम जो कुछ भी लिखते हैं उसके अधिक विस्तृत स्पष्टीकरण के लिए MySQL 5.6 की प्रतीक्षा कर रहे हैं।
event.MYD , event.MYI - ठीक है, मैं पहले ही इस उत्पाद की गुणवत्ता के बारे में बात कर चुका हूं ।
tmp / # sql149f_301db7_b.frm और उनके जैसे अन्य - ठीक है, कोई व्यक्ति सक्रिय रूप से अस्थायी तालिकाओं का उपयोग करता है - आपको घटनाओं में अधिक विस्तृत जानकारी देखने की आवश्यकता है। घटनाओं के लिए, आप प्रक्रिया सूची में शामिल हो सकते हैं और यदि आप भाग्यशाली हैं तो आप उन्हें रंगे हाथों पकड़ लेंगे।
job_events # P # job_events_201108.ibd innodb की सबसे हॉट टेबल में से एक है। हम बहुत लिखते हैं, कुछ भी नहीं पढ़ते हैं, यह वास्तुकला के बारे में सोचने लायक है, चाहे हमने सब कुछ सही किया हो।
olap_transactions_hourly_amount.par - ठीक है, यहां सब कुछ ईमानदार लगता है, हर घंटे हम विभाजन को बदलते हैं, पढ़ने का स्तर लगभग रिकॉर्डिंग स्तर से मेल खाता है।
यह केवल विश्लेषण का एक उदाहरण है; बेशक, आपके पास कई तालिकाएँ नहीं हो सकती हैं, लेकिन आपको और व्यवस्थापक को यह जानना होगा कि प्रत्येक तालिका के साथ क्या किया जा रहा है।

सबसे गर्म ताले

  Event_name, source, sum (टाइमर_वाइट) टाइमर_wait को इवेंट_waits_history_long से चुनें, जहां event_name इवेंट_name द्वारा 'प्रतीक्षा / io / फ़ाइल%' समूह को पसंद नहीं करता है, स्रोत क्रम 3 डीएससी सीमा 30 तक;
 + ------------------------------------------------- ----- + -------------------- + --------------- +
 |  घटना_नाम |  स्रोत |  टाइमर_वाइट |
 + ------------------------------------------------- ----- + -------------------- + --------------- +
 |  प्रतीक्षा / synch / cond / sql / COND_queue_state |  event_queue.cc:765 |  1998358450083 | 
 |  प्रतीक्षा करें / synch / rwlock / myisam / MYISAM_SHARE :: key_root_lock |  mi_rnext.c: 43 |  82397115 | 
 ...
 |  प्रतीक्षा करें / synch / mutex / sql / LOCK_plugin |  sql_plugin.cc:744 |  607986 | 
 + ------------------------------------------------- ----- + -------------------- + --------------- + 

(इस तालिका की जानकारी लाइव डेटाबेस पर बहुत तेज़ी से अपडेट की गई है, इसलिए अस्पताल में औसत तापमान की गणना करने के लिए इवेंट_वाइट्स_सुमरी_बिन_थ्रेड_ईवेंट_नाम का उपयोग करना बेहतर है, कोड की कोई विशिष्ट रेखा नहीं है, लेकिन जानकारी अधिक उद्देश्य है, उदाहरण केवल दिखाने के लिए प्रदान किया गया है)
पहले और दूसरे स्थान के बीच का अंतर डरावना है। हम स्रोत पर जाते हैं।

  अगर (thd-> मारे गए)
   {
     अगर (संयम)
       mysql_cond_wait (& COND_queue_state, और LOCK_event_queue);
     अन्यथा
       mysql_cond_timedwait (& COND_queue_state, और LOCK_event_queue, abstime);  // यहाँ यह हमारी लाइन है
   } 

ठीक है, ऐसा लगता है कि यह ठीक है, यह सिर्फ एक पर्ची है। लेकिन आपको स्वीकार करना होगा, MySQL के सोर्स कोड में डील करना बिल्कुल भी कपूर नहीं है। यदि इसके बिना गतिरोध हैं, तो मैं म्यूटेक्स से उत्पन्न होने वाली सबसे आम समस्याओं के शीर्ष को रेखांकित करूंगा।
MySQL के हाल के संस्करणों में, प्रचारित सुविधा innobd_adaptive_hash_index प्रकट हुई है । जैसा कि आप जानते हैं, बी-ट्री ऑपरेशन में एक खोज इष्टतम नहीं है। इसलिए, यदि आपकी तालिका छोटी है, और सूचकांक रैम में फिट हो सकता है, तो MySQL इस बफर में हैश मैप के रूप में इस सूचकांक की एक प्रति बनाता है। इस प्रकार खोज यथासंभव तेज हो जाती है। हालाँकि, इस समाधान में एक नुकसान है। इस कैश में केवल एक सिंक्रनाइज़ेशन म्यूटेक्स है। किसी भी टेबल या इंडेक्स के लिए पढ़ने और लिखने पर इस महत्वपूर्ण सेक्शन तक पहुँच दी जाती है, इसलिए यदि आपके पास बड़ी मात्रा में प्रतिस्पर्धी लेन-देन है और यह म्यूटेक्स गर्म हो जाता है तो आप क्वेरी टॉप में देखेंगे।
| wait/synch/rwlock/innodb/btr_search_latch | btr0sea.c:XXX | 183897 |
यदि हां, तो आपको इस विकल्प को अक्षम करने पर विचार करना चाहिए।
InnoDB म्यूटेक्स और रीड-राइट लॉक को लागू करने के लिए थ्रेड्स के बजाय परमाणु संचालन का उपयोग करता है। इस तरह के कार्यान्वयन को वर्तमान में मल्टीप्रोसेसर सिस्टम के लिए सबसे इष्टतम माना जाता है। ताले के बजाय, जहां तक ​​मैं समझता हूं, कुछ काउंटरों में वृद्धि होती है। यदि आप प्रतीक्षा प्रकार / सूचना / लंच / म्यूटेक्स / इनबॉक्स / rw_lock_mutex या प्रतीक्षा / सिंक / म्यूटेक्स / इंसोडब / थ्रोट_लोकल_मुटेक्स में सबसे ऊपर हैं, तो इन स्रोतों पर जाएं और जांचें कि क्या इन अपेक्षाओं की रेखा #ifdef INNODBB_Rutex_mutex पर नहीं है। शुरुआती कंपाइलर और आप #else / * INNODB_RW_LOCKS_USE_ATOMICS * / पर जाएं और इस तरह इस तकनीक के सभी आकर्षण का उपयोग न करें।
नवीनतम InnoDB प्लगइन्स में से एक में, एक विशेष म्यूटेक्स प्रतीक्षा / synch / mutex / innodb / flush_list_mutex पेश किया गया था । जैसा कि आप जानते हैं, कुछ समय के लिए रैम में बदलाव के बाद सभी गंदे ब्लॉक, और केवल कुछ समय के बाद डिस्क में फ्लश हो जाते हैं। पहले, बफर पूल के म्यूटेक्स का उपयोग रीसेट को सिंक्रनाइज़ करने के लिए किया गया था, हालांकि, यह एक असफल निर्णय था और इस प्रक्रिया के लिए एक अलग महत्वपूर्ण खंड बनाया गया था। यह आपको बेहतर पैमाने पर, और डिस्क पर लिखने की प्रक्रिया को ट्रैक करने की अनुमति देता है।
यदि आप बड़ी संख्या में म्यूटेक्स अपेक्षाएँ देखते हैं / synch / rwlock / innodb / checkpoint_lock तो आपको लॉग फ़ाइलों का आकार बढ़ाने की आवश्यकता है या आपका innodb_max_dirty_pages_pct_ value बहुत कम है। चौकी प्रक्रिया को कम आक्रामक बनाने की कोशिश करें।
शायद सबसे लोकप्रिय प्रतीक्षा होगी / सिंक / म्यूटेक्स / इनोडब / बुफ़_पुल_म्यूटेक्स । यह म्यूटेक्स बफर पूल में डेटा लोड करने के लिए जिम्मेदार है। यदि यह म्यूटेक्स सबसे ऊपर लटका हुआ है, तो आपके पास दो विकल्प हैं: डेटाबेस आर्किटेक्चर को बदलना ताकि जितना संभव हो उतना कम डेटा रैम में लोड हो, या XtraDB पर स्विच हो। मैंने इस तरह के संस्करण को सुना है कि यह प्लगइन इनोबीडी की तुलना में बड़े डेटाबेस के साथ अधिक कुशलता से काम करता है, लेकिन मैंने इसे स्वयं जांच नहीं किया।
ऐसे ताले हैं जो बस कहते हैं कि सब कुछ खराब है, लेकिन कोई भी आपकी मदद नहीं कर सकता है। उदाहरण के लिए, कर्नेल_मुटेक्स जैसे ताले उन लोगों के लिए बहुत दर्दनाक हैं जिनके पास कई लेनदेन हैं, क्योंकि प्रत्येक लेनदेन को बनाते समय, इसे वर्तमान लेनदेन की पूरी सूची को अपने मेमोरी क्षेत्र में कॉपी करने की आवश्यकता होती है। यदि सूची बल्कि बड़ी है, तो लॉक (अन्य प्रक्रियाओं में महत्वपूर्ण) लंबे समय तक आयोजित किया जाएगा।
अपने अभ्यास से, मैं कह सकता हूं कि इनोडब प्लगइन के लिए म्यूटेक्स सबसे अच्छा वर्णित हैं।
बाकी के लिए, ज्यादातर मामलों में आपको स्रोत पढ़ना होगा।
इसके अलावा, इस योजना का उपयोग करके, आप कुल आवृत्ति फ़्रीज़ के दौरान ताले ट्रैक कर सकते हैं। लेकिन यह पूरी तरह से अलग कहानी है।

निष्कर्ष

यह तंत्र, ऑरेकल में हमारे बहुत-प्यारे निशानों और आँकड़ों के पैक की शक्ति को प्रतिस्थापित नहीं करेगा, लेकिन अब वहाँ कुछ देखने को मिल रहा है। यदि आपका डेटाबेस फ्रीज हो जाता है और आप नहीं जानते कि कहां से शुरू करें, तो PERFORMANCE_SCHEMA से शुरू करें। वहां हमेशा बहुत सारी उपयोगी जानकारी होती है, खासकर जब से ओरेकल अभी भी पहले से ही नहीं खड़ा है और 5.6.X में हमें दो ड्रॉप डेड परफॉर्मेंस का वादा किया गया था, जो सभी टेबल और इंडेक्स के उपयोग पर आंकड़े दिखाते हैं (मैंने पहले ही जांच कर लिया था कि यह वहां जारी किया गया है और व्यक्तिगत रूप से मेरे लिए है) जानकारी अत्यंत उपयोगी लग रही थी, यह लापता या खोज के लिए, इसके विपरीत, अप्रयुक्त इंडेक्सों को खोजने के लिए अद्भुत है)। खैर, हम आशा और प्रतीक्षा करते हैं।

ZY यदि आप एक विशिष्ट म्यूटेक्स समस्या को हल करने के साथ सामना कर रहे हैं, तो इसे टिप्पणियों में साझा करना न भूलें, क्योंकि फिलहाल किसी भी स्थान पर म्यूटेक्स की पूरी जानकारी नहीं है, मुझे लगता है कि इससे कई लोगों को मदद मिलेगी जिन्होंने PERFORMANCE -SCHEMA का उपयोग किया है