การใช้หลายคอร์สำหรับเคียวรี MySQL เดี่ยวบน Debian


10

ฉันใช้เซิร์ฟเวอร์ MySQL สำหรับการทดสอบบน VM (VMWare) กับ Debian ในฐานะแขกของระบบปฏิบัติการ แขกมีคอร์ CPU ที่จำลองสี่แกนดังนั้นฉันจึงตั้งค่า thread_concurrency เป็นสี่

ฉันกำลังทำร่วมราคาแพงบนโต๊ะขนาดใหญ่ซึ่งอาจใช้เวลาหลายนาที แต่ฉันเห็นในระบบปฏิบัติการของแขกว่ามีเพียงหนึ่งคอร์เท่านั้นที่ใช้ในแต่ละครั้ง สิ่งนี้เกิดขึ้นโดยไม่คำนึงถึงเอ็นจิ้นการจัดเก็บที่ใช้สำหรับตารางที่เกี่ยวข้อง (ทดสอบกับ MyISAM และ InnoDB) นอกจากนี้ฐานข้อมูลทั้งหมดดูเหมือนจะถูกบล็อกเมื่อทำการสอบถามขนาดใหญ่เหล่านี้ฉันไม่สามารถทำแบบสอบถามเพิ่มเติมใด ๆ ในแบบคู่ขนาน แสดงว่า htop แปลก ๆ ที่แกนกลางที่ใช้สำหรับคิวรีนั้นเปลี่ยนไปในระหว่างรันไทม์ของคิวรี!

ทำไมสิ่งนี้ถึงเกิดขึ้น

นี่คือรายการที่เกี่ยวข้องจากSHOW FULL PROCESSLIST;(ไม่มีคำสั่งอื่น ๆ ):

| 153 | root       | localhost | pulse_stocks  | Query   |   50 | Copying to tmp table | 
SELECT DISTINCT * FROM 
`pulse_stocks`.`stocks` sto,
`pulse_new`.`security` sec
WHERE
(sto.excntry = sec.excntry AND sto.stock_id = sec.ibtic) OR
( sto.isin = sec.isin AND sto.isin <> "" AND sec.isin <> "" )
ORDER BY
sto.id
LIMIT 0, 30 

ไม่มีการค้นหาอื่น ๆ ที่รอดำเนินการ ข้อสังเกตที่น่าสนใจอีกข้อหนึ่งคือว่า MySQL จะตอบแบบสอบถามนี้ภายในORDER BYไม่กี่วินาที

นี่คือสิ่งที่SHOW ENGINE INNODB STATUS;แสดง:

=====================================
120316  9:55:56 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 49 seconds
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 47258, signal count 47258
Mutex spin waits 0, rounds 10260, OS waits 39
RW-shared spins 94442, OS waits 47210; RW-excl spins 1, OS waits 1
------------
TRANSACTIONS
------------
Trx id counter 0 5381
Purge done for trx's n:o < 0 1810 undo n:o < 0 0
History list length 2
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 0, not started, process no 7503, OS thread id 140316748777216
MySQL thread id 154, query id 654 localhost root
SHOW ENGINE INNODB STATUS
---TRANSACTION 0 5380, ACTIVE 105 sec, process no 7503, OS thread id 140316748977920
 fetching rows, thread declared inside InnoDB 429
mysql tables in use 2, locked 0
MySQL thread id 153, query id 623 localhost root Copying to tmp table
SELECT DISTINCT * FROM 
    `pulse_stocks`.`stocks` sto,
    `pulse_new`.`security` sec
WHERE
    (sto.excntry = sec.excntry AND sto.stock_id = sec.ibtic) OR
    ( sto.isin = sec.isin AND sto.isin <> "" AND sec.isin <> "" )
ORDER BY
    sto.id
LIMIT 0, 30

Trx read view will not see trx with id >= 0 5381, sees < 0 5381
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
 ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
116089 OS file reads, 7 OS file writes, 7 OS fsyncs
1063.16 reads/s, 117085 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 5, seg size 7,
0 inserts, 0 merged recs, 0 merges
Hash table size 17393, node heap has 1 buffer(s)
0.00 hash searches/s, 14.73 non-hash searches/s
---
LOG
---
Log sequence number 0 38201270
Log flushed up to   0 38201270
Last checkpoint at  0 38201270
0 pending log writes, 0 pending chkp writes
10 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 20638760; in additional pool allocated 994816
Dictionary memory allocated 162680
Buffer pool size   512
Free buffers       0
Database pages     511
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 816631, created 0, written 1
7597.72 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 964 / 1000
--------------
ROW OPERATIONS
--------------
1 queries inside InnoDB, 0 queries in queue
2 read views open inside InnoDB
Main thread process no. 7503, id 140316711446272, state: waiting for server activity
Number of rows inserted 0, updated 0, deleted 0, read 160338394
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 1495933.31 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

โปรดโพสต์ผลลัพธ์ของ SHOW FULL PROCESSLIST (อาจถูกทำให้สะอาด) และสถานะ INNODB SHOW ENGINE ENGINE เพื่อช่วยเราวิเคราะห์สาเหตุที่ "ฐานข้อมูลทั้งหมด" ถูกล็อค
Aaron Brown

ขอบคุณฉันอัปเดตคำถามด้วยข้อมูลที่ร้องขอ
Thomas

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

ตกลงฉันตรวจสอบนี้ มันเป็นไปได้ที่จะทำแบบสอบถามอื่น ๆ ในคอนโซล mysql แม้เมื่อมีการเรียกใช้แบบสอบถามขนาดใหญ่ อย่างไรก็ตาม phpmyadmin ไม่ตอบสนองเลยแม้แต่การพยายามเข้าสู่ระบบอย่างง่ายในขณะที่กำลังดำเนินการค้นหา เวลาดำเนินการเองมักจะน้อยกว่า 10 วินาที แต่แบบสอบถามยังคงอยู่ในสถานะ "ส่งข้อมูล" เป็นเวลาหลายนาที
โทมัส

คำตอบ:


10

คุณอาจพบสิ่งที่น่าประหลาดใจ แต่คุณควรตั้งค่า Innodb_thread_concurrency เป็น 0 (ซึ่งเป็นค่าที่เกิดขึ้นพร้อมกันไม่สิ้นสุด) สิ่งนี้จะช่วยให้ InnoDB Storage Engine สามารถตัดสินใจว่าจะออกตั๋วชมพ้องด้วยจำนวนเท่าไร

ผมเขียนบทความเกี่ยวกับ InnoDB ของมัลติคอร์มีส่วนร่วม (MySQL 5.5 ยัง MySQL 5.1.38 InnoDB ปลั๊กอิน) กลับไปเมื่อวันที่ 26 พฤษภาคม 2011

ตามเอกสารของ MySQL ตัวแปรthread_concurrency นั้นใช้ได้กับ Solarisเท่านั้น

ฉันมีข้อกังวลอีกข้อหนึ่ง: การเข้าร่วมของคุณเกี่ยวข้องกับ MyISAM และ InnoDB ด้วยกันไหม? MyISAM เต็มรูปแบบของตารางล็อคโมฆะพฤติกรรมล็อคระดับแถว InnoDB และ MVCC

ถ้าคุณไม่ได้ใช้ MySQL 5.5 โปรดปรับให้เร็วที่สุดเพื่อที่จะตั้งค่าตัวเลือก InnoDB multicore หมั้น

อัพเดท 2012-03-19 08:30 EDT

เริ่มต้นด้วย MySQL 5.1.38 คุณสามารถติดตั้งปลั๊กอิน InnoDB เพื่อใช้การตั้งค่าใหม่สำหรับการมีส่วนร่วมแบบมัลติคอร์ อย่างไรก็ตามคุณต้องปรับการตั้งค่าให้เหมาะสม

ในความเป็นจริงที่เหลือไม่มีการกำหนดค่า

  • InnoDB สำหรับ MySQL 4.1 ทำงานได้ดีขึ้นในสภาพแวดล้อมแบบเธรดเดียวกว่า MySQL รุ่นอื่นทั้งหมดก่อนหรือหลัง
  • ปลั๊กอิน InnoDB 5.1 ทำงานได้ดีขึ้นในสภาพแวดล้อม CPU เดียวกว่า MySQL รุ่นอื่นทั้งหมดก่อนหรือหลัง
  • ฉันเขียนโพสต์เกี่ยวกับเรื่องนี้ในเดือนพฤศจิกายน 2011: ทำไม mysql 5.5 ช้ากว่า 5.1 (linux โดยใช้ mysqlslap)
  • ฉันยังเขียนโพสต์กลับในเดือนมิถุนายน 2011 เกี่ยวกับวิธีที่คุณสามารถรันเกณฑ์มาตรฐานของคุณเองกับ MySQL, เซิร์ฟเวอร์ Percona และ MariaDB: ฉันจะทำ MySQL อบอย่างถูกต้องได้อย่างไร?
  • การยืนยันของฉันทั้งหมดนั้นขึ้นอยู่กับ Percona ที่ใช้ Performance Benchmark เปรียบเทียบกับ MySQL ทุกรุ่น: http://www.mysqlperformanceblog.com/2011/10/10/mysql-versions-shootout/

ขอบคุณมาก. คำตอบของคุณบอกเป็นนัย ๆ ว่าการใช้หลายคอร์ไม่ได้ใช้งานในเวอร์ชัน 5.1.X หรือไม่?
โทมัส

ใช่และไม่. ฉันบอกว่าใช่เพราะ InnoDB 5.1.x ไม่มีการตั้งค่ามัลติคอร์ ฉันบอกว่าไม่เพราะคุณสามารถติดตั้งปลั๊กอิน InnoDB สำหรับการตั้งค่าใหม่เหล่านี้ แต่ใช้ได้กับ MySQL 5.1.38 ขึ้นไปเท่านั้น
RolandoMySQLDBA

@RolandoMySQLDBA: ขออภัยฉันรู้ว่าโพสต์นี้เก่า แต่ฉันพบว่า mysql บนเซิร์ฟเวอร์ของฉัน (ซึ่งมี 24 คอร์) ใช้เพียง 1 คอร์เท่านั้น ฉันตรวจสอบinnodb_thread_cuncurrencyตามที่คุณกล่าวถึงและตั้งค่าเป็น 0 ดังนั้นฉันสงสัยว่าทำไม mysql ไม่ใช้แกนเพิ่มเติม
monamona

1
@monamona นั่นไม่ใช่การตั้งค่าเดียวที่เล่นด้วย คุณต้องตั้งค่า innodb_read_io_threads และ innodb_write_io_threads ให้สูงขึ้น (ลอง 8, 16, 32 และ 64)
RolandoMySQLDBA

@monamona โปรดอ่านโพสต์เก่าของฉันdba.stackexchange.com/questions/2918/…สำหรับรายละเอียดเพิ่มเติม
RolandoMySQLDBA

2

MySQL ทุกรุ่นไม่มีรหัสใด ๆ ที่จะใช้หลายคอร์ในการเชื่อมต่อเดียว

Percona ทำงานได้ดีกว่าในการใช้หลายคอร์ในหลาย ๆการเชื่อมต่อใน Xtradb InnoDB หมดไอน้ำที่ 8 คอร์ Xtradb แบนออกที่ 32 หรือมากกว่านั้น

"เคียวรีขนาดใหญ่" อาจล็อกตาราง (หรือแถวของตาราง) ที่การเชื่อมต่ออื่น ๆ ต้องการ ลองดูที่แบบสอบถามและตารางแสดงผล

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.