Estoy ejecutando un servidor MySQL para pruebas en una VM (VMWare) con Debian como SO huésped. El invitado tiene cuatro núcleos de CPU emulados, por lo que configuré thread_concurrency en cuatro.

Estoy haciendo costosas uniones en tablas grandes, lo que puede llevar varios minutos, pero veo en el sistema operativo invitado que solo se usa un núcleo a la vez. Esto sucede independientemente del motor de almacenamiento utilizado para las tablas involucradas (probado con MyISAM e InnoDB). Además, toda la base de datos parece estar bloqueada al hacer estas consultas grandes, no puedo hacer consultas adicionales en paralelo. Curiosamente, htop muestra que el núcleo utilizado para la consulta cambia durante el tiempo de ejecución de la consulta.

¿Por qué pasó esto?

Esta es la entrada relevante de SHOW FULL PROCESSLIST;(no hay otras consultas):

| 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 

No hay otras consultas pendientes. Otra observación interesante es que MySQL responderá esta consulta en un segundo, si omito la ORDER BYparte.

Esto lo que SHOW ENGINE INNODB STATUS;muestra:

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

Puede encontrar esto sorprendente, pero debe establecer innodb_thread_concurrency en 0 (que es concurrencia infinita). Esto permitirá que el motor de almacenamiento de InnoDB decida cuántos tickets de concurrencia se emitirán.

Escribí una publicación sobre el compromiso multinúcleo de InnoDB (MySQL 5.5, también MySQL 5.1.38 InnoDB Plugin) el 26 de mayo de 2011 .

Según la documentación de MySQL, la variable thread_concurrency solo funciona para Solaris .

Tengo una inquietud más: ¿son sus UNIONES involucrando a MyISAM e InnoDB juntos? El comportamiento de bloqueo de la tabla completa de MyISAM anula el bloqueo de nivel de fila de InnoDB y MVCC .

Si no está utilizando MySQL 5.5, actualice lo antes posible para configurar las opciones de participación multinúcleo de InnoDB .

ACTUALIZACIÓN 2012-03-19 08:30 EDT

A partir de MySQL 5.1.38, puede instalar el complemento InnoDB para usar nuevas configuraciones para la interacción multinúcleo. Sin embargo, debe ajustar la configuración correctamente.

De hecho, se dejó sin configurar

• InnoDB para MySQL 4.1 funciona mejor en un entorno de subproceso único que todas las demás versiones de MySQL antes o después
• InnoDB 5.1 Plugin funciona mejor en un solo entorno de CPU que todas las otras versiones de MySQL antes o después
• Escribí una publicación sobre esto en noviembre de 2011: por qué mysql 5.5 es más lento que 5.1 (linux, usando mysqlslap)
• También escribí una publicación en junio de 2011 sobre cómo puede ejecutar su propio Benchmark contra MySQL, Percona Server y MariaDB: ¿Cómo realizo correctamente un horneado de MySQL?
• Todas mis afirmaciones se basan en Percona, que en realidad ejecutó un Benchmark de rendimiento en todas las versiones de MySQL: http://www.mysqlperformanceblog.com/2011/10/10/mysql-versions-shootout/

MySQL, cualquier versión, no tiene ningún código para usar múltiples núcleos en una sola conexión.

Percona hace un mejor trabajo al usar múltiples núcleos a través de múltiples conexiones en su Xtradb. InnoDB se queda sin vapor a unos 8 núcleos; Xtradb se aplana a los 32 aproximadamente.

Una "consulta grande" podría estar bloqueando la tabla (o filas de la tabla) que necesita alguna otra conexión. Miremos la consulta y la MOSTRAR CREAR TABLA.