มัลติคอร์และประสิทธิภาพ MySQL

ความสำคัญของ RAM เป็นความจริงที่สร้างขึ้นมา แต่มีเนื้อหาน้อยมากเกี่ยวกับความสำคัญของคอร์และมัลติเธรดเมื่อพูดถึงการใช้งาน CPU โดย MySQL ฉันกำลังพูดถึงความแตกต่างของการใช้งาน MySQL บน 4cores vs 6cores เทียบกับ 8cores เป็นต้น

เอนจินการเก็บข้อมูลที่ต่างกันใช้ CPU ต่างกันหรือไม่

เมื่อพูดถึง MySQL จะไม่มีการเปรียบเทียบระหว่างเอ็นจิ้นการจัดเก็บยกเว้นว่ามันแบ่งออกเป็นสองประเภทพื้นฐาน:

• ธุรกรรม ( สอดคล้องกับ ACID )
• ไม่ใช่การทำธุรกรรม

MySQL ใช้ประโยชน์จากเอนจินการจัดเก็บข้อมูลจำนวนมาก

• InnoDB (ค่าเริ่มต้นตั้งแต่ MySQL 5.5)
• MyISAM (ค่าเริ่มต้นก่อน MySQL 5.5)
• ARCHIVE
• หลุมดำ
• CSV
• หน่วยความจำ
• MRG_MYISAM
• สหพันธ์
• NDB อาคา MySQL Cluster

สำหรับเอ็นจิ้นการจัดเก็บที่ระบุไว้มีเพียงรายการเดียวที่มีความสอดคล้องกับกรดคือ InnoDB และ NDB ทำไมการนำเข้านี้ถึงไม่พูดถึง เหตุผลสองประการ:

• เอ็นจิ้นการจัดเก็บอื่น ๆ นั้นไม่ได้รับประโยชน์หากมีคอร์มากขึ้นนอกเหนือจากดิสก์ I / O พื้นฐานการใช้งาน CPU และปริมาณงานโดยรวม
• โค้ดสำหรับเอ็นจิ้นการจัดเก็บข้อมูลที่ไม่มีการทำธุรกรรมแต่ละรายการซึ่งกำหนดโดยทั่วไป 14 การดำเนินการภายในโดยไม่คำนึงถึงเอ็นจิ้นการจัดเก็บข้อมูลไม่ได้ถูกออกแบบมาเพื่อใช้ประโยชน์จากการเข้าถึงหลายแกน

InnoDB ภายใต้ MySQL 5.5, InnoDB Plugin) และ XtraDB ของ Percona Server มีตัวเลือกที่คุณสามารถตั้งค่าเพื่อเข้าถึงหลายคอร์ (Percona Server ทำงานได้นานขึ้น) ในความเป็นจริงแล้ว Percona ใช้โค้ดประมาณ 30,000 บรรทัดสำหรับการปรับปรุงประสิทธิภาพของ InnoDB พร้อมกับรหัส GA ของ MySQL รุ่นใหม่แต่ละรุ่น เรามั่นใจได้ว่า Oracle ได้รวมการปรับปรุงของตัวเองจากคลังความคิดของตัวเองเพื่อให้ทำงานได้ภายใน InnoDB สำหรับการทำงานแบบมัลติคอร์ (ตั้งแต่ MySQL 5.1.38)

ด้วยความต้องการที่จะดำเนินการMVCCกับข้อมูลร่วมกับการล็อคแถว / หน้าประสิทธิภาพการทำงานของธุรกรรมสามารถถูกวัดและกำหนดค่าได้แล้ว

หากมีสิ่งหนึ่งที่ฉันได้เรียนรู้เกี่ยวกับการใช้หลายคอร์นั่นคือคุณต้องปรับแต่ง InnoDB อย่างมีประสิทธิภาพและไม่เพียง แต่พึ่ง InnoDB เพียงอย่างเดียว

อัพเดท 2011-09-20 08:03 EDT

ในเรื่องที่เกี่ยวกับ InnoDB ที่ได้รับประโยชน์จากทุกแกนเราจำเป็นต้องเก็บรักษาสิ่งต่าง ๆ ไว้ในใจ แกนจะต้องมีแนวโน้มที่จะเรื่องอื่น ๆ (ระบบปฏิบัติการ, ดิสก์, หน่วยความจำ, การใช้งาน, การตรวจสอบและอื่น ๆ ) ในเซิร์ฟเวอร์ฐานข้อมูล สำหรับผู้ที่มีงบประมาณพอสมควรหลายคนมักจะมีเซิร์ฟเวอร์ฐานข้อมูลที่ให้บริการ NFS การตรวจสอบจาก Munin การสนับสนุนแอปสำหรับ JBoss, PHP และรายการต่อไป หากคุณต้องการ MySQL มากขึ้นโดยเฉพาะ InnoDB การใช้แกนมากขึ้น, เซิร์ฟเวอร์ฐานข้อมูลที่จะต้องอุทิศให้กับ MySQL และระบบปฏิบัติการ / ดิสก์ / หน่วยความจำจะต้องมีแนวโน้มที่จะ MySQL เท่านั้น ได้รับมุมมองนี้InnoDB จะมีส่วนร่วมแกนมากขึ้น withtout สงสัย

สำหรับ InnoDB Plugin มันถูกกล่าวถึงเพียงเพื่อแสดงความคิดริเริ่มก่อนหน้านี้เพื่อให้มี InnoDB ที่ดีขึ้นในส่วนของ MySQL (เอ๊ะออราเคิลขออภัยยังไม่ได้ปิดลง) ตัวแปรใหม่เพื่อเรียกกิจกรรมหลักเพิ่มเติมเห็นได้ชัดจาก MySQL 5.1.38

ตัวอย่างเช่นinnodb_read_io_threadsและinnodb_write_io_threads (ทั้งตั้งแต่ MySQL 5.1.38) จัดสรรจำนวนเธรดที่ระบุสำหรับการอ่านและเขียน ค่าเริ่มต้นคือ 4 และสูงสุดคือ 64 การตั้งค่าเริ่มต้นและสูงสุดแตกต่างกันมาก (4 - 64) แสดงให้เห็นว่าInnoDB เป็นแบบมัลติเธรดและคอร์ที่เข้มข้นตามที่คุณกำหนดค่า !!!

Percona ตอบสนองความต้องการของชุมชน MySQL ในการเข้าถึงคอร์มากขึ้นด้วย InnoDB ดังนั้น MySQL เริ่มตามหลังชุดสูท ฉันต้องยอมรับว่า Oracle (yuck) ทำการปรับปรุงที่จำเป็นสำหรับกิจกรรมหลักเพิ่มเติม

ฉันพบว่าการพูดถึงเครื่องมือเก็บข้อมูลโดยใช้แกนประมวลผลอาจทำให้เข้าใจผิดสำหรับผู้เริ่มต้น โดยที่โปรแกรมนั้นมีหลายเธรดอย่างเพียงพอระบบปฏิบัติการจะจัดตารางเวลาให้ทั่วทั้งคอร์มากที่สุดเท่าที่จะเป็นไปได้

ปัญหาเฉพาะที่ จำกัด การปรับซีพียูคือเมื่อรหัสการล็อคภายใน ( mutexes ) มีการช่วงชิงและบล็อกเธรดจากการรันพร้อมกัน เครื่องมือจัดเก็บข้อมูลทั้งหมดจะต้องใช้ mutexes แต่แน่นอนว่ามี Myisam บางตัวที่ร้อนแรง

หากเราเพิกเฉยต่อการโต้แย้งของ mutex เป็นครั้งที่สองและกลับไปที่คำถามหลักของคุณ: สำคัญแค่ไหนที่มีหลายคอร์? -

ฉันชอบที่มีคอร์จำนวนมากสำหรับเวิร์กโหลดที่ตอบสนองการร้องขอของผู้ใช้ การมีหลายคนสามารถลดความแปรปรวนระหว่างเวลาของแบบสอบถาม คิดว่านี่เป็นเหมือนเข้าแถวในซูเปอร์มาร์เก็ตโดยมี 12 ช่องเปิดเทียบกับ 2 ช่องเท่านั้น

อัปเดต : ฉันเขียนบทความในบล็อกเกี่ยวกับสาเหตุที่ความยืดหยุ่นในแนวตั้ง (หลายคอร์) มีความสำคัญ