Menggunakan beberapa inti untuk satu permintaan MySQL di Debian


10

Saya menjalankan server MySQL untuk pengujian pada VM (VMWare) dengan Debian sebagai OS tamu. Tamu memiliki empat inti CPU yang dicontoh, jadi saya mengatur thread_concurrency menjadi empat.

Saya melakukan gabungan mahal di atas meja besar, yang bisa memakan waktu beberapa menit, tetapi saya lihat di OS tamu, bahwa hanya satu inti yang digunakan pada satu waktu. Ini terjadi terlepas dari mesin penyimpanan yang digunakan untuk tabel yang terlibat (diuji dengan MyISAM dan InnoDB). Selain itu, seluruh basis data tampaknya diblokir saat melakukan kueri besar ini, saya tidak bisa melakukan kueri tambahan secara paralel. Anehnya htop menunjukkan, bahwa inti yang digunakan untuk perubahan permintaan selama runtime permintaan!

Mengapa ini terjadi?

Ini adalah entri yang relevan dari SHOW FULL PROCESSLIST;(tidak ada pertanyaan lain):

| 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 

Tidak ada permintaan lain yang tertunda. Pengamatan lain yang menarik adalah, bahwa MySQL akan menjawab pertanyaan ini dalam sedetik, jika saya meninggalkan ORDER BYbagian itu.

Ini yang SHOW ENGINE INNODB STATUS;menunjukkan:

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

Silakan memposting keluaran dari PROSESLUS SHOW FULL (mungkin dibersihkan) dan SHOW ENGINE STATUS INNODB untuk membantu kami mendiagnosis mengapa "seluruh basis data" dikunci.
Aaron Brown

Terima kasih, saya memperbarui pertanyaan dengan informasi yang diminta.
Thomas

1
Jika tidak ada permintaan lain yang berjalan, maka tidak ada bukti bahwa seluruh basis data dikunci. Bisakah Anda mereproduksi kondisi ini dan memposting apa yang terjadi ketika kueri yang berjalan lama tampaknya mengunci yang lain?
Baron Schwartz

Ok, saya periksa ini. Dimungkinkan untuk melakukan kueri lain di konsol mysql, bahkan ketika kueri besar sedang berjalan. Namun, phpmyadmin tidak merespons sama sekali, bahkan untuk upaya login sederhana, saat kueri sedang dieksekusi. Waktu eksekusi itu sendiri seringkali kurang dari 10 detik, tetapi kueri tetap dalam keadaan "mengirim data" selama beberapa menit.
Thomas

Jawaban:


10

Anda mungkin menemukan ini mengejutkan, tetapi Anda harus mengatur Innodb_thread_concurrency ke 0 (yang merupakan konkurensi tak terbatas). Ini akan memungkinkan InnoDB Storage Engine untuk memutuskan berapa banyak tiket konkurensi yang akan diterbitkan.

Saya menulis posting tentang keterlibatan multicore InnoDB (MySQL 5.5, juga MySQL 5.1.38 InnoDB Plugin) kembali pada 26 Mei 2011 .

Menurut Dokumentasi MySQL, variabel thread_concurrency hanya berfungsi untuk Solaris .

Saya memiliki satu keprihatinan lagi: Apakah GABUNGAN Anda melibatkan MyISAM dan InnoDB bersama? Perilaku penguncian tabel penuh MyISAM membatalkan penguncian level-baris dan MVCC InnoDB .

Jika Anda tidak menggunakan MySQL 5.5, tingkatkan ASAP untuk menyiapkan opsi keterlibatan multicore InnoDB .

UPDATE 2012-03-19 08:30 EDT

Dimulai dengan MySQL 5.1.38, Anda dapat menginstal Plugin InnoDB untuk menggunakan pengaturan baru untuk keterlibatan multicore. Namun, Anda harus menyetel pengaturan dengan benar.

Bahkan, dibiarkan tidak terkonfigurasi


Terima kasih banyak. Apakah jawaban Anda menyiratkan, bahwa menggunakan banyak core tidak diimplementasikan dalam versi 5.1.X?
Thomas

Iya dan tidak. Saya katakan YA karena InnoDB 5.1.x tidak memiliki pengaturan multicore. Saya katakan TIDAK karena Anda dapat menginstal Plugin InnoDB untuk pengaturan baru ini, tetapi hanya tersedia untuk MySQL 5.1.38 dan di atasnya.
RolandoMySQLDBA

@RolandoMySQLDBA: Maaf, saya tahu posting ini sudah tua, tetapi saya menemukan bahwa mysql di server saya (yang memiliki 24 core) hanya menggunakan 1 core. Saya memeriksa innodb_thread_cuncurrencyketika Anda menyebutkan dan diatur ke 0, jadi saya bertanya-tanya mengapa mysql tidak menggunakan lebih banyak core?
monamona

1
@monamona Itu bukan satu-satunya pengaturan untuk bermain. Anda juga harus menetapkan innodb_read_io_threads dan innodb_write_io_threads lebih tinggi (Coba 8, 16, 32, dan 64).
RolandoMySQLDBA

@monamona Silakan baca posting lama saya dba.stackexchange.com/questions/2918/... untuk lebih jelasnya
RolandoMySQLDBA

2

MySQL, versi apa pun, tidak memiliki kode apa pun untuk menggunakan banyak inti dalam satu koneksi.

Percona melakukan pekerjaan yang lebih baik dalam menggunakan beberapa core di beberapa koneksi di Xtradb-nya. InnoDB kehabisan uap sekitar 8 core; Xtradb rata pada 32 atau lebih.

"Permintaan besar" dapat mengunci tabel (atau baris tabel) yang dibutuhkan oleh beberapa koneksi lain. Mari kita lihat query dan SHOW CREATE TABLE.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.