MySQL को एक से अधिक कोर का उपयोग करना संभव है?

Question

मुझे कुछ समर्पित MySQL सर्वरों के साथ प्रस्तुत किया गया है जो कभी भी एक से अधिक कोर का उपयोग नहीं करते हैं। मैं MySQL के लिए DBA से अधिक डेवलपर हूं इसलिए कुछ मदद चाहिए

सेट अप

OLAP / DataWarehouse (DW) प्रकार के लोड के साथ सर्वर काफी भारी हैं:

• प्राथमिक: 96GB RAM, 8 कोर + सिंगल RAID 10 सरणी
• टेस्ट: 4 कोर के साथ 32 जीबी रैम
• सबसे बड़ी DB 540 GB है, कुल लगभग 1.1TB है और ज्यादातर InnoDB टेबल है
• सोलारिस 10 इंटेल -64
• MySQL 5.5.x

नोट: सबसे बड़ी DB OLTP DR सर्वर से एक प्रतिकृति है और DW को इससे लोड किया गया है। यह पूर्ण डीडब्ल्यू नहीं है: पिछले 6 महीने से 6 सप्ताह तक तो यह ओएलटीपी डीबी से छोटा है।

एक परीक्षण सर्वर पर अवलोकन

• 3 अलग कनेक्शन
• प्रत्येक में एक समवर्ती (और अलग) है ALTER TABLE...DROP KEY...ADD INDEX
• 3 तालिकाओं में 2.5, 3.8 और 4.5 मिलियन पंक्तियाँ हैं
• सीपीयू का उपयोग 25% तक हो जाता है (एक कोर अधिकतम हो जाता है) और इससे अधिक नहीं
• 3 ALTERs को 12-25 मिनट लगते हैं (सबसे छोटा 4.5 पर एक एकल)

प्रशन

1. एक से अधिक कोर का उपयोग करने की अनुमति देने के लिए किस सेटिंग या पैच की आवश्यकता होती है?
   यही कारण है, MySQL उपलब्ध सभी कोर का उपयोग क्यों नहीं करता है? (अन्य RDBMS की तरह)
2. क्या यह प्रतिकृति का परिणाम है?

अन्य नोट

• मैं RDBMS "थ्रेड" और OS "थ्रेड" के बीच का अंतर समझता हूं
• मैं समानता के किसी भी रूप के बारे में नहीं पूछ रहा हूं
• InnoDB और थ्रेड्स के लिए कुछ सिस्टम चर उप-इष्टतम हैं
  (त्वरित जीत की तलाश में)
• लघु अवधि, मैं डिस्क लेआउट को बदलने में असमर्थ हूं
• जरूरत पड़ने पर ओएस को घुमाया जा सकता है
• छोटी मेज पर एक एकल तालिका में 4.5 मिनट लगते हैं (चौंकाने वाला IMO)

संपादित करें 1

• innodb_thread_concurrency दोनों पर 8 पर सेट है। हां, यह गलत है लेकिन MySQL को कई कोर का उपयोग नहीं करेगा
• innodb_buffer_pool_size प्राथमिक पर 80GB है, एक परीक्षण पर 10GB (एक और उदाहरण बंद है)। यह अभी के लिए ठीक है।
• innodb_file_per_table = ON

संपादित करें 2

• innodb_flush_log_at_trx_commit = 2
• innodb_use_sys_malloc = ON
• innodb_flush_method O_DIRECT होना चाहिए (लेकिन SHOW VARIABLES यह नहीं दिखाता है)
• innodb_doublewrite = OFF
• फ़ाइल सिस्टम = ZFS (और मेरे sysadmin ने यह पाया: http://blogs.oracle.com/realneel/entry/mysql_innodb_zfs_best_practices )

परीक्षा करना

• innodb_flush_method O_DIRECT के रूप में नहीं दिखाया जा रहा है जब यह होना चाहिए
• RolandoMySQLDBA की सेटिंग्स का पालन करेंगे

मुझे पता है कि क्या मैंने कुछ महत्वपूर्ण याद किया है

चियर्स

अपडेट करें

RolandoMySQLDBA के उत्तर में innodb_flush_method + 3 x थ्रेड सेटिंग्स बदली गईं
:> परीक्षणों के लिए उपयोग किए गए 1 कोर = सकारात्मक परिणाम

Comments

@ डटेस्ट: innodb_file_per_table = ON SHOW इंजन INNODB STATUS \ G केवल कमांड लाइन है?

— gbb

@Dest: मुझे SQLyog में कोई आउटपुट नहीं मिला और इसे कमांड लाइन से किसी को चलाने के लिए कहना पड़ेगा

— gbn

webyog.com/forums/index.php?showtopic=1290 के बिना काम करना चाहिए \G। इसके अलावा, मुझे लगता SHOW INNODB STATUSहै कि SHOW ENGINE INNODB STATUS5.5 के पक्ष में पदावनत किया गया है (मुझे कमांड-लाइन में पूर्व को चलाने में त्रुटि मिलती है।

— डेरेक डाउनी

जबकि अन्य सभी उत्तर अच्छे हैं, चूंकि आप एक डेवलपर हैं, मैं आपको Shard Query code.google.com/p/shard-query पर एक नज़र डालने की सलाह दूंगा, यह आपकी मदद कर सकता है, विशेष रूप से डेटावेयरहाउस वातावरण में।

— जोनाथन

धन्यवाद, यह एक ऐसा विकल्प है जिसके बारे में हमने सोचा है। मैं = मी भी डीबीए की भूमिका में है।

— gbn

Answer 1

मैंने वास्तव में मई 2011 में Percona Live NYC सम्मेलन में एक MySQL एक्सपर्ट के साथ innodb_thread_concurrency पर चर्चा की ।

मैंने कुछ आश्चर्यचकित किया: दस्तावेज़ीकरण के बावजूद, इसे innodb_thread_concurrency0 (अनंत संगामिति) पर छोड़ना सबसे अच्छा है । इस तरह, InnoDB innodb_concurrency_ticketsकिसी दिए गए MySQL इंस्टा सेटअप के लिए खुलने की सबसे अच्छी संख्या तय करता है ।

एक बार जब आप innodb_thread_concurrency0 पर सेट हो जाते हैं, तो आप 64 के अधिकतम मूल्य पर ( innodb_read_io_threadsऔर innodb_write_io_threadsMySQL 5.1.38 के बाद से) सेट कर सकते हैं। यह अधिक कोर संलग्न करना चाहिए।

Comments

की कोशिश करेंगे। मैं innodb_thread_concurrency को 0 पर सेट करने जा रहा था, वैसे भी मेरे द्वारा पढ़े गए सामान के आधार पर

— gbn

+1 के लिए innodb_thread_concurrency = 0

— randomx

@ जीबी - डीबीएएसई में # 1 आदमी से आ रहा है, एक धन्यवाद आप एक आत्मविश्वास बूस्टर हैं और बहुत सराहना की। धन्यवाद और आपका स्वागत है !!!

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

सेट वैश्विक innodb_read_io_threads = 8 त्रुटि कोड: 1238. परिवर्तनीय 'innodb_read_io_threads' एक पढ़ा जाने वाला केवल चर है

— wgq3g23g

@ wgq3g23g यदि आप RDS कर रहे हैं, तो उसे DB पैरामीटर समूह में बदलें और उदाहरण को रिबूट करें। यदि आप EC2 या नंगे धातु कर रहे हैं, तो myfqld को my.cnfफिर से शुरू करने के लिए उस विकल्प को जोड़ें । कृप्या।

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

Answer 2

MySQL स्वचालित रूप से कई कोर का उपयोग करेगा, इसलिए या तो आपके 25% का भार संयोग ^{1 है} या सोलारिस पर एक संभावित गलत धारणा है। मैं यह जानने का नाटक नहीं करूंगा कि सोलारिस को कैसे ट्यून किया जाता है, लेकिन यहां एक लेख है जो कुछ सोलारिस-विशिष्ट ट्यूनिंग जानकारी पर जाता है ।

InnoDB ट्यूनिंग पृष्ठों को MySQL 5.5 में ओवरहाल दिया गया है, इसलिए वहां कुछ अच्छी जानकारी भी है। से InnoDB डिस्क आईओ सुझावों :

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

जाँच करने के लिए कुछ अन्य बातें:

• Innodb_flush_method को O_DIRECT में बदलना परीक्षण के लायक है। यदि यह मदद करता है, तो आपको forcedirectioविकल्प के साथ फाइल सिस्टम को माउंट करने की आवश्यकता हो सकती है

• 1 से 0 तक innodb_flush_log_at_trx_commit बदलें (यदि आप mysql क्रैश पर अंतिम दूसरा खोने का बुरा नहीं मानते हैं) या 2 (यदि आप OS क्रैश पर अंतिम दूसरा खोने का बुरा नहीं मानते हैं)।

• Innodb_use_sys_malloc का मान जांचें । इस लेख में चर पर अधिक जानकारी है ।

  उस समय, मल्टी-कोर सीपीयू के लिए ट्यून किए गए मेमोरी एलोकेटर लाइब्रेरी नहीं थे। इसलिए, InnoDB ने मेम सबसिस्टम में अपने स्वयं के मेमोरी एलोकेटर को लागू किया। यह आवंटन एक म्यूटेक्स द्वारा संरक्षित है, जो एक अड़चन बन सकता है।

  लेकिन अनुभाग को समाप्त करने के बारे में कुछ कैविएट हैं कि चर को चालू करने का क्या मतलब है (यह 5.5 में डिफ़ॉल्ट रूप से चालू है)।

  ध्यान दें कि जब InnoDB मेमोरी आबंटक अक्षम होता है, तो InnoDB पैरामीटर innodb_additional_mem_pool_size के मान को अनदेखा करेगा।

• यह संभव है कि प्रतिकृति समस्या का कारण बन रही है। मुझे लगता है कि आप समानता में रुचि नहीं रखते हैं, लेकिन इस कार्यक्षेत्र के विवरण से :

  वर्तमान में, मल्टी-कोर मशीनों पर प्रतिकृति अच्छी तरह से पैमाने पर नहीं होती है। एकल दास धागा प्रतिकृति घटनाओं को एक-एक करके निष्पादित करता है और अलग-अलग मास्टर सर्वर के सीपीयू द्वारा प्रदान किए जाने वाले समवर्ती कई ग्राहक कनेक्शनों द्वारा उत्पादित लोड का सामना नहीं कर सकता है।

अंततः, इनोवा डीबीटवेयर के लिए सबसे अच्छा इंजन नहीं हो सकता है, क्योंकि डिस्क आधारित संचालन होता है। आप फेरबदल datawarehouse तालिका (रों) होने के लिए विचार कर सकते हैं MyISAM संपीडित ।

¹ _{संयोग से, मेरा मतलब है कि एक अड़चन है जो आपके भार को 25% से ऊपर बढ़ने से रोकती है, लेकिन जरूरी नहीं कि एक सिंगल-कोर मुद्दा है।}

Comments

धन्यवाद। सेटिंग अनुभाग को प्रश्न में जोड़ा गया। समस्या एकल कोर का उपयोग करते हुए कई गहन प्रश्न हैं: स्मृति या थ्रेड सेटिंग्स अभी तक नहीं। अधिक धागे अभी भी उसी कोर पर चलते हैं

— gbn

@ अपडेट के लिए धन्यवाद, अभी भी देख रहे हैं। मैं सोच रहा था कि यह एक 'संयोग' था। मुझे आश्चर्य हो रहा है कि क्या यह सोलारिस-ओनली इश्यू ( डेवलपर्स.सून. com/solaris/articles/mysql_perf_tune.html ) है, लेकिन उस सिस्टम के बारे में ज्यादा जानकारी नहीं है।

— डेरेक डाउनी

@ डाइट: मैं उस लेख को सोलारिस एडमिन के ऊपर रखूंगा। इसमें कुछ अच्छी चीजें हैं

— gbn

अब, स्लेव पर प्रतिकृति (वैकल्पिक रूप से) बहु-थ्रेडेड है। इस उत्तर के लिखे जाने के बाद से InnoDB में सुधार हुआ है। मैं MyISAM का उपयोग करने की सलाह नहीं दूंगा, खासकर अगर संकुचित नहीं।

— रिक जेम्स

Answer 3

एक एकल कनेक्शन केवल एक कोर का उपयोग करेगा। (ठीक है, InnoDB अन्य धागे का उपयोग करता है, इसलिए कोर, कुछ I / O प्रसंस्करण के लिए, लेकिन यह महत्वपूर्ण नहीं है)

आपके पास 3 अलर्ट थे, इसलिए आप 3 से अधिक कोर के मूल्य का उपयोग नहीं कर रहे थे।

काश, विभाजन भी कई कोर का उपयोग नहीं करता।

कुछ समय पहले, 4-8 कोर के बाद कई कनेक्शन अधिकतम हो जाएंगे। पर्कोना का Xtradb (मारियाडीबी में शामिल) कई कोर का बेहतर उपयोग करता है, लेकिन फिर भी प्रति धागे केवल एक ही है। वे लगभग 32 कोर पर अधिकतम करते हैं।

Comments

(अपडेट २०१५ में :) ५.es अधिकतम के साथ कई कनेक्शन ४es कोर पर। 5.7 बेहतर होने का वादा। (इसलिए ओरेकल बेंचमार्क कहते हैं।) लेकिन अभी भी एक कनेक्शन के लिए कई कोर का उपयोग नहीं किया गया है।

— रिक जेम्स

अद्यतन (ओरेकल के ओपनवर्ल्ड में जाने के बाद): नया संस्करण 8.x में कोई समानता नहीं होगी।

— रिक जेम्स

Answer 4

IMHO और वर्णित उपयोग-मामले में, आप कभी भी एक से अधिक कोर का उपयोग नहीं करेंगे। कारण यह है कि आपका कार्यभार IO बाउंड है, CPU बाध्य नहीं है। जैसा कि आपके 3 कनेक्शन एक नया सूचकांक बना रहे हैं, उनमें से प्रत्येक को डिस्क से पूरी तालिका को पढ़ने की आवश्यकता है: यह वह है जो समय ले रहा है, सूचकांक की गणना नहीं कर रहा है।

Answer 5

विचार करें कि आपकी अड़चन आपके फाइलसिस्टम का IO प्रदर्शन हो सकती है।

@RolandoMySQLDBA द्वारा सुझाई गई सेटिंग्स के अलावा , मैंने अपने mysql डेटा डायरेक्टरी ( मेरे मामले में, माउंटेड के साथ ) के विभाजन के लिए noatimeमाउंट सेटिंग्स भी सेट की हैं ।/etc/fstab/data01/mysql/dev/sdb1/data01

डिफ़ॉल्ट रूप से हर कोई पढ़ने या लिखने के लिए एक्सेस समय रिकॉर्ड करता है, जो विशेष रूप से डेटाबेस जैसे उच्च IO अनुप्रयोगों के लिए IO के प्रदर्शन को नकारात्मक रूप से प्रभावित करता है। इसका मतलब यह है कि एक फ़ाइल से डेटा पढ़ना भी डिस्क पर एक लिखने को ट्रिगर करता है ... वाट!

इसे अक्षम करने के लिए, निम्न माउंट बिंदु के लिए noatimeमाउंट विकल्प /etc/fstabको निम्नानुसार जोड़ें (मेरे मामले में उदाहरण):

/dev/sdb1  /data01  ext4  defaults,noatime  0  2

फिर विभाजन का वर्णन करें:

mount -o,remount /data01

यह उस विभाजन का उपयोग करके अनुप्रयोगों के पढ़ने / लिखने के प्रदर्शन को बढ़ावा देना चाहिए। लेकिन ... कुछ भी नहीं है अपने सभी डेटा स्मृति में धड़कता है।