Использование нескольких ядер для отдельных запросов MySQL в Debian


10

Я использую сервер 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
============================

Пожалуйста, опубликуйте выходные данные SHOW FULL PROCESSLIST (возможно, санированные) и SHOW ENGINE INNODB STATUS, чтобы помочь нам диагностировать, почему «вся база данных» заблокирована.
Аарон Браун

Спасибо, я обновил вопрос запрошенной информацией.
Томас

1
Если другие запросы не выполняются, то нет никаких доказательств того, что вся база данных заблокирована. Можете ли вы воспроизвести это условие и сообщить, что происходит, когда длительный запрос явно блокирует других?
Барон Шварц

Хорошо, я проверил это. Можно выполнять другие запросы в консоли mysql, даже когда выполняется большой запрос. Однако phpmyadmin вообще не отвечает даже на простые попытки входа в систему, пока выполняется запрос. Само время выполнения часто составляет менее 10 секунд, но запрос остается в состоянии «отправки данных» в течение нескольких минут.
Томас

Ответы:


10

Это может показаться удивительным, но вы должны установить 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, чтобы использовать новые настройки для многоядерного взаимодействия. Тем не менее, вы должны настроить параметры правильно.

На самом деле, остался ненастроенным


Большое спасибо. Ваш ответ подразумевает, что использование нескольких ядер не реализовано в версии 5.1.X?
Томас

Да и нет. Я говорю ДА, потому что InnoDB 5.1.x не имеет многоядерных настроек. Я говорю НЕТ, потому что вы можете установить плагин InnoDB для этих новых настроек, но он доступен только для MySQL 5.1.38 и выше.
RolandoMySQLDBA

@RolandoMySQLDBA: Извините, я знаю, что этот пост старый, но я обнаружил, что mysql на моем сервере (который имеет 24 ядра) использует только 1 ядро. Я проверил, innodb_thread_cuncurrencyкак вы упоминаете, и он установлен в 0, поэтому мне было интересно, почему MySQL не использует больше ядер?
Монамона

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 или около того.

«Большой запрос» может блокировать таблицу (или строки таблицы), в которой нуждается какое-то другое соединение. Давайте посмотрим на запрос и ПОКАЗАТЬ CREATE TABLE.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.