Debian'da tek MySQL sorguları için birden çok çekirdek kullanma


10

Konuk işletim sistemi olarak Debian ile bir VM (VMWare) üzerinde testler için bir MySQL sunucusu çalıştırıyorum. Konuk dört taklit CPU çekirdeği vardır, bu yüzden dört thread_concurrency ayarlayın.

Birkaç dakika sürebilen büyük masalarda pahalı eklemeler yapıyorum, ancak konuk işletim sisteminde, bir seferde sadece bir çekirdeğin kullanıldığını görüyorum. Bu, ilgili tablolar için kullanılan depolama motoruna bakılmaksızın gerçekleşir (MyISAM ve InnoDB ile test edilmiştir). Ayrıca, tüm veritabanı bu büyük sorguları yaparken engellenmiş gibi görünüyor, paralel olarak herhangi bir ek sorgu yapamam. Garip bir şekilde htop, sorgu için kullanılan çekirdeğin, sorgunun çalışma süresi boyunca değiştiğini gösterir!

Bu neden oluyor?

Bu, ilgili giriştir SHOW FULL PROCESSLIST;(başka sorgu yoktur):

| 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 

Bekleyen başka sorgu yok. Bir başka ilginç gözlem ise, ORDER BYparçayı dışarıda bırakırsam MySQL'in bir saniye içinde bu sorguyu yanıtlayacağıdır .

Bu ne SHOW ENGINE INNODB STATUS;gösterir:

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

"Tüm veritabanının" neden kilitlendiğini teşhis etmemize yardımcı olmak için lütfen TAM İŞLEMCİ GÖSTER (muhtemelen dezenfekte edilmiş) ve MOTOR INNODB DURUMUNU GÖSTER komutunun çıktısını gönderin.
Aaron Brown

Teşekkürler, soruyu istenen bilgilerle güncelledim.
Thomas

1
Çalışan başka sorgu yoksa, tüm veritabanının kilitlendiğine dair bir kanıt yoktur. Bu koşulu yeniden oluşturabilir ve uzun süren sorgu görünüşte başkalarını kilitliyorsa ne olacağını gönderebilir misiniz?
Baron Schwartz

Tamam, bunu kontrol ettim. Büyük sorgu çalışırken bile mysql konsolunda başka sorgular yapmak mümkündür. Ancak, phpmyadmin, sorgu yürütülürken basit giriş denemelerine bile hiç yanıt vermiyor. Yürütme süresi genellikle 10 saniyeden azdır, ancak sorgu birkaç dakika boyunca "veri gönderme" durumunda kalır.
Thomas

Yanıtlar:


10

Bunu şaşırtıcı bulabilirsiniz, ancak innodb_thread_concurrency değerini 0 (sonsuz eşzamanlılık) olarak ayarlamanız gerekir. Bu, InnoDB Depolama Motorunun kaç tane eşzamanlı bilet düzenleyeceğine karar vermesini sağlayacaktır.

26 Mayıs 2011 tarihinde InnoDB'nin çok çekirdekli katılımı (MySQL 5.5, ayrıca MySQL 5.1.38 InnoDB Eklentisi) hakkında bir yazı yazdım .

MySQL Belgelerine göre, thread_concurrency değişkeni yalnızca Solaris için çalışır .

Bir endişem daha var: JOIN'leriniz MyISAM ve InnoDB ile ilgili mi? MyISAM'ın tam tablo kilitleme davranışı, InnoDB'nin satır düzeyinde kilitleme ve MVCC'yi geçersiz kılar .

MySQL 5.5 kullanmıyorsanız, InnoDB'nin çok çekirdekli katılım seçeneklerini ayarlamak için lütfen ASAP'ı yükseltin .

GÜNCELLEME 2012-03-19 08:30 EDT

MySQL 5.1.38 ile başlayarak, çok çekili katılım için yeni ayarları kullanmak üzere InnoDB Eklentisini kurabilirsiniz. Ancak, ayarları doğru şekilde yapmanız gerekir.

Aslında, yapılandırılmamış bıraktı


Çok teşekkür ederim. Cevabınız, 5.1.X sürümünde birden çok çekirdeğin kullanılmadığı anlamına mı geliyor?
Thomas

Evet ve hayır. Diyorum ki EVET InnoDB 5.1.x'in çok çekirdekli ayarları yok. Bu yeni ayarlar için InnoDB Eklentisini kurabileceğiniz için HAYIR diyorum, ancak yalnızca MySQL 5.1.38 ve üstü için kullanılabilir.
RolandoMySQLDBA

@RolandoMySQLDBA: Üzgünüm, bu yazının eski olduğunu biliyorum, ancak sunucumdaki (24 çekirdeğe sahip) mysql'nin sadece 1 çekirdek kullandığını buldum. innodb_thread_cuncurrencyBahsettiğin gibi kontrol ettim ve 0'a ayarlandı, bu yüzden mysql neden daha fazla çekirdek kullanmadığını merak ediyordum?
monamona

1
@monamona Oynamak için tek ayar bu değil. Ayrıca innodb_read_io_threads ve innodb_write_io_threads değerini daha yüksek ayarlamanız gerekir (8, 16, 32 ve 64'ü deneyin).
RolandoMySQLDBA

@monamona benim eski sonrası okuyunuz dba.stackexchange.com/questions/2918/... fazla detay için
RolandoMySQLDBA

2

MySQL, herhangi bir versiyonda, tek bir çekirdekte birden fazla çekirdek kullanmak için herhangi bir kod yok bağlantıda .

Percona, Xtradb'sindeki birden çok bağlantıda birden çok çekirdek kullanma konusunda daha iyi bir iş çıkarıyor. InnoDB buhar yaklaşık 8 çekirdekte biter; Xtradb 32'de düzleşir.

"Büyük bir sorgu" diğer bazı bağlantıların gerektirdiği tabloyu (veya tablo satırlarını) kilitliyor olabilir. Sorguya ve GÖSTER TABLOSUNA bakalım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.