भारी mysql उपयोग CPU या मेमोरी

Question

मैं एक अमेज़न S3 उदाहरण है और परियोजना हम सर्वर पर है सम्मिलित करता है और अद्यतन और कुछ जटिल का चयन करता है

हम देख रहे हैं कि MySQL अक्सर एक समय लग जाएगा का एक बहुत कुछ करता है बहुत सी सीपीयू।

मैं यह स्थापित करने की कोशिश कर रहा हूं कि उपरोक्त सेटअप की उच्च मेमोरी या उच्चतर सीपीयू बेहतर है या नहीं।

उच्च सीपीयू अतिरिक्त बड़े उदाहरण

7 स्मृति के जीबी 20 EC2 कंप्यूट इकाइयों (8 :

नीचे cat /proc/meminfo

MemTotal:  7347752 kB 
MemFree:   94408 kB 
Buffers:   71932 kB 
Cached:  2202544 kB 
SwapCached:   0 kB 
Active:  6483248 kB 
Inactive:  415888 kB 
SwapTotal:   0 kB 
SwapFree:   0 kB 
Dirty:   168264 kB 
Writeback:   0 kB 
AnonPages:  4617848 kB 
Mapped:   21212 kB 
Slab:   129444 kB 
SReclaimable: 86076 kB 
SUnreclaim:  43368 kB 
PageTables:  54104 kB 
NFS_Unstable:  0 kB 
Bounce:    0 kB 
CommitLimit: 3673876 kB 
Committed_AS: 5384852 kB 
VmallocTotal: 34359738367 kB 
VmallocUsed:  180 kB 
VmallocChunk: 34359738187 kB 

वर्तमान सेटअप का उत्पादन है 2.5 ईसी 2 गणना इकाइयों के साथ वर्चुअल कोर) 16 9 0 उदाहरण के जीबी भंडारण 64-बिट मंच आई/ओ प्रदर्शन: उच्च एपीआई नाम: c1.xlarge

संभव सेटअप:

उच्च मेमोरी डबल अतिरिक्त बड़े उदाहरण

34.2 जीबी मेमोरी 13 ईसी 2 कंप्यूट यूनिट्स (3.25 ईसी 2 कंप्यूट इकाइयों के साथ 4 वर्चुअल कोर) 850 जीबी इंस्टेंस स्टोरेज 64-बिट प्लेटफ़ॉर्म I/O प्रदर्शन: उच्च एपीआई नाम: एम 2.2xlarge

Answer 1

मैं 32 जीबी मेमोरी और शायद RAID में अधिक हार्डडिस्क के लिए जाऊंगा। सीपीयू बहुत मदद नहीं करेगा - आपके पास सीपीयू शक्ति है। आपको mysql को सही तरीके से कॉन्फ़िगर करने की भी आवश्यकता है।

• ओएस कैश और टेम्प टेबल के लिए 1-2 जीबी छोड़ दें।
• बढ़ाएँ tmp_table_size
• निकालें स्वैप
• अनुकूलन query_cache_size (यह बहुत बड़ी नहीं बनाते हैं - इसके बारे में mysql दस्तावेज़ देखें)
• समय-समय पर फ्लश क्वेरी के कैश चलाते हैं। यदि आपकी क्वेरी कैश < 512 एमबी है - इसे हर 5 मिनट में चलाएं। यह कैश साफ़ नहीं करता है, यह इसे अनुकूलित करता है (डीफ्रैगमेंट)। यह mysql डॉक्स से है:

Defragment बेहतर करने के लिए क्वेरी कैश अपनी स्मृति का उपयोग करें। फ्लश QUERY CACHE फ्लैश टैबलेट या रीसेट QUERY CACHE के विपरीत कैश से किसी भी प्रश्न को नहीं हटाता है।

हालांकि मैंने देखा कि दूसरे समाधान में आधा डिस्क स्थान है: 850 जीबी, जो हार्ड डिस्क की संख्या कम हो सकती है। यह आमतौर पर एक बुरा विचार है। डेटाबेस में सबसे बड़ी समस्या हार्ड डिस्क है। यदि आप RAID5 का उपयोग करते हैं - सुनिश्चित करें कि आप कम हार्ड डिस्क का उपयोग नहीं करते हैं। यदि आप छापे का उपयोग नहीं करते हैं - तो मैं RAID 0 का सुझाव दूंगा।

Answer 2

यह एप्लिकेशन पर निर्भर करता है।

आप mysql प्रश्नों को कैश करने के लिए memcached का उपयोग कर सकते हैं। यह सीपीयू उपयोग को थोड़ा सा आसान करेगा, हालांकि इस विधि के साथ आप क्वेरी को संग्रहीत करने के लिए रैम को बढ़ाना चाहते हैं।

दूसरी ओर यदि यह एप्लिकेशन के प्रकार के आधार पर व्यवहार्य नहीं है तो मैं उच्च CPU की अनुशंसा करता हूं।

Answer 3

कई सीपीयू का उपयोग करने के लिए MySQL के कई कारण नहीं हैं: यह या तो संग्रहीत दिनचर्या (संग्रहित प्रक्रियाओं या संग्रहीत कार्यों) की प्रसंस्करण या सीपीयू खा सकता है।

यदि आप संग्रहीत दिनचर्या के कारण बहुत सारे CPU का उपयोग कर रहे हैं, तो आप इसे गलत कर रहे हैं और आपकी आत्मा को वैसे भी सहेजा नहीं जा सकता है।

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

चुनने का क्या दृष्टिकोण सीपीयू उपयोग के वास्तविक कारण पर निर्भर करता है - क्या यह प्रश्न और सॉर्टिंग है? और वास्तविक प्रश्नों पर। तो किसी भी मामले में आपको पहले बेहतर निगरानी की आवश्यकता होगी।

निगरानी की जानकारी नहीं है, सामान्य सलाह हमेशा होती है: डेटाबेस के लिए अधिक CPU नहीं, अधिक मेमोरी खरीदें।

Answer 4

ईसी 2 की ऑन-डिमांड प्रकृति एक दिन के लिए संभावित सेटअप किराए पर लेने के लिए आसान नहीं है, और कुछ लोड परीक्षण करते हैं? मापन शब्दों से ज़ोर से बोलते हैं।

Answer 5

"हाई-सीपीयू अतिरिक्त बड़े उदाहरण" का उपयोग करें।

अपने मौजूदा सेटअप में, MySQL स्मृति द्वारा सीमित नहीं है:

MemTotal:  7347752 kB  
MemFree:   94408 kB  
Buffers:   71932 kB  
Cached:  **2202544 kB** 

7 जीबी मेमोरी समाप्त

, 2 जीबी अप्रयुक्त और मैं/हे कैश के रूप में ओएस द्वारा इस्तेमाल किया जा रहा है।

इस मामले में, बढ़ती सीपीयू गिनती आपको हिरन के लिए अधिक धमाके देगी।

Answer 6

vmstat और iostat का उपयोग यह पता लगाने के लिए करें कि क्या CPU या I/O बाधा है (यदि I/O - अधिक रैम जोड़ें और डेटा को स्मृति में लोड करें)। खोल से चलाने के लिए और जांच के परिणाम:

vmstat 5 
iostat -dx 5 

• अगर सीपीयू समस्या vmstatus स्तंभ में उच्च मूल्यों दिखाएगा है, और iostat कम डिस्क उपयोग (util)
• दिखाएगा अगर मैं/हे समस्या है तो vmstatus कॉलम में कम मान दिखाएगा और iostat उच्च डिस्क उपयोग (util) दिखाएगा; उच्च से मेरा मतलब है> 50%