mysql पहली क्वेरी पर धीमा, फिर संबंधित प्रश्नों के लिए तेज़

Question

मैं ऐसी समस्या से जूझ रहा हूं जो केवल तब होता है जब डेटाबेस क्वेरी के लिए समय के लिए निष्क्रिय रहता है। 30 सेकंड के क्रम में पहली क्वेरी बेहद धीमी होगी और फिर संबंधित प्रश्न 0.1 सेकंड की तरह तेज होंगे। मुझे लगता है कि यह कैशिंग से संबंधित है, लेकिन मैं इसका कारण नहीं ढूंढ पाया।

mysql चर बदलना tmp_table_size, max_heap_table_size को बड़े आकार में स्मृति में अस्थायी तालिकाओं को छोड़कर कोई प्रभाव नहीं पड़ा।

मुझे नहीं लगता कि यह क्वेरी से संबंधित है क्योंकि यह अच्छी तरह अनुक्रमित है और पहली धीमी क्वेरी के बाद, एक ही क्वेरी के वेरिएंट धीमी क्वेरी लॉग में दिखाई नहीं देते हैं। मुझे इस कारण का कारण निर्धारित करने में अपमानजनक कैश को रीसेट करने का प्रयास करने में सबसे अधिक दिलचस्पी है, इसलिए मैं इस समस्या का निवारण कर सकता हूं।

Answer 1

innodb डेटा फ़ाइलों के पृष्ठ innodb बफर पूल में कैश हो जाते हैं। यही वह है जो आप उम्मीद करेंगे। फ़ाइलों को पढ़ना धीमा है, यहां तक ​​कि अच्छी हार्ड ड्राइव पर भी, विशेष रूप से यादृच्छिक पढ़ता है जो ज्यादातर डेटाबेस देखता है।

यह हो सकता है कि आपकी पहली क्वेरी किसी प्रकार का टेबल स्कैन कर रही हो जो बफर पूल में बहुत सारे पेज खींचती है, फिर उन्हें एक्सेस करना तेज़ होता है। या कुछ समान है।

यही वह है जो मैं उम्मीद करता हूं।

आदर्श रूप से, सभी तालिकाओं के लिए एक ही इंजन का उपयोग करें (अपवाद: सिस्टम टेबल, अस्थायी तालिकाओं (शायद) और बहुत छोटी टेबल या अल्पकालिक वाले)। यदि आप ऐसा नहीं करते हैं तो उन्हें राम के लिए लड़ना होगा।

मान लें कि आपकी सभी टेबलें innodb हैं, बफर पूल सर्वर के भौतिक RAM के 75% तक का उपयोग करें (मान लीजिए कि आप मशीन पर बहुत से अन्य कार्यों को नहीं चलाते हैं)।

फिर आप अपने डेटाबेस के लगभग 12 जी को राम में फिट करने में सक्षम होंगे, इसलिए एक बार यह "गर्म हो जाने" के बाद, आपके डेटाबेस का "सबसे अधिक उपयोग किया गया" 12 जी रैम में होगा, जहां इसे एक्सेस करना अच्छा और तेज़ है।

mysql के कुछ उपयोगकर्ता थोड़ी देर के लिए किसी अन्य मशीन से कॉपी किए गए प्रश्नों को भेजकर पुनरारंभ करने के बाद उत्पादन सर्वर को "गर्म" करते हैं (ये प्रतिकृति दास होंगे) जब तक कि वे उन्हें अपने उत्पादन पूल में न जोड़ दें। यह कैश ठंडा होने पर देखा गया चरम धीमापन से बचाता है। उदाहरण के लिए, यूट्यूब यह करता है (या कम से कम इसका उपयोग किया जाता है; Google ने उन्हें खरीदा है और वे अब Google-fu का उपयोग कर सकते हैं)

Answer 2

क्या आपके mysql सर्वर पर कुछ और चल रहा है? मेरा विचार यह है कि शायद पहली क्वेरी के बाद, आपकी तालिका अभी भी स्मृति में कैश की गई है। एक बार यह निष्क्रिय होने के बाद, एक और प्रक्रिया इसे डी-कैश किया जा रहा है। हालांकि बस एक अनुमान है।

आपके पास कितनी मेमोरी है और क्या चल रहा है?

Answer 3

टेट्री और समय के बाद क्वेरी चलाने पर लिनक्स कमांड लाइन पर "vmstat 1" के आउटपुट की तुलना करें, बनाम जब आप इसे फिर से चलाते हैं और परिणाम तेजी से प्राप्त करते हैं। विशेष रूप से "द्वि" कॉलम की जांच करें (वह प्रति सेकंड डिस्क से केबी पढ़ा जाता है)।

आपको लगता है कि ऑपरेटिंग सिस्टम तेजी से मामले में डिस्क ब्लॉक को कैश कर रहा है (और इस प्रकार कम "द्वि" आकृति), लेकिन धीमी स्थिति में नहीं (और इसलिए एक बड़ी "द्वि" आकृति)।

आप यह भी पा सकते हैं कि vmstat किसी भी मामले में उच्च/निम्न सीपीयू उपयोग दिखाता है। यदि तेज़ होने पर यह कम होता है, और डिस्क थ्रूपुट भी कम होता है, तो आपका सिस्टम अभी भी एक कैश किए गए क्वेरी को वापस कर सकता है, भले ही आपने संकेत दिया है कि प्रासंगिक कॉन्फ़िगरेशन मान शून्य पर सेट है। शायद show engine innodb status और SHOW VARIABLES के आउटपुट की जांच करें और पुष्टि करें।

innodb_buffer_pool_size भी उच्च सेट किया जा सकता है (यह होना चाहिए ...), जो ओएस उन्हें वापस करने से पहले भी ब्लॉक को कैश करेगा।

आप यह भी पा सकते हैं कि "key_buffer" उच्च सेट है - यह इंडेक्स में कुंजी को कैश करेगा, जो आपके चयन को अंधेरे से तेज कर सकता है।

बहुत उपयोगी जानकारी के लिए mysql performance blog साइट को आजमाएं।

Answer 4

मेरे पास एक एसएसआईएस पैकेज था जो समय समाप्त हो रहा था। क्वेरी एक ही MySQL तालिका से बहुत सरल थी, लेकिन कभी-कभी इसे कई रिकॉर्ड लौटा दिए जाते थे और कभी-कभी निष्पादित करने में कुछ मिनट लगते थे, फिर कुछ ही मिलीसेकंड बाद में अगर मैं इसे फिर से पूछना चाहता था। हम एडीओ कनेक्शन से फंस गए थे, जिसका मतलब था कि यह 30 सेकंड के बाद समाप्त हो जाएगा, इसलिए लगभग आधे डेटाबेस जिन्हें हम लोड करने की कोशिश कर रहे थे, विफल रहे थे।

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

Answer 5

मुझे समस्या थी जब निष्क्रिय अवधि के बाद MySQL 5.6 पहली क्वेरी पर धीमा था। यह एक कनेक्शन समस्या थी, MySQL उदाहरण समस्या नहीं, उदा। यदि आप MYSQL क्वेरी ब्राउज़र निष्पादित करते हैं तो "कुछ_क्यू से चुनें * निष्पादित करें", इसे कुछ घंटों के लिए अकेला छोड़ दें, फिर किसी भी क्वेरी को निष्पादित करें, यह धीमा चलता है, जबकि साथ ही सर्वर पर प्रक्रिया या ब्राउज़र के नए इंस्टेंस को उसी टेबल से चुनेंगे हाथों हाथ।

स्किप-होस्ट-कैश जोड़ना, my.ini फ़ाइल को छोड़ने-नाम-संकल्प को हल करने से इस समस्या को हल किया गया।

मुझे नहीं पता कि वह क्यों है। मैंने यह क्यों कोशिश की: MySQL 5.1 उन विकल्पों के बिना धीरे-धीरे अन्य नेटवर्क से कनेक्शन स्थापित कर रहा था (उदाहरण के लिए सर्वर 192.168.1.100, 192.168.1.101 तेजी से कनेक्ट होता है, 1 9 2.168.2.100 धीमा कनेक्ट करता है), MySQL 5.6 को इस तरह से शुरू करने में ऐसी समस्या नहीं थी हमने शुरुआत में my.ini में इन्हें नहीं जोड़ा।

यूपीडी: वास्तव में आधा मामलों को हल किया गया। Wait_timeout को अधिकतम पूर्णांक पर सेट करना दूसरे आधे को तय करता है। हो सकता है कि अब भी मैं स्किप-होस्ट-कैश, स्किप-नेम-रेज़ोल्यूशन को हटा सकता हूं और यह 100% मामलों में धीमा नहीं होगा