ลักษณะเซิร์ฟเวอร์

• ระบบ RAM ทั้งหมด: 8GB (ใช้งาน MySQL + สิ่งอื่นนอกเหนือจาก MySQL ในนั้นคือไม่ได้ทุ่มเทให้กับ MySQL)
• จำนวนคอร์ CPU: 6
• ฉันมีข้อมูลในฐานข้อมูลประมาณ 2GB
• ฉันมี InnoDB Buffer Pool Size ตั้งไว้ที่ 4GB

ไหนดีกว่า:

• Innodb Buffer Pool Instances ตั้งค่าเป็น 1
• Innodb Buffer Pool Instances ตั้งค่าเป็น 2 (2GB ในแต่ละ)?
• Innodb Buffer Pool Instances ตั้งค่าเป็น 4 (แต่ละ 1GB ในแต่ละ)?
• Innodb Buffer Pool Instances ตั้งค่าเป็น 8 (การตั้งค่าเริ่มต้น)

ฉันไม่แน่ใจว่าจะให้เหตุผลอย่างไรเมื่อพูดถึง Buffer Pool Instances และ "ใช้อินสแตนซ์หรือประสบปัญหา Swap OS เมื่อมีขนาดใหญ่เช่น InnoDB Buffer Pool Size"

เมื่อฉันกลับไปที่ MySQL 5.5 ฉันจะคิดถึงสิ่งเดียวกันนี้

สิ่งที่ฉันเรียนรู้ในช่วงหลายปีที่ผ่านมาคือ: ถ้าบัฟเฟอร์พูลใหญ่กว่าครึ่ง RAM ที่ติดตั้งและinnodb_buffer_pool_instancesเป็น 1 (ค่าเริ่มต้นสำหรับ 5.5) ภัยคุกคามจากการแลกเปลี่ยนนั้นใกล้เข้ามาเสมอ

ฉันพูดถึงเรื่องนี้มาก่อน: มีกฎง่ายๆเกี่ยวกับขนาดและจำนวนของอินสแตนซ์บัฟเฟอร์พูลหรือไม่? . ในโพสต์นั้นฉันพูดถึงตัวอย่างของลูกค้าที่มี RAM 192GB บนเซิร์ฟเวอร์ที่มีบัฟเฟอร์บัฟเฟอร์ 162GB เมื่อinnodb_buffer_pool_instancesเป็น 1 การแลกเปลี่ยนเกิดขึ้น เมื่อฉันตั้งinnodb_buffer_pool_instanceเป็น 2 สิ่งต่าง ๆ ก็ดีขึ้น

ในกรณีของคุณเนื่องจาก Buffer Pool มีค่าครึ่งหนึ่งค่า 1 จึงอาจใช้ได้ ฉันจะไม่เสี่ยงมัน ฉันจะตั้งเป็น 2

เนื่องจาก MySQL 5.6 มีค่าเริ่มต้นที่ 8 คุณไม่ควรคิดอีกต่อไป

ผมจะพูดแบบนี้: คำตอบ akuzminsky มีหลักการสูงสุด คำตอบของฉันคือถ่ายจากสะโพกโดยอิงจากประสบการณ์ในอดีต (ดีและไม่ดี)

จำนวนของอินสแตนซ์บัฟเฟอร์พูลควรเพิ่มขึ้นเพื่อหลีกเลี่ยงการโต้แย้งของพูลพูล mutex

ด้วยขนาดบัฟเฟอร์พูล 8GB ฉันสงสัยว่าคุณจะเคยเห็นการโต้แย้งของพูลพูล mutex

อัพเดท 0 :

ฉันพูดถึงบัฟเฟอร์พูล 8Gb ในคำตอบในคำถามเดิมหน่วยความจำทั้งหมดคือ 8GB แน่นอนว่าบัฟเฟอร์พูลต้องน้อยกว่า 8GB เสียง 4GB เริ่มต้นที่ดี แต่ต้องแน่ใจว่าไม่มีการสลับสับเปลี่ยน

อัปเดต 1 :

// จากสไลด์ของ Yasufumi (ใน MySQL รุ่นล่าสุดผลลัพธ์อาจแตกต่างกันเล็กน้อย)

เพื่อตรวจสอบว่ามีการช่วงชิงบน mutex ของพูลบัฟเฟอร์รวบรวมโหลSHOW ENGINE INNODB STATUSตัวอย่างในช่วงเวลาสูงสุดหรือไม่

จากนั้นรวมเข้าด้วยกันโดยใช้ข้อมูลโค้ดของเชลล์:

#!/bin/sh
cat $1.innodb | grep "Mutex at " | cut -d"," -f1 | sort | uniq -c > /tmp/tmp1.txt 
cat $1.innodb | grep "lock on " | cut -d"-"
-f2- | sort | uniq -c > /tmp/tmp2.txt
cat /tmp/tmp1.txt /tmp/tmp2.txt | sort -n > $1.contention rm /tmp/tmp1.txt /tmp/tmp2.txt

ซึ่งให้ผลลัพธ์เช่นนี้

.....
4 lock on RW-latch at 0x7fb86b2c9138 created in file dict/dict0dict.c line 1356
6 lock on RW-latch at 0x7fb86b2c4138 created in file dict/dict0dict.c line 1356
12 lock on RW-latch at 0x7fb86b2d9538 created in file dict/dict0dict.c line 1356
20 lock on RW-latch at 0x7fb86b2db138 created in file dict/dict0dict.c line 1356
22 Mutex at 0x7fb86b28f0e0 created file btr/btr0sea.c line 139
30 lock on RW-latch at 0x7fb86b2ba938 created in file dict/dict0dict.c line 1356
36 lock on RW-latch at 0x7fb86b2bad38 created in file dict/dict0dict.c line 1356
71 Mutex at 0x7fb86b28ecb8 created file buf/buf0buf.c line 597
164 lock on RW-latch at 0x7fb86b28f0b8 created in file btr/btr0sea.c line 139

หากคุณเห็นจำนวน mutex ของบัฟเฟอร์พูลสูงรอถึงเวลาที่จะพิจารณาอินสแตนซ์พูลบัฟเฟอร์หลายอินสแตนซ์ การโต้แย้งไม่น่าจะเกิดขึ้นในบัฟเฟอร์พูลขนาดเล็กกว่า ~ 48G

ตั้งค่า "swappiness" เป็น 1 หากระบบปฏิบัติการของคุณมีเช่น ปัญหาอาจเป็น OOM เชิงรุกมากเกินไป

ฉันขอแนะนำให้ตั้งค่านี้ให้ตรงกับจำนวน MySQL thread สูงสุดที่คุณต้องการเรียกใช้พร้อมกัน ฉันใช้จำนวนแกน

ฉันยังตั้งinnodb_read_io_threadsและinnodb_write_io_threadsให้ตรงกับหมายเลขนี้

หากinnodb_buffer_pool_instancesต่ำเกินไปเธรดของคุณอาจติดค้างในเซมาฟอร์รอ สิ่งนี้ทำให้ทั้ง CPU และ I / O ดูเหมือนจะไม่มีการใช้งานแม้ว่าระบบจะไม่ว่าง - และเวลาแฝงของแอปพลิเคชันของคุณจะผ่านหลังคา