게스트 OS로 Debian을 사용하여 VM (VMWare)에서 테스트하기 위해 MySQL 서버를 실행하고 있습니다. 게스트에는 4 개의 에뮬레이트 된 CPU 코어가 있으므로 thread_concurrency를 4로 설정했습니다.

몇 분이 걸릴 수있는 큰 테이블에서 값 비싼 조인을 수행하고 있지만 게스트 OS에서는 한 번에 하나의 코어 만 사용됩니다. 이것은 관련된 테이블에 사용 된 스토리지 엔진에 관계없이 발생합니다 (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
============================

이 놀라운 것을 발견 할 수 있지만 innodb_thread_concurrency를 0 (무한 동시성)으로 설정해야합니다. 이를 통해 InnoDB 스토리지 엔진은 발행 할 동시성 티켓 수를 결정할 수 있습니다.

2011 년 5 월 26 일 InnoDB의 멀티 코어 참여 (MySQL 5.5, MySQL 5.1.38 InnoDB 플러그인)에 대한 글을 썼습니다 .

MySQL 문서에 따르면 thread_concurrency 변수 는 Solaris에서만 작동합니다 .

또 하나의 우려가 있습니다 : 귀하의 JOIN이 MyISAM과 InnoDB를 함께 사용하고 있습니까? MyISAM의 전체 테이블 잠금 동작은 InnoDB의 행 수준 잠금 및 MVCC를 무효화 합니다.

MySQL 5.5를 사용하지 않는 경우 InnoDB의 멀티 코어 참여 옵션을 설정하려면 최대한 빨리 업그레이드하십시오 .

업데이트 2012-03-19 08:30 EDT

MySQL 5.1.38부터는 InnoDB 플러그인을 설치하여 멀티 코어 참여를위한 새로운 설정을 사용할 수 있습니다. 그러나 설정을 올바르게 조정해야합니다.

실제로, 구성되지 않은 상태로 두십시오

• MySQL 용 InnoDB 4.1은 단일 또는 스레드 환경에서 이전 버전 이후의 다른 모든 버전의 MySQL보다 더 잘 실행됩니다.
• InnoDB 5.1 플러그인은 이전 또는 이후의 다른 모든 MySQL 버전보다 단일 CPU 환경에서 더 잘 실행됩니다.
• 나는 2011 년 11 월에 이것에 관한 게시물을 썼다 : 왜 mysql 5.5가 5.1보다 느린 이유 (linux, mysqlslap을 사용)
• 또한 2011 년 6 월에 MySQL, Percona Server 및 MariaDB에 대해 자체 벤치 마크를 실행하는 방법에 대한 게시물을 작성했습니다 . MySQL 베이크 오프를 올바르게 수행하려면 어떻게해야합니까?
• 모든 주장은 실제로 모든 MySQL 버전에 대해 성능 벤치 마크를 실행 한 Percona를 기반으로합니다. http://www.mysqlperformanceblog.com/2011/10/10/mysql-versions-shootout/

모든 버전의 MySQL에는 단일 연결 에서 여러 코어를 사용하는 코드가 없습니다 .

Percona는 Xtradb의 여러 연결에서 여러 코어를 더 잘 사용합니다 . InnoDB는 약 8 코어에서 증기가 부족합니다. Xtradb는 32 정도에서 평평 해집니다.

"큰 쿼리"는 다른 연결에 필요한 테이블 (또는 테이블 행)을 잠글 수 있습니다. 쿼리와 SHOW CREATE TABLE을 보자.