MySQL table_cache और Opened_tables

Question

मैंने देखा है कि लोग My_SQL में बहुत छोटा है या नहीं, इसका आकलन करने के लिए Open_tables और Opened_tables की तुलना का उपयोग करते हैं। हालाँकि, मेरा मानना ​​है कि Opened_tables अपटाइम के दौरान संचयी है, इसलिए यह एक वैध तुलना नहीं है। एक ही चेतावनी है कि शायद Opened_tables केवल यादों पर टकरा रहा है - हालांकि तब भी अगर प्रति सेकंड खोले जा रहे टेबल अभी भी छोटे हैं, तो शायद धीरे-धीरे बढ़ने के लिए यह कोई समस्या नहीं है।

यदि Open_tables की Opened_tables से तुलना करना मान्य नहीं है, तो क्या इसके लिए मापा डेटा प्राप्त करने का एक और तरीका है?

यह MySQL 5.0 पर है, लेकिन संस्करण के बीच अंतर भी स्वागत योग्य है।

Comments

मुझे यह सवाल पसंद है क्योंकि यह एक सोचा-समझा सवाल है। यह DB सर्वर हेल्थ को मापने के लिए स्टेटस वेरिएबल्स का पूरा फायदा उठाने के लिए MySQL डेवलपर्स की याद दिलाने के लिए +1 प्राप्त करता है।

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

Answer 1

बड़ी तालिका_ कैश करने का सबसे बड़ा कारण यह है कि LOCK_open mutex गर्म नहीं है। 5.5 से पहले MySQL के पास बहुत सारी विवाद है, जब आप टेबल को खोलने / बंद करने की कोशिश कर रहे हैं, इसलिए आप इसे जितना संभव हो उतना सीमित करना चाहते हैं, अर्थात एक बड़ा टेबल कैश है।

तो आप किसी भी हिट के विशेष अनुपात को याद करने के बारे में परवाह नहीं करते हैं (वास्तव में आपको अनुपात की उपेक्षा करनी चाहिए - यह ब्लॉग पोस्ट क्यों बताता है )। आप जिस चीज की परवाह करते हैं, वह मिस रेट है , क्योंकि जितनी बार यह प्रति सेकंड होता है, उतनी अधिक संभावना है कि आपके पास विवाद होगा (एक धागे को ताला जारी करने के लिए दूसरे धागे की प्रतीक्षा करनी होगी।)

आप मिस रेट को कैसे देखते हैं? आप दिन के सबसे व्यस्त अवधि के दौरान कुछ सेकंड के अलावा Opened_Tables के कुछ नमूने लाते हैं, और यदि प्रत्येक नमूने में वृद्धि होती है, तो यह देखना एक अच्छा विचार है कि क्या आप टेबल_कैश को टक्कर दे सकते हैं।

नोट: मैं विशेष रूप से अपटाइम की तुलना करने की अनुशंसा नहीं करता हूं।

Answer 2

पहले, आइए उन दर्जे के चर पर विचार करें:

ओपन टेबल : टेबल की संख्या जो खुली होती है।

Opened_tables : जो तालिकाएँ खोली गई हैं। यदि Opened_tables बड़ा है, तो आपका table_open_cache मान संभवतः बहुत छोटा है।

आश्चर्यजनक रूप से, आपके प्रश्न का उत्तर प्रश्न के भीतर ही है।

यदि आप मिक्स में एक और स्टेटस वैरिएबल फेंकते हैं, तो दो वैरिएबल केवल अधिक समझ में आएंगे : FLUSH STATUS के बाद ताज़े औसत के लिए Uptime (या Uptime_since_flush स्टेटस )।

आपको Open_tables agsinst (Opened_tables / Uptime) की तुलना करनी चाहिए । यदि Open_tables ऊपर चढ़ता है (Opened_tables / Uptime) , तो अब आपके पास चिंता का कारण है और निम्नलिखित बातों पर ध्यान रखना चाहिए:

• netstat
• iostat
• सर्वर लोड
• कनेक्शन गणना (जैसा कि यह max_connections के पास है )
• निरस्त ग्राहक
• गर्भपात जोड़ता है
• धीमी क्वेरी

UPDATE 2011-08-31 12:18 EDT

कृपया ध्यान दें कि मैंने एक निश्चित अवधि के लिए वृद्धि के Opened_tables पैटर्न को ठीक करने के लिए Uptime के बजाय Uptime_since_flush_status का उपयोग करने का सुझाव भी दिया है ।

उदाहरण के लिए, यदि आप FLUSH STATUS;प्रत्येक सोमवार आधी रात को दौड़ते हैं, तो आप एक OpenTableFactor उत्पन्न कर सकते हैं:

SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM
(SELECT variable_value Uptime FROM information_schema.global_status
WHERE variable_name = 'Uptime_since_flush_status') up,
(SELECT variable_value Open_tables FROM information_schema.global_status
WHERE variable_name = 'Open_tables') opn,
(SELECT IF(variable_value=0,1,variable_value) Opened_tables
FROM information_schema.global_status
WHERE variable_name = 'Opened_tables') opnd;

यह ओपन टेबल फैक्टर उस संख्या पर निर्भर करता है, जो दी गई तालिका की औसत संख्या के खिलाफ किसी भी समय खुली तालिकाओं की संख्या का प्रतिनिधित्व करती है, जो दी गई अवधि से गुजरती हैं। एक के साथ FLUSH HOSTS;हर हफ्ते / दिन / मेजबान, कि औसत सप्ताह / दिन / घंटे के खिलाफ है।

यहाँ मेरे नियोक्ता के ग्राहकों में से एक नमूना है:

mysql> SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM     (SELECT variable_value Uptime FROM information_sc    hema.global_status     WHERE variable_name = 'Uptime_since_flush_status') up,     (SELECT variable_value Open_tables FROM informat    ion_schema.global_status     WHERE variable_name = 'Open_tables') opn,     (SELECT IF(variable_value=0,1,variable_value) Opened_ta    bles     FROM information_schema.global_status     WHERE variable_name = 'Opened_tables') opnd;
+----------+-------------+---------------+-------------------+
| Uptime   | Open_tables | Opened_tables | OpenTableFactor   |
+----------+-------------+---------------+-------------------+
| 14385123 | 16326       | 30429078      | 7717.996519579068 |
+----------+-------------+---------------+-------------------+
1 row in set (0.00 sec)

यह ग्राहक सामान्य रूप से अधिकतम 7745 OpenTableFactor रखता है। यदि OpenTableFactor अचानक गिरता है (भले ही थोड़ा सा), यह कम ट्रैफ़िक पैटर्न, उच्च गर्भपात वाले संकेत, और इसके आगे संकेत कर सकता है। यदि OpenTableFactor कभी नहीं बदलता है (भले ही थोड़ा), यह आपको इन सेटिंग्स को बदलने के अवसर के साथ प्रस्तुत कर सकता है:

• open_files_limit
• innodb_open_files
• table_open_cache

एक बार समायोजित हो जाने के बाद, OpenTableFactor लगातार बदल सकता है या किसी अन्य छत या पठार से टकरा सकता है। इस प्रकार, स्थिति चर के भीतर विभिन्न इकाइयों का उपयोग इस तरह के ट्यूनिंग के लिए महत्वपूर्ण हो जाता है।

UPDATE 2011-08-31 12:42 EDT

OpenTableFactor के लिए मैंने जिस SQL ​​क्वेरी को चलाया, वह MySQL 5.0 और बैक के लिए काम नहीं करती है। यदि आप MySQL प्रशासक या मोनयोग का उपयोग कर रहे हैं , तो आप क्वेरी और मॉनिटर में सूत्र का उपयोग करके एक ग्राफ को अनुकूलित कर सकते हैं। मोनयोग बाद के ऐतिहासिक रेखांकन के लिए SQLLite का उपयोग करके इतिहास एकत्र करता है। यह MySQL के किसी भी संस्करण के लिए किया जा सकता है।

Comments

कुछ अच्छे सुझाव, लेकिन मुझे नहीं लगता कि आप दो इकाइयों की तुलना अलग-अलग इकाइयों से करना चाहते हैं, जितना कि आप किसी संचयी मूल्य की तुलना किसी वर्तमान में करना चाहते हैं। और अगर यह सिर्फ उपाय याद आती है का मुद्दा बना हुआ है।

— सैम ब्राइटमैन

Answer 3

Table_cache प्रलेखन पृष्ठ पर उपयोगकर्ता टिप्पणियों में से एक से :

Opened_tables एक स्टेटस वैरिएबल है जो अतिरिक्त फ़ाइल डिस्क्रिप्टर की संख्या का एक रनिंग टैली रखता है जो टेबल पर उपलब्ध ओपनिंग के लिए कई बार आबंटित किए गए हैं जब table_cache में उपलब्ध फाइल डिस्क्रिप्टर को हटा दिया गया है। ...

मतलब यह है कि जब आप अपने table_cacheमूल्य से अधिक हो जाते हैं तो यह बढ़ जाता है। तो जिस तरह से मैं सामान्य रूप से इसकी जांच करता हूं , उसकी तुलना opened_tablesकरना है uptime, लेकिन यहां कुंजी इसे एक सेट अंतराल (एक बार दस मिनट से अधिक प्रति मिनट, उदाहरण के लिए) लेना है। यदि यह बढ़ रहा है तो यह एक संकेत हो सकता है जिसे आपको बढ़ाने की आवश्यकता है table_cache।

एक युगल का उल्लेख करने के लिए:

• उस प्रलेखन में एक और टिप्पणी: "स्टेटस वैरिएबल 'Opened_tables' को हर बार जब आप एक अस्थायी तालिका बनाते हैं, तो आपको 2 से बढ़ाना होगा।" इसलिए यदि आपके प्रश्नों को कई अस्थायी तालिकाओं की आवश्यकता होती है, तो यह तेजी से वृद्धि का कारण हो सकता है opened_tables। आप निम्नलिखित क्वेरी का उपयोग करके अपना अस्थायी तालिका उपयोग देख सकते हैं:

  SHOW GLOBAL STATUS LIKE '%tmp%';

• तालिका_चेचे को बहुत अधिक न बढ़ाएं

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