Я использую сервер MySQL для тестирования на ВМ (VMWare) с Debian в качестве гостевой ОС. Гость имеет четыре эмулируемых ядра процессора, поэтому я установил для 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
============================
Ответы:
Это может показаться удивительным, но вы должны установить innodb_thread_concurrency в 0 (это бесконечный параллелизм). Это позволит InnoDB Storage Engine решить, сколько билетов параллелизма выпустить.
Я написал пост о многоядерном взаимодействии InnoDB (MySQL 5.5, также MySQL 5.1.38 InnoDB Plugin) еще 26 мая 2011 года .
Согласно документации MySQL, переменная thread_concurrency работает только для Solaris .
У меня есть еще одна проблема: участвуют ли ваши JOINS в MyISAM и InnoDB вместе? Поведение блокировки полной таблицы MyISAM сводит на нет блокировку на уровне строк InnoDB и MVCC .
Если вы не используете MySQL 5.5, обновите как можно скорее, чтобы настроить параметры многоядерного взаимодействия InnoDB .
ОБНОВЛЕНИЕ 2012-03-19 08:30 ПО ВОСТОЧНОМУ ВРЕМЕНИ
Начиная с MySQL 5.1.38, вы можете установить плагин InnoDB, чтобы использовать новые настройки для многоядерного взаимодействия. Тем не менее, вы должны настроить параметры правильно.
На самом деле, остался ненастроенным
источник
innodb_thread_cuncurrencyкак вы упоминаете, и он установлен в 0, поэтому мне было интересно, почему MySQL не использует больше ядер?MySQL любой версии не имеет кода для использования нескольких ядер в одном соединении.
Percona лучше использует несколько ядер в нескольких соединениях в своем Xtradb. InnoDB работает на 8 ядрах; Xtradb выравнивается на 32 или около того.
«Большой запрос» может блокировать таблицу (или строки таблицы), в которой нуждается какое-то другое соединение. Давайте посмотрим на запрос и ПОКАЗАТЬ CREATE TABLE.
источник