जब क्वेरी कैश अक्षम हो जाता है तो MySQL थ्रेड्स अक्सर "मुफ्त आइटम" स्थिति क्यों दिखाते हैं?

Question

जब मैं दौड़ता हूं SHOW PROCESSLIST, तो अक्सर "फ्रीजिंग आइटम" राज्य में बड़ी संख्या में INSERT / UPDATE धागे होते हैं।

MySQL मैनुअल से पता चलता है कि इस राज्य में एक थ्रेड के कम से कम हिस्से में क्वेरी कैश शामिल है - संभवतः यह बदले हुए डेटा के कारण कैश किए गए प्रश्नों को अमान्य कर देगा।

हालाँकि, मेरा query_cache_size0 पर सेट है जो क्वेरी कैश को पूरी तरह से अक्षम कर देना चाहिए।

इस राज्य में इतने सारे धागे होने के और क्या कारण होंगे?

प्रासंगिक तालिकाओं में InnoDB भंडारण इंजन का उपयोग किया जाता है।

Answer 1

Innodb_thread_concurrency का मान जांचें।

मेरी प्रणाली के लिए MySql प्रलेखन में दिशानिर्देशों के अनुसार 8 से 32 तक मूल्य में वृद्धि, "मुक्त आइटम" स्थिति की समवर्ती रिपोर्ट करने वाले थ्रेड्स की संख्या में एक घटिया कमी आई। इसके अलावा, परिमाण के क्रम द्वारा गिराया गया औसत औसत क्वेरी समय।

हालांकि इसने समग्र सर्वर प्रदर्शन में एक बड़ा अंतर डाला, यह "निशुल्क आइटम" चांदी की गोली नहीं थी। मेरा हार्डवेयर इकोसिस्टम मुझे इस बात की परिकल्पना की ओर ले जाता है कि यह राज्य ज्यादातर "धीमी" डिस्क (2x10k डिस्क छापे 1) के साथ सिस्टम पर देखा जाता है, और तेजी से भंडारण (12x15k डिस्क आरएस 10) के साथ सिस्टम पर कम प्रचलित है। तो, डिस्क प्रदर्शन का एक चेक वारंट भी हो सकता है।

शुभ लाभ!

इसके अलावा:

यह ध्यान देने योग्य है कि innodb_thread_concurrency का डिफ़ॉल्ट मान 5.0 पॉइंट रिलीज़ का उपयोग करने के आधार पर मौलिक रूप से भिन्न है।

डिफ़ॉल्ट मान कई बार बदल गया है: MySQL 5.0.8 से पहले 8, 5.0.18 के माध्यम से 5.0.8 से 20 (अनंत), 5.0.19 से 5.0 (0) (अनंत) और 5.0.21 से 8 (परिमित)। पर। - स्रोत

इसका मतलब यह है कि 5.0.20 से 5.0.21 तक एक सहज रूप से उन्नत अपग्रेड ने डिफ़ॉल्ट को 8 से अनंत में बदल दिया, और इसके साथ प्रदर्शन में बदलाव लाया।

Comments

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

— Navigatron

Answer 2

नि: शुल्क आइटम एक क्वेरी निष्पादन चरण है जहां अस्थायी संरचनाएं, बफ़र्स इत्यादि का निपटान किया जाता है। इस चरण में कुछ क्वेरी कैश काम किया जाता है, लेकिन यह केवल एक चीज नहीं है जो वहां होता है। मैं यह दिखाने के लिए शो प्रोफाइल का उपयोग करने का सुझाव दूंगा कि यह चरण अन्य चरणों के सापेक्ष कितना समय ले रहा है, और यदि समय लगता है तो चिंता का विषय है, गरीब आदमी के प्रोफाइलर और ऑप्रोफाइल जैसे उपकरणों के साथ समस्या निवारण।

Comments

'मुक्त करने वाली वस्तुओं' में शून्य करने के लिए धन्यवाद। क्या इसका कोई विशिष्ट दस्तावेज है, या यह मेरे लिए सिर्फ एक Google अभ्यास है?

— RolandoMySQLDBA

या स्रोत कोड बहिष्कार ब्राउज़ करें! :)

— डेरेक डाउनी

Answer 3

इस मुद्दे के बारे में एक बग रिपोर्ट "नि: शुल्क आइटम" और क्वेरी कैश से संबंधित थी । हालाँकि बग बंद है, लेकिन innodb_thread_concurrency का कोई उल्लेख नहीं किया गया था ।

मई के अंत में, मैंने रोनाल्ड ब्रैडफोर्ड के साथ पेरकोना लाइव एनवाईसी में बात की। मैंने उसे एक ऐसी स्थिति के बारे में बताया, जहाँ मैंने innodb_thread_concurrency पर tweeked किया क्योंकि MySQL 5.5 के मल्टीपल InnoDB बफर पूल ने थ्रेड लॉकिंग के एक टन का उत्पादन किया था और मुझे संदेह था कि कैश्ड डेटा की मुझे सबसे अधिक संभावना है कि कई बफर पूलों में फैल गया था।

उन्होंने स्पष्ट रूप से मुझसे कहा कि मुझे innodb_thread_concurrency के खिलाफ कभी भी मूल्य निर्धारित नहीं करना चाहिए। इसे हमेशा डिफ़ॉल्ट मान होने दें, जो अब शून्य (0) है। ऐसा करके, आप InnoDB संग्रहण को यह तय करने देते हैं कि कितने innodb_concurrency_ticket अपने दम पर उत्पन्न होते हैं। यह वही है जो अनंत संगामिति करता है।

जब हम innodb_thread_concurrency पर सीमाएं लगाते हैं, तो 'मुक्त आइटम' सबसे अधिक बार होता है। वह हमेशा शून्य (0) होना चाहिए। मैं जोखिम उठाता हूं और innodb_concurrency_ticket बढ़ाता हूं और देखता हूं कि यह मदद करता है या नहीं।

Answer 4

हमें बिल्कुल समान लक्षणों के साथ एक समस्या थी। यह पता चला है कि InnoDB लॉग फ़ाइलों वाली डिस्क भर गई है। जांच करने लायक।

Comments

आपको बहुत बड़ी लॉग फ़ाइलों की आवश्यकता है। वास्तव में, सबसे बड़ी लॉग फाइलें innodb_log_files_in_group डिफ़ॉल्ट (जो 2 है) के साथ 2047M है। आपको mysql, rm -f / var / lib / ib_logfile को बंद करना चाहिए [01], innodb_log_file_size = 2047M in /cc/my.cnf में करें और mysql शुरू करें। बेशक, एक बड़ी डिस्क प्राप्त करें !!!

— रोलैंडमाइसीडीडीबीए

Answer 5

एक और संकेत: निर्दोष fsync () हो सकता है। सेटिंग का प्रयास करें

innodb_flush_log_at_trx_commit = 2

में my.cnf

मासूम लॉगफाइल को हर 1-2 सेकंड में डिस्क करने के लिए फ्लश किया जाता है, बजाय हर कमिट के। डेटा अखंडता के लिए थोड़ा जुर्माना, गति में महान लाभ।