MySQL'in birden fazla çekirdek kullanması mümkün mü?

Asla tek bir çekirdekten fazlasını kullanmayan bazı özel MySQL sunucularına sunuldum. MySQL için DBA'dan daha geliştiriciyim, bu nedenle yardıma ihtiyacım var

Kurmak

Sunucular bir OLAP / DataWarehouse (DW) tipi yük ile oldukça ağır:

• Birincil: 96 GB RAM, 8 çekirdek + tek RAID 10 dizi
• Test: 4 çekirdekli 32GB RAM
• En büyük DB 540 GB, toplam ise 1,1 TB ve çoğunlukla InnoDB masalarıdır
• Solaris 10 Intel-64
• MySQL 5.5.x

Not: En büyük DB, OLTP DR sunucusundan çoğaltılmıştır ve DW bundan yüklenir. Tam bir DW değil: sadece 6 ay ila 6 hafta arası, bu yüzden OLTP DB'den daha küçük.

Test sunucusundaki gözlemler

• 3 ayrı bağlantı
• her birinin bir eşzamanı vardır (ve farklı) ALTER TABLE...DROP KEY...ADD INDEX
• 3 masa 2,5, 3,8 ve 4,5 milyon sıraya sahiptir.
• CPU kullanımı% 25'e kadar çıkar (bir çekirdek maksimuma çıkarıldı) ve daha yüksek değil
• 3 ALTER 12-25 dakika sürer (en küçüğü tek olan 4.5)

Sorular

1. Birden fazla çekirdeğin kullanılmasına izin vermek için hangi ayar veya yama gereklidir?
   Yani, MySQL neden mevcut tüm çekirdeği kullanmıyor? (diğer RDBMS'ler gibi)
2. Çoğaltmanın sonucu mu?

Diğer notlar

• Bir RDBMS "thread" ve bir OS "thread" arasındaki farkı anlıyorum
• Herhangi bir paralellik biçimi hakkında soru sormuyorum
• InnoDB ve thread için bazı sistem değişkenleri en düşük seviyededir
  (hızlı bir kazanç arayışı içinde)
• Kısa vadede, disk düzenini değiştiremiyorum
• Gerekirse işletim sistemi çimdiklenebilir
• En küçük masadaki tek bir ALTER TABLE, 4.5 dakika sürer (şok edici IMO)

Düzenle 1

• innodb_thread_concurrency her ikisinde de 8 olarak ayarlanmıştır. Evet, yanlış ama MySQL'in çoklu çekirdek kullanmasını sağlamaz
• innodb_buffer_pool_size birincil olarak 80 GB, testte 10 GB'dir (başka bir örnek kapatılır). Bu şimdilik.
• innodb_file_per_table = AÇIK

Düzenle 2

• innodb_flush_log_at_trx_commit = 2
• innodb_use_sys_malloc = AÇIK
• innodb_flush_method O_DIRECT olmalıdır (ancak VARIABLES GÖSTERMEKTEDİR)
• innodb_doublewrite = KAPALI
• Dosya sistemi = ZFS (Ve sysadmin bunu buldu: http://blogs.oracle.com/realneel/entry/mysql_innodb_zfs_best_practices )

Test etmek

• innodb_flush_method, olması gerektiği zaman O_DIRECT olarak görünmüyor
• RolandoMySQLDBA'nın ayarlarını takip edecek

Önemli bir şeyi kaçırdıysam bana bildirin

Şerefe

Güncelleme

RolandoMySQLDBA'nın yanıtındaki değiştirilmiş innodb_flush_method + 3 x thread ayarları
Sonuç:> Testlerde kullanılan 1 çekirdek = pozitif sonuç

Aslında Mayıs 2011'de Percona Live NYC konferansında bir MySQL Uzmanı ile innodb_thread_concurrency'i tartıştım .

Şaşırtıcı bir şey öğrendim: Belgelere rağmen innodb_thread_concurrency, 0'da ( en iyi eşzamanlılık) bırakmak en iyisidir . Bu şekilde, InnoDB innodb_concurrency_ticketsverilen MySQL örneği kurulumunda açılacak en iyi sayıya karar verir .

innodb_thread_concurrency0'a ayarladıktan sonra innodb_read_io_threadsve innodb_write_io_threads(her ikisi de MySQL 5.1.38'den beri) maksimum 64 değerine ayarlayabilirsiniz . Bu, daha fazla çekirdek kullanmalıdır.

MySQL otomatik olarak birden fazla çekirdek kullanacaktır, bu nedenle% 25'lik yükünüz tesadüf ¹ veya Solaris'te olası bir yanlış yapılandırma olabilir. Solaris'i nasıl ayarlayacağınızı biliyormuş gibi davranmayacağım, ama işte solaris'e özgü bazı ayar bilgileri üzerinden geçen bir makale .

InnoDB ayar sayfaları MySQL 5.5 'te elden geçirilmiş, bu yüzden orada bazı iyi bilgiler de var. Gönderen InnoDB'nin disk GÇ ipuçları :

Unix üst aracı veya Windows Görev Yöneticisi, iş yükünüzle CPU kullanım yüzdesinin% 70'ten az olduğunu gösteriyorsa, iş yükünüz büyük olasılıkla diske bağlıdır. Belki de çok fazla işlem taahhüdünde bulunuyorsunuz ya da tampon havuzu çok küçük. Yapımı tampon havuzu daha büyük yardımcı olabilir, ancak fiziksel bellek fazla% 80'ine eşit ayarlamayın.

Kontrol edilecek diğer şeyler:

• Anahtarlama innodb_flush_method O_DIRECT değer testidir. Bu yardımcı olursa, dosya sistemini forcedirectioseçenekle takmanız gerekebilir.

• Değişim innodb_flush_log_at_trx_commit veya 2 (OS kazasında son saniye kaybetme sakıncası yoksa) (Mysql kazasında son saniye kaybetme sakıncası yoksa) 1'den 0'a.

• İnnodb_use_sys_malloc değerini kontrol edin . Bu makale değişken hakkında daha fazla bilgi içermektedir .

  O zamanlar, çok çekirdekli işlemciler için ayarlanmış hiçbir bellek ayırıcı kütüphanesi yoktu. Bu nedenle, InnoDB mem alt sisteminde kendi hafıza ayırıcısını uyguladı. Bu tahsisatçı, darboğaz olabilecek tek bir muteks tarafından korunur.

  Ancak, bölümün sonunda, değişkeni açmanın ne demek olduğu hakkında bazı uyarılar var (varsayılan olarak 5.5'te açıktır).

  InnoDB bellek ayırıcısı devre dışı bırakıldığında, InnoDB'nin innodb_additional_mem_pool_size parametresinin değerini göz ardı edeceğini unutmayın.

• Çoğaltmanın bazı sorunlara neden olması mümkündür. Paralellikle ilgilenmediğinizi, ancak bu çalışma grubunun tanımından anladığınızı fark ediyorum :

  Şu anda, çoğaltma çok çekirdekli makinelerde iyi ölçeklenmiyor. Tekli iş parçacığı iş parçacığı çoğaltma olaylarını tek tek yürütür ve ayrı ana sunucunun işlemcisi tarafından sunulan eşzamanlı çoklu istemci bağlantıları tarafından üretilen bir yükle baş edemez.

Sonuçta, InnoDB gerçekleşen disk tabanlı işlemler nedeniyle veri depolama için en iyi motor olmayabilir. Datawarehouse tablo (larını) Sıkıştırılmış MyISAM olarak değiştirmeyi düşünebilirsiniz .

¹ _{Tesadüf olarak, yükünüzün% 25'in üzerine çıkmasını engelleyen bir darboğaz var, ancak zorunlu olarak tek bir çekirdekli sorun değil.}

Tek bir bağlantı sadece tek bir çekirdek kullanır. (Tamam, InnoDB, bazı giriş / çıkış işlemleri için çekirdekler, dolayısıyla çekirdekler kullanır, ancak bu önemli değildir.)

3 ALTER aldınız, bu yüzden 3 çekirdeğin değerinden fazlasını kullanmıyordunuz.

Ne yazık ki, BÖLÜM bile birden fazla çekirdek kullanmıyor.

Yakın zamana kadar, 4-8 çekirdekten sonra çoklu bağlantılar kopardı. Percona'nın Xtradb'si (MariaDB'ye dahil), birden fazla çekirdeği daha iyi kullanıyor, ancak yine de iş parçacığı başına sadece bir tane kullanıyor. Yaklaşık 32 çekirdekte maksimuma çıkarlar.

IMHO ve tarif edilen kullanım durumunda, asla birden fazla çekirdek kullanmayacaksınız. Bunun nedeni, iş yükünüzün CPU'ya bağlı değil, IO'ya bağlı olmasıdır. 3 bağlantınız yeni bir Dizin oluşturduğundan, her birinin tüm tabloyu diskten okuması gerekir: Dizinleri hesaplamak değil, zaman alan budur.

Darboğazınızın dosya sisteminizin IO performansı olabileceğini göz önünde bulundurun.

@RolandoMySQLDBA tarafından önerilen ayarlara ek olarak , aynı zamanda mysql veri dizinini ( benim için monte edilmiş ) tutan bölümün noatimemontaj ayarlarını da /etc/fstabyaptım ./data01/mysql/dev/sdb1/data01

Varsayılan olarak linux, özellikle veri tabanları gibi yüksek IO uygulamaları için IO performansını olumsuz yönde etkileyen HER ÇOK okuma veya yazma erişim zamanını kaydeder. Bu, hatta bir dosyadan veri okumak bile diske yazmaya yazma anlamına gelir ... WAT!

Bunu devre dışı bırakmak için, istediğiniz montaj noktası için noatimemount seçeneğini /etc/fstabaşağıdaki gibi ekleyin (benim durumumda örnek):

/dev/sdb1  /data01  ext4  defaults,noatime  0  2

Ardından bölümü yeniden yerleştirin:

mount -o,remount /data01

Bu, bu bölümü kullanan uygulamaların okuma / yazma performansını artırmalıdır. AMA ... hiçbir şey tüm verilerinizi bellekte tutmaya kalkar.