Sử dụng nhiều lõi cho các truy vấn MySQL đơn trên Debian


10

Tôi đang chạy máy chủ MySQL để kiểm tra trên VM (VMWare) với Debian là hệ điều hành khách. Khách có bốn lõi CPU được mô phỏng, vì vậy tôi đặt thread_concurrency thành bốn.

Tôi đang thực hiện các phép nối đắt tiền trên các bảng lớn, có thể mất vài phút, nhưng tôi thấy trên hệ điều hành khách, chỉ có một lõi được sử dụng tại một thời điểm. Điều này xảy ra bất kể công cụ lưu trữ được sử dụng cho các bảng có liên quan (đã được thử nghiệm với MyISAM và InnoDB). Ngoài ra, toàn bộ cơ sở dữ liệu dường như bị chặn khi thực hiện các truy vấn lớn này, tôi không thể thực hiện bất kỳ truy vấn bổ sung nào song song. Htop lạ lùng cho thấy, lõi được sử dụng cho truy vấn thay đổi trong thời gian chạy truy vấn!

Lý do tại sao điều này xảy ra?

Đây là mục liên quan từ SHOW FULL PROCESSLIST;(không có truy vấn nào khác):

| 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 

Không có câu hỏi nào khác đang chờ xử lý. Một quan sát thú vị khác là, MySQL sẽ trả lời truy vấn này trong một giây, nếu tôi bỏ qua ORDER BYphần đó.

Điều này SHOW ENGINE INNODB STATUS;cho thấy:

=====================================
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
============================

Vui lòng gửi đầu ra của SHOW FULL PROCESSLIST (có thể được khử trùng) và SHOW Engine INNODB STATUS để giúp chúng tôi chẩn đoán tại sao "toàn bộ cơ sở dữ liệu" bị khóa.
Aaron Brown

Cảm ơn bạn, tôi đã cập nhật câu hỏi với các thông tin được yêu cầu.
Thomas

1
Nếu không có truy vấn nào khác đang chạy, thì không có bằng chứng nào cho thấy toàn bộ cơ sở dữ liệu bị khóa. Bạn có thể tái tạo điều kiện này và đăng những gì xảy ra khi truy vấn dài hạn rõ ràng đang khóa những người khác không?
tước Schwartz

Ok, tôi đã kiểm tra này. Có thể thực hiện các truy vấn khác trong bảng điều khiển mysql, ngay cả khi truy vấn lớn đang chạy. Tuy nhiên, phpmyadmin hoàn toàn không phản hồi, ngay cả với những lần thử đăng nhập đơn giản, trong khi truy vấn đang được thực thi. Thời gian thực hiện thường dưới 10 giây, nhưng truy vấn vẫn ở trạng thái "gửi dữ liệu" trong vài phút.
Thomas

Câu trả lời:


10

Bạn có thể thấy điều này đáng ngạc nhiên, nhưng bạn nên đặt innodb_thread_concurrency thành 0 (là đồng thời vô hạn). Điều này sẽ cho phép Công cụ lưu trữ InnoDB quyết định có bao nhiêu vé đồng thời phát hành.

Tôi đã viết một bài về sự tham gia đa lõi của InnoDB (MySQL 5.5, cũng là Plugin 5.1 5.1 của InnoDB) vào ngày 26 tháng 5 năm 2011 .

Theo Tài liệu MySQL, biến thread_concurrency chỉ hoạt động cho Solaris .

Tôi có một mối quan tâm nữa: THAM GIA của bạn có liên quan đến MyISAM và InnoDB không? Hành vi khóa toàn bảng của MyISAM sẽ vô hiệu hóa khóa cấp hàng và MVCC của InnoDB .

Nếu bạn không sử dụng MySQL 5.5, vui lòng nâng cấp ASAP để thiết lập các tùy chọn tương tác đa lõi của InnoDB .

CẬP NHẬT 2012/03/19 08:30 EDT

Bắt đầu với MySQL 5.1,38, bạn có thể cài đặt Plugin InnoDB để sử dụng các cài đặt mới để tương tác đa lõi. Tuy nhiên, bạn phải điều chỉnh các cài đặt đúng.

Trong thực tế, không được cấu hình


Cảm ơn rât nhiều. Câu trả lời của bạn có ngụ ý rằng việc sử dụng nhiều lõi không được triển khai trong phiên bản 5.1.X không?
Thomas

Có và không. Tôi nói CÓ becasue InnoDB 5.1.x không có cài đặt đa lõi. Tôi nói KHÔNG vì bạn có thể cài đặt Plugin InnoDB cho các cài đặt mới này, nhưng nó chỉ có sẵn cho MySQL 5.1,38 trở lên.
RolandoMySQLDBA

@RolandoMySQLDBA: Xin lỗi, tôi biết bài đăng này đã cũ, nhưng tôi thấy rằng mysql trên máy chủ của tôi (có 24 lõi) chỉ sử dụng 1 lõi. Tôi đã kiểm tra innodb_thread_cuncurrencynhư bạn đề cập và nó được đặt thành 0, vì vậy tôi đã tự hỏi tại sao mysql không sử dụng nhiều lõi hơn?
monamona

1
@monamona Đó không phải là thiết lập duy nhất để chơi với. Bạn cũng phải đặt innodb_read_io_threads và innodb_write_io_threads cao hơn (Hãy thử 8, 16, 32 và 64).
RolandoMySQLDBA

@monamona Vui lòng đọc bài viết cũ của tôi dba.stackexchange.com/questions/2918/ vào để biết thêm chi tiết
RolandoMyQueryDBA

2

MySQL, bất kỳ phiên bản, không có bất kỳ mã để sử dụng đa lõi trong một đơn kết nối.

Percona thực hiện công việc tốt hơn là sử dụng nhiều lõi trên nhiều kết nối trong Xtradb của mình. InnoDB hết hơi ở khoảng 8 lõi; Xtradb làm phẳng ở 32 hoặc hơn.

Một "truy vấn lớn" có thể khóa bảng (hoặc các hàng của bảng) mà một số kết nối khác cần. Chúng ta hãy xem truy vấn và BẢNG TẠO HIỂN THỊ.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.