ประสิทธิภาพการจำลองแบบ MySQL


15

ฉันมีปัญหาร้ายแรงกับประสิทธิภาพการทำสำเนา MySQL 5.5 ระหว่างสองเครื่องส่วนใหญ่เป็นตาราง myISAM ที่มีการจำลองแบบตามคำสั่ง บันทึกไบนารีและไดเรกทอรีข้อมูล mysql อยู่ใน Fusion ioDrive เดียวกัน

ปัญหาเป็นปัญหาใหญ่เมื่อเร็ว ๆ นี้เมื่อเราต้องการหยุดการจำลองแบบชั่วคราว 3 ชั่วโมง. ใช้เวลาประมาณ 10 ชั่วโมงในการติดตามอีกครั้งโดยไม่มีโหลดอื่น ๆ

10 ชั่วโมงเพื่อให้ทัน

ฉันจะเพิ่มประสิทธิภาพของการจำลองแบบได้อย่างไร โดยทั่วไปแล้วเครื่อง B ไม่ได้ใช้งาน (น้อย, IO, 2 maxed out cores จาก 16, RAM ฟรีจำนวนมาก) เนื่องจากมีเพียง 1 mySQL thread เท่านั้นที่กำลังเขียนข้อมูล นี่คือความคิดของฉัน:

  • สลับไปที่การจำลองแบบแถว ในการทดสอบนี่ให้ผลเพียง 10-20% เท่านั้น
  • อัพเกรดเป็น mySQL 5.6 ด้วยการจำลองแบบหลายเธรด เราสามารถแบ่งข้อมูลของเราออกเป็นฐานข้อมูลแยกกันได้อย่างง่ายดายและการเปรียบเทียบดูเหมือนว่าบ่งชี้ว่าสิ่งนี้จะช่วยได้ แต่โค้ดดูเหมือนจะยังไม่พร้อมใช้งาน
  • ตัวแปรการกำหนดค่าบางอย่างที่จะช่วยเร่งความเร็วการจำลองแบบ

ปัญหาหลักคือถ้าใช้เวลา 10 ชม. หลังจากหยุดชั่วคราวเป็นเวลา 3 ชั่วโมงหมายความว่าการจำลองข้อมูลกำลังเขียนข้อมูล 13 ชั่วโมงใน 10 ชม. หรือสามารถเขียนที่ความเร็ว 130% ของข้อมูลที่เข้ามาฉันกำลังมองหา อย่างน้อยสองครั้งที่การเขียนบนเครื่อง Master ในอนาคตอันใกล้ดังนั้นต้องการวิธีปรับปรุงประสิทธิภาพการจำลองแบบอย่างมาก

เครื่อง A:

  • เจ้านาย
  • 24GB ราม
  • ฟิวชั่น 1.2TB ioDrive2
  • 2x E5620
  • กิกะบิตเชื่อมต่อระหว่างกัน

my.cnf:

[mysqld]
server-id=71
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp

log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306

log-bin=/data_fio/mysqlbinlog/mysql-bin.log
binlog-format=STATEMENT
replicate-ignore-db=mysql

log-slave-updates = true

# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000

# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32

user=mysql

symbolic-links=0

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysql]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

เครื่อง B:

  • ทาส
  • 36GB ราม
  • ฟิวชั่น 1.2TB ioDrive2
  • 2x E5620
  • กิกะบิตเชื่อมต่อระหว่างกัน

my.cnf:

[mysqld]
server-id=72
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp

log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306

# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000

# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32

user=mysql

symbolic-links=0

plugin-load=archive=ha_archive.so;blackhole=ha_blackhole.so

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysql]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

เครื่อง B ไม่ได้ใช้งานโดยทั่วไป นี่คือประสบการณ์ของฉันกับการจำลองแบบบน MySQL 5.1 การจำลองแบบเป็นเธรดเดียวและ CPU หนึ่งจะถูก maxed ออกในขณะที่คนอื่นนั่งว่าง
Stefan Lasiewski

คุณกำลังสำรองข้อมูลจากทาสหรือไม่
Mike

@ stefan-lasiewski เพื่อให้ชัดเจนนี่คือ MySQL 5.5 แต่ใช่ มันเป็นหัวข้อเดียวและน่าผิดหวังมาก
นิค

@ ไมค์ใช่เช่นเดียวกับการสืบค้นที่หนักซึ่งใช้เวลาหลายนาทีตลอดทั้งวัน การจำลองแบบช้าไป ~ 100 หรือมากกว่านั้นและจากนั้นใช้เวลาสักครู่เพื่อติดตามอีกครั้ง บริการที่เรียกใช้คิวรีเหล่านี้จะเรียกใช้คิวรีหนึ่งรอให้มันติดตามแล้วรันอีกครั้งรอ ฯลฯ ... หากเราสามารถเร่งความเร็วการจำลองแบบได้เราสามารถเพิ่มความถี่ที่เราเรียกใช้คิวรีเหล่านี้
Nick

1
@ stefan-lasiewski ใช่ - หากไม่มีสิ่งใดหยุดยั้งการจำลองแบบเห็นได้ชัดว่ามันจะไม่ได้รับการแก้ไข ปัญหาหลักคือความเร็วการจำลองแบบเป็นคอขวดเพื่อเพิ่มการเขียนบนต้นแบบ หากใช้เวลา 3.3 วินาทีในการติดตาม 1 วินาทีนั่นหมายความว่าการจำลองแบบกำลังเขียนข้อมูล 4.3s ใน 3.3s หรือสามารถทำซ้ำได้ที่ 130% ของความเร็วของข้อมูลที่เข้ามาฉันต้องการเขียนอย่างน้อยสองครั้ง โหลดบนเซิร์ฟเวอร์นี้
Nick

คำตอบ:


4

ว้าวคุณมีฮาร์ดแวร์ที่ยอดเยี่ยมสำหรับปัญหานี้ มีอะไรอีกมากมายที่คุณสามารถทิ้งฮาร์ดแวร์ไว้ได้อย่างชาญฉลาดยกเว้นการอัพเกรดซีพียู Sandy / Ivy Bridge เพื่อประสิทธิภาพที่ดีขึ้น 20-50% จากการค้นหา Btree เป็นต้น

โปรดทราบว่ามือขวาของฉันคือ Innodb ดังนั้นฉันจะไป

  1. ไม่ต้องสนใจว่าคุณเป็นเมียมาและทำราวกับว่ามันจะไม่สร้างความแตกต่าง
  2. สมมติว่าปัญหานี้เป็นแรงผลักดันให้คุณอัปเกรด ใช่มันเป็นการอัพเกรด

Innodb สามารถช่วยให้ได้รับประโยชน์อย่างมากจากหน่วยความจำทั้งหมดโดยการจัดเก็บแถวที่เข้าถึงบ่อยเหล่านี้ในบัฟเฟอร์พูล คุณสามารถปรับแต่งมันให้มีขนาดใหญ่ที่สุดเท่าที่คุณต้องการ (พูด 80% ของหน่วยความจำ) และการอ่าน / เขียนที่สดใหม่จะยังคงอยู่ในหน่วยความจำจนกว่าจะต้องผลักมันไปที่ดิสก์เพื่อเพิ่มพื้นที่สำหรับข้อมูลที่เข้าถึงล่าสุด ในหน่วยความจำคือลำดับความสำคัญเร็วกว่า FusionIO ของคุณ

มีคุณสมบัติ Innodb มากมายเช่นแฮชที่ปรับได้กลไกการล็อคอัตโนมัติเป็นต้นซึ่งอาจเป็นประโยชน์ต่อสภาพแวดล้อมของคุณ อย่างไรก็ตามคุณทราบข้อมูลของคุณดีกว่าที่ฉันทำ

ในโลก Innodb ทางออกระยะสั้นที่ดีคือการเพิ่มประสิทธิภาพทาสของคุณ - คุณต้องการดัชนีทุกตัวสำหรับทาสที่คุณมีต่อเจ้านายของคุณหรือไม่? ดัชนีเป็นลูกบอลและเชนในส่วนแทรก / อัพเดต / ลบแม้จะมีการ์ด Fusion IO IOPS ไม่ใช่ทุกอย่างที่นี่ procs Sandy / Ivy Bridge มีหน่วยความจำความเร็วและประสิทธิภาพการประมวลผลที่ดีขึ้นมาก - พวกเขาสามารถสร้างความแตกต่างอย่างมากของ Westmeres ที่คุณมีตอนนี้ (ภาพรวม 20-50%) ลบดัชนีทั้งหมดที่คุณไม่ต้องการใช้กับทาส!

ข้อที่สองและเกือบจะใช้กับ innodb เท่านั้นคือ mk-prefetch สามารถรู้ได้ว่าการอัพเดตใดและก่อนที่ทาสจะเขียนมัน สิ่งนี้อนุญาตให้ mk-prefetch รันการสืบค้นแบบอ่านก่อนดังนั้นจึงบังคับให้ข้อมูลอยู่ในหน่วยความจำตามเวลาที่การจำลองแบบครั้งเดียวรันการสืบค้นแบบเขียน ซึ่งหมายความว่าข้อมูลอยู่ในหน่วยความจำไม่ใช่ฟิวชั่นซึ่งเป็นลำดับความรวดเร็วที่เพิ่มขึ้น นี้จะทำให้ขนาดใหญ่แตกต่างกันมากกว่าหนึ่งอาจคาดหวัง บริษัท จำนวนมากใช้สิ่งนี้เป็นโซลูชั่นถาวร ค้นหาข้อมูลเพิ่มเติมได้โดยการตรวจสอบจากPercona Toolkit

ลำดับที่สามและที่สำคัญที่สุดเมื่อคุณอัปเกรดเป็น Innodb แล้วให้ชำระเงิน Tokutek อย่างแน่นอน พวกเหล่านี้มีบางสิ่งที่ยอดเยี่ยมเกินควรซึ่งเกินกว่าประสิทธิภาพการเขียน / อัปเดต / ลบของ Innodb โดยการยิงยาว ๆ พวกเขา tout ความเร็วการจำลองแบบที่ดีขึ้นเป็นหนึ่งในผลประโยชน์ที่สำคัญและคุณสามารถดูจากมาตรฐานของพวกเขาว่าทำไม Fusions บ้า IOPS จะยังคงไม่ช่วยให้คุณในกรณีของ Btrees (หมายเหตุ: ไม่ได้ตรวจสอบโดยฉัน) พวกเขาใช้ดรอปอินแทนดัชนี btree ซึ่งในขณะที่มีความซับซ้อนมากขึ้นช่วยแก้ไขข้อ จำกัด ความเร็วอัลกอริทึมหลายอย่างของดัชนี btree

ฉันอยู่ระหว่างการพิจารณาการยอมรับ Tokutek หากพวกเขาเพิ่มความเร็วในการเขียนมากขึ้นนั่นทำให้ฉันสามารถเพิ่มดัชนีได้มากขึ้น เนื่องจากพวกเขาบีบอัดข้อมูลและดัชนีด้วยอัตราส่วนที่ยอดเยี่ยม (พวกเขาอ้างถึง 25x) คุณไม่ต้องจ่ายแม้แต่ราคา (ประสิทธิภาพการบำรุงรักษา) สำหรับข้อมูลที่เพิ่มขึ้น คุณต้องจ่าย ($) สำหรับเอ็นจิ้นของพวกเขา แต่ $ 2,500 / ปีต่อ GB ที่ได้รับการบีบอัดล่วงหน้า IIRC พวกเขามีส่วนลดถ้าคุณมีข้อมูลที่จำลองแบบ แต่คุณสามารถติดตั้ง Tokutek ลงบนทาสของคุณและรักษาเจ้านายของคุณตามที่เป็นอยู่ ตรวจสอบรายละเอียดทางเทคนิคในการบรรยาย MIT Algoritms เปิดบทเรียน อีกวิธีหนึ่งคือพวกเขามีเนื้อหาทางเทคนิคมากมายในบล็อกและสมุดปกขาวปกติสำหรับผู้ที่ไม่มี 1:20 ในการดูวิดีโอ ฉันเชื่อว่าวิดีโอนี้ให้สูตร Big-O สำหรับการอ่านที่รวดเร็ว ฉันมีสมมติว่าการอ่านช้ากว่า (มีข้อเสียเสมอ!) แต่สูตรซับซ้อนเกินกว่าที่ฉันจะวัดได้เท่าไหร่ พวกเขาอ้างว่ามันเหมือนกัน แต่ฉันค่อนข้างจะเข้าใจคณิตศาสตร์ (ไม่น่าจะ!) คุณอาจจะค้นพบสิ่งนี้ได้ดีกว่าฉัน

ป.ล. ฉันไม่ได้มีส่วนเกี่ยวข้องกับ Tokutek ฉันไม่เคยเรียกใช้ผลิตภัณฑ์ของพวกเขาและพวกเขาไม่รู้ด้วยซ้ำว่าฉันกำลังดูพวกเขาอยู่

อัปเดต :

ฉันเห็นคุณมีคำถามอื่น ๆ ในหน้านี้และคิดว่าฉันจะชิปใน:

ก่อนอื่นการเรียกทาสล่วงหน้าเกือบจะไม่ทำงานกับ myisam เว้นแต่ว่าคุณจะมีสภาพแวดล้อมที่พิเศษ นี่เป็นส่วนใหญ่เนื่องจากการดึงข้อมูลล่วงหน้าจะถูกล็อคตารางที่คุณตั้งใจจะเขียนหรือมิฉะนั้นเธรดที่เป็นทาสจะมีตารางถูกล็อกที่ต้องการการดึงข้อมูลล่วงหน้าล่วงหน้า หากตารางของคุณมีความสมดุลอย่างมากสำหรับการทำซ้ำและตารางที่แตกต่างกันกำลังถูกเขียนไปในรูปแบบรอบ - โรบินนี่อาจใช้ได้ - แต่โปรดจำไว้ว่านี่เป็นทฤษฎี หนังสือ "Mysql ประสิทธิภาพสูง" มีข้อมูลเพิ่มเติมในส่วน "ปัญหาการจำลองแบบ"

ประการที่สองสันนิษฐานว่าทาสของคุณมีโหลด 1.0-1.5 มันอาจจะสูงกว่าถ้าคุณมี procs หรือคิวรีอื่น ๆ ที่ทำงานอยู่ แต่พื้นฐานเป็น 1.0 ซึ่งหมายความว่าคุณมีแนวโน้มว่า CPU จะถูกผูกไว้กับ FusionIO ของคุณ อย่างที่ฉันได้กล่าวไปแล้วก่อนหน้านี้ Sandy / Ivy Bridge กำลังจะอุ้มน้ำเพิ่มอีกนิดหน่อย แต่อาจจะไม่เพียงพอที่จะพาคุณผ่านช่วงเวลาที่ยากลำบากไปได้ หากโหลดบนสลาฟนี้ส่วนใหญ่เป็นแบบเขียนอย่างเดียว (นั่นคืออ่านไม่มาก) ซีพียูของคุณเกือบจะใช้เวลาในการคำนวณตำแหน่งสำหรับการแทรก / ลบ btree สิ่งนี้ควรเสริมจุดของฉันด้านบนเกี่ยวกับการลบดัชนีที่ไม่สำคัญ - คุณสามารถเพิ่มดัชนีเหล่านั้นใหม่ได้ในภายหลัง การปิดใช้งานไฮเปอร์เธรดจะไม่ทำงาน CPU มากขึ้นไม่ใช่ศัตรูของคุณ เมื่อคุณได้รับ RAM 32GB ที่สูงกว่าพูดถึง 64GB คุณต้องกังวลเกี่ยวกับการกระจาย RAMแต่ถึงอย่างนั้นอาการก็จะต่างกัน

ในที่สุดและที่สำคัญที่สุด (อย่าข้ามส่วนนี้;)) ฉันสมมติว่าคุณกำลังรัน RBR (การจำลองแบบแถวตาม) เพราะคุณพูดถึงการเพิ่มขึ้นของประสิทธิภาพที่ไม่น่ารำคาญเมื่อเปลี่ยนไป อย่างไรก็ตาม - อาจมีวิธีในการเพิ่มประสิทธิภาพที่นี่ ข้อผิดพลาด Mysql 53375สามารถแสดงให้เห็นว่าคุณมีตารางที่ถูกจำลองแบบโดยไม่มีคีย์หลัก โดยพื้นฐานแล้วทาสไม่ฉลาดพอที่จะใช้อะไรก็ได้นอกจากคีย์หลักดังนั้นการไม่มีตัวบังคับให้เธรดการจำลองแบบทำการสแกนเต็มตารางสำหรับทุกการอัปเดต. การแก้ไขเป็นเพียงการเพิ่มคีย์หลักการสร้างตัวแทนอัตโนมัติที่อ่อนโยน ฉันจะทำสิ่งนี้ถ้าตารางมีขนาดใหญ่ (พูดหลายสิบหมื่นแถวหรือใหญ่กว่า) แน่นอนว่าสิ่งนี้มาจากค่าใช้จ่ายของการมีดัชนีอื่นบนโต๊ะซึ่งจะแสดงราคาที่คุณจ่ายเป็นซีพียู โปรดสังเกตว่ามีข้อโต้แย้งเชิงทฤษฎีน้อยมากเนื่องจาก InnoDB จะเพิ่มสิ่งที่อยู่เบื้องหลังหากคุณไม่ทำ อย่างไรก็ตามหนึ่งในปีศาจก็ไม่ได้มีประโยชน์ในการป้องกัน 53375 ทังสเตนสามารถเอาชนะปัญหานี้ได้เช่นกัน แต่คุณต้องแน่ใจว่าเมื่อใช้ทังสเตนที่คุณมีการเข้ารหัสตรง ครั้งสุดท้ายที่ฉันเล่นกับมันมันจะตายอย่างน่ากลัวเมื่อสตริงที่ไม่ใช่ UTF8 จำเป็นต้องจำลองแบบ นั่นคือเวลาที่ฉันยอมแพ้


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

ว้าวนี้เป็นบางส่วนวิเคราะห์ MySQL ที่ยอดเยี่ยมอย่างจริงจัง :)
เควิน

4

ไม่ใช่คำตอบ แต่คุณอาจพิจารณาตัวเลียนแบบทังสเตนและผลิตภัณฑ์เชิงพาณิชย์เพื่อความยืดหยุ่นมากขึ้น การใช้ cpu 100% บนคอร์แกนเดี่ยวที่เป็นคอขวดหรือไม่?


ขอบคุณ! นั่นเป็นวิธีแก้ปัญหาที่น่าสนใจแม้ว่าฉันจะลังเลเล็กน้อยที่จะเสียบซอฟต์แวร์บุคคลที่สามลงใน MySQL ในเอกสารกล่าวว่า "ไม่จำเป็นต้องอัปเกรดเพื่อรอรุ่น MySQL ในอนาคตหรือย้ายไปยังทางเลือกที่ยังไม่ทดลอง" ดังนั้นจึงดูเหมือนว่าจะคล้ายกับที่ MySQL 5.6 จะสนับสนุน คุณมีประสบการณ์เกี่ยวกับ Tungsten Replicator หรือไม่?
Nick

ไม่เพิ่งรู้ว่าผู้มีส่วนร่วมระบบนิเวศ mysql ที่มีชื่อเสียงทำงานให้พวกเขา [ datacharmer.blogspot.com ] คุณคิดว่ามันเป็นคอขวดหรือเปล่า?
pQd

ขอบคุณสำหรับข้อมูล. RE: ปัจจัยที่ จำกัด ไม่ฉันไม่แน่ใจเลย ฉันไม่คิดว่าเป็น I / O เนื่องจาก iostat รายงานว่า Fusion ioDrive กำลังเขียน <10 MB / s ฉันค่อนข้างแน่ใจว่าอุปกรณ์นี้มีความสามารถมากกว่า ในทางกลับกันจะมี 1 เสมอและเพิ่มอีก 1 แกนเป็นระยะ ๆ ที่ตรึงที่ 100% ในขณะที่คนอื่น ๆ ไม่ได้ใช้งาน สิ่งที่เกี่ยวกับการปิดใช้งานการทำเกลียวมากเกินไป?
Nick

@Nick - ขออภัยฉันไม่สามารถให้คำแนะนำเกี่ยวกับไฮเปอร์เธรด แต่ลอง ... ด้วย - ลองติดตั้ง munin หรือ cacti ด้วยเทมเพลต mysql และดูรายละเอียดเพิ่มเติมว่าเกิดอะไรขึ้น
pQd

ตรวจสอบโพสต์นี้จากกลุ่ม Continuent: scale-out-blog.blogspot.ca/2011/10/…ข้อความอ้างอิง: "โดยรวมแล้วเราสามารถพูดได้อย่างปลอดภัยว่าการจำลองแบบเนทีฟแบบเธรดเดียวนั้นไม่สามารถทำงานได้ใน I / O-bound เคสโดยไม่ต้องใช้ SSD และ / หรือ Slave แบบรวมกันก่อน "
HTTP500

2

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


อย่างแน่นอน เราทำการล็อคตารางเป็นประจำสำหรับการสำรองข้อมูลหรือการสืบค้นแบบยาว แต่ปัญหาจะอยู่ที่ความเร็วของการจำลองแบบเมื่อเธรด IO กลับมาทำงานต่อ ฉันประมาณการว่ามันจะทำการเรพลิเคตที่ 130% ของความเร็วของข้อมูลที่เข้ามาเท่านั้นซึ่ง จำกัด ว่าเราจะสามารถปรับการตั้งค่านี้ได้มากน้อยเพียงใดเว้นแต่ว่าเราสามารถปรับปรุงความเร็วในการจำลองข้อมูลได้ มันสมเหตุสมผลไหม
Nick
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.