Використання декількох ядер для одиночних запитів MySQL на Debian


10

Я запускаю сервер MySQL для тестів на VM (VMWare) з Debian як гостьовою ОС. У гостя є чотири емульованих ядра CPU, тому я встановив nit_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 .

У мене є ще одна стурбованість: чи ваші ПРИЄДНАННЯ включають MyISAM та InnoDB разом? Поведінка блокування повної таблиці MyISAM зводить нанівець блокування InnoDB на рівні рядків та MVCC .

Якщо ви не використовуєте MySQL 5.5, оновіть ASAP, щоб налаштувати багатоядерні варіанти взаємодії InnoDB .

ОНОВЛЕННЯ 2012-03-19 08:30 EDT

Починаючи з MySQL 5.1.38, ви можете встановити модуль InnoDB для використання нових налаштувань для багатоядерної взаємодії. Однак налаштування потрібно правильно налаштувати.

Насправді залишився не налаштованим

  • InnoDB для MySQL 4.1 працює краще в однопотоковому середовищі, ніж усі інші версії MySQL до або після нього
  • InnoDB 5.1 плагін працює краще в одному процесорному середовищі, ніж усі інші версії MySQL до або після нього
  • Я написав повідомлення про це ще в листопаді 2011 року: Чому mysql 5.5 повільніше, ніж 5.1 (Linux, використовуючи mysqlslap)
  • Ще в червні 2011 року я написав публікацію про те, як можна запустити свій власний бенчмарк проти MySQL, Percona Server та MariaDB: Як правильно виконати резервну копію MySQL?
  • Усі мої твердження засновані на Percona, який фактично застосував показник ефективності проти всіх версій MySQL: http://www.mysqlperformanceblog.com/2011/10/10/mysql-versions-shootout/

Дуже дякую. Чи відповідає ваша відповідь, що використання декількох ядер не реалізовано у версії 5.1.X?
Томас

Так і ні. Я кажу ТАК, оскільки InnoDB 5.1.x не має багатоядерних налаштувань. Я кажу НЕ, оскільки ви можете встановити InnoDB плагін для цих нових налаштувань, але він доступний лише для MySQL 5.1.38 і вище.
RolandoMySQLDBA

@RolandoMySQLDBA: Вибачте, я знаю, що ця публікація стара, але я виявив, що на моєму сервері mysql (який має 24 ядра) використовується лише 1 ядро. Я перевірив, innodb_thread_cuncurrencyяк ви mentiones, і він встановлений на 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 або більше.

"Великий запит" може блокувати таблицю (або рядки таблиці), яка потрібна деяким іншим з'єднанням. Давайте подивимось на запит і ПОКАЖИТИ СТВОРИТИ ТАБЛИЦЮ.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.