टेबल लेवल लॉक के इंतजार से प्रश्नों को रोकने का तरीका

Question

हमने अपने ग्राहक के डेटाबेस को एक अतिरिक्त सर्वर पर ले जाने के बाद एक समस्या का सामना किया है। साइट के प्रदर्शन पर इसका सकारात्मक प्रभाव होना चाहिए था, लेकिन MyISAM में टेबल लॉकिंग की समस्या है। (मैंने MyISAM के बजाय InnoDB का उपयोग करने के बारे में सुना है, लेकिन हम निकट भविष्य में इंजन को बदल नहीं सकते हैं)।
हम इसे अपडेट-क्वेरी के लिए प्रस्तुत कर सकते हैं, जो कि जब मॉडरेटर मॉडरेटर द्वारा लेख पर टिप्पणी सक्रिय करता है, तब किया जाता है। यह प्रक्रिया है:

• अद्यतन-क्वेरी संसाधित है SET status = 1 WHERE id = 5(सूचकांक सेट है)
• पृष्ठ की कैश्ड फ़ाइलें हटा दी जाती हैं

इस बिंदु पर पूरा पृष्ठ धीमा हो जाता है। डेटाबेस स्वयं मिनटों के लिए व्यस्त है। मैंने कुछ समय के लिए प्रक्रिया सूची प्राप्त की और विभिन्न चयन-प्रश्नों की लगभग 60 प्रविष्टियाँ देखीं, जो सभी टेबल लेवल लॉक की प्रतीक्षा कर रहे थे ।

1. मुझे समझ नहीं आ रहा है कि टेबल का यह अपडेट टेबल लेवल लॉक के लिए प्रतीक्षा करने के article_commentsलिए टेबल के articleलिए चयन-कथनों को क्यों प्रभावित कर सकता है । प्रक्रिया सूची में लगभग सभी प्रतीक्षा प्रश्न इस तालिका से थे। मैंने इस तथ्य के बारे में पढ़ा है कि अपडेट / आवेषण का चयन करने के लिए पसंद किया जाता है और यह इस तरह की समस्याओं का कारण बन सकता है, लेकिन टिप्पणी सक्रिय होने पर लेख-तालिका स्वयं अपडेट नहीं होती है, इसलिए चयनों का इंतजार नहीं करना चाहिए। क्या मुझे यह समझ में आया?
2. क्या इस व्यवहार को रोकने या कम से कम एक बेहतर संतुलन पाने के लिए InnoDB को बदलने के अलावा भी कुछ है? मैं इस तथ्य से बहुत चिढ़ हूँ कि नए सर्वर पर डेटाबेस ले जाने से पहले यह समस्या सामने नहीं आई। मुझे लगता है कि कुछ गलत धारणा है, लेकिन मुझे नहीं पता कि कैसे पहचानें।

Comments

सामान्य लॉगिंग सक्षम करें और इन तालिकाओं के बीच JOIN कथनों के लिए देखें। जब आप चयन करते हैं तो यह एक अंतर्निहित READ LOCK बनाता है। चूंकि MYISAM ROW LEVEL लॉकिंग का समर्थन नहीं करता है, इसलिए यह टेबल स्तर पर लॉक होता है। शायद यह मामला है कि यह लॉकिंग पुराने सर्वर पर हो रहा था लेकिन कोई नहीं देख रहा था? मेजबानों के बीच लाइन के लिए अपने my.cnf लाइन की तुलना करें और विशेष रूप से सुनिश्चित करें कि आपका key_buffer ठीक से ट्यून किया गया है।

— बेतरतीब

हमें पुराने सर्वर पर कई अन्य प्रदर्शन समस्याएं थीं, और अक्सर प्रक्रिया सूची देखी। मुख्य रूप से कई नींद की प्रक्रियाएं थीं, लेकिन हमने कभी भी प्रतीक्षा करने वालों पर ध्यान नहीं दिया (मैंने इस जानकारी को इस नए सर्वर पर पहली बार देखा)। मेरे साथी ने पुराने my.cnf की नकल की और नए मौजूदा हार्डवेयर में मूल्यों को समायोजित किया, लेकिन कई प्रविष्टियां नहीं थीं। मैंने "SHOW VARIABLES" के आउटपुट की तुलना भी की, लेकिन वास्तव में नहीं पता था कि क्या देखना है। हम कल कीबफ़र का पुनः परीक्षण करेंगे, आपकी टिप्पणी के लिए धन्यवाद।

— 32bitfloat

हमें हाल ही में इसी तरह की समस्या हुई थी। शुरू में हमारे key_buffer_sizeलिए सेट किया गया था 1GB। उस 10GBसमस्या को कम करना।

— हलुक

@ रिक जेम्स, धन्यवाद। आपने आज मुझे बहुत परेशानी से बचाया। क्या आपके पास अमेज़न या कहीं और इच्छा सूची है? :) मैं क्वेरी_cache_limit को 1024 में सेट करता हूं। अब कोई लॉक समस्या नहीं है। मैंने इसे mysql क्लाइंट से सबसे पहले वेरिएबल्स में किया। वैश्विक क्वेरी_चेचे_लिमिट = 1024 सेट करें; अब मैं इसे my.cnf पर लिखूंगा। इस समाधान ने मुझे बिना किसी तनाव के निर्दोष प्रवास की योजना बनाने का समय मिल गया, इसलिए धन्यवाद।

Answer 1

MyISAM स्टोरेज इंजन किसी भी DML (INSERTs, UPDATEs, DELETEs) के लिए पूर्ण टेबल लॉक करने के लिए उग्र रूप से कुख्यात है। InnoDB निश्चित रूप से लंबी अवधि में उस मुद्दे को हल करेगा।

मैंने MyISAM बनाम InnoDB का उपयोग करने के पेशेवरों और विपक्षों के बारे में लिखा

• InnoDB बनाम MyISAM कई सूचकांक (जुलाई 05, 2012) के साथ
• कौन सा तेज़ है, InnoDB या MyISAM? (03 मई, 2012)
• MyISAM से InnoDB में परिवर्तित करने के साथ सभी पर कोई भी गोच? (09 जनवरी, 2012)
• क्या मुझे इन तालिकाओं को ऑप्टिमाइज़ करने के लिए MyISAM के अलावा किसी अन्य स्टोरेज इंजन का उपयोग करना चाहिए या क्या मुझे बेहतर डिस्क मिलनी चाहिए? (अक्टूबर ० (, २०११)
• टेबल लेवल लॉकिंग के लाभ (14 सितंबर, 2011)
• InnoDB और MyISAM के बीच मुख्य अंतर क्या हैं? (अप्रैल 14, 2011)

आपके वर्तमान प्रश्न के संबंध में, यहां एक संभावित परिदृश्य है:

• articleऔर article_commentsदोनों MyISAM टेबल हैं
• article_commentsstatusएक स्तंभ के साथ एक या एक से अधिक अनुक्रमित है
• के लिए इंडेक्स पेज अपडेट article_commentsMyISAM की बफर में कैश्ड हैं ( key_buffer_size द्वारा आकार ), जिससे पुराने इंडेक्स पेज MyISAM की बफर से बाहर हो जाते हैं
• आपके पास सेलेक्टेड क्वेश्चन हैं जो बीच article- बीच में जॉइन करते हैं औरarticle_comments

मेरे सुझाए गए परिदृश्य में, किसी भी डीएमएल (इस मामले में ) से मुक्त articleहोने के लिए प्रतीक्षा करने के कारण तालिका के विरुद्ध चयनों को लिखने की अनुमति देने से रोका जा सकता है।article_commentsUPDATE

Comments

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

— 32bitfloat

अंतिम समाधान: टेबल को InnoDB में बदलें। मेरी पोस्ट dba.stackexchange.com/a/9422/877 पर देखें कि कैसे सब कुछ MyISAM को InnoDB में परिवर्तित किया जाए

— RolandoMySQLDBA

Answer 2

इस बिंदु पर पूरा पृष्ठ धीमा हो जाता है। डेटाबेस स्वयं मिनटों के लिए व्यस्त है।

आपके जैसी खुशबू एक बड़ी Query_cache है?

mysql> SHOW VARIABLES LIKE 'query_cache%';
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 16777216 | -- Not over 50M
| query_cache_type             | DEMAND   | -- Only if using SQL_CACHE
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

बहुत सारे लेखन के साथ उत्पादन प्रणालियों के लिए, आप क्वेरी_cache को बंद कर सकते हैं।

दिए गए तालिका के लिए query_cache में सभी प्रविष्टियों को तब शुद्ध किया जाता है जब कोई भी तालिका उस तालिका में होती है। क्यूसी जितना बड़ा है, यह कार्य उतना ही धीमा है।

MyISAM "तालिका स्तर" ताले का उपयोग करता है। एक ही समय (एक ही टेबल पर) पढ़ता और लिखता है। क्रूड, लेकिन प्रभावी।

Comments

सही है। हमारे पास लगभग 64M कैश है। इस जानकारी के लिए धन्यवाद, जो मेरे लिए नया था, हालांकि, पुराने सर्वर पर हमारे पास वही मूल्य था जहां हमने टेबललॉक पर ध्यान नहीं दिया था। हम पहले से ही InnoDB पर जाना शुरू कर चुके हैं लेकिन यह तथ्य एक रहस्य के रूप में बना हुआ है ...

— 32bitfloat