En İyi MySQL InnoDB Arabellek Havuzu Eşgörünümü Sayısı


13

Sunucu Özellikleri

  • Toplam sistem RAM'i: 8GB (MySQL + üzerinde MySQL dışında başka şeyler çalıştırıyor, yani MySQL'e adanmamış)
  • CPU Çekirdek Sayısı: 6
  • Yaklaşık 2GB db veri var
  • InnoDB Arabellek Havuzu Boyutu 4GB olarak ayarlandı

Hangisi daha iyi:

  • Innodb Buffer Pool Instances 1 olarak ayarlandı mı?
  • Innodb Buffer Pool Instances 2 olarak ayarlandı (her birinde 2GB)?
  • Innodb Buffer Pool Instances 4'e ayarlı (her birinde 1GB)?
  • Innodb Buffer Pool Örnekleri 8 olarak ayarlandı (varsayılan ayar)

Bu nedenle, buffer Pool Instances ve ayrıca tüm "bu tür büyük InnoDB Buffer Pool Size sahip olduğunda örnekleri kullanın veya OS Swap acı" konusunda neden emin değilim.


"Bu kadar büyük InnoDB Tampon Havuzu Boyutu'nu kullanırken örnekleri kullanın veya OS Swap'a maruz kaldınız"
Rick James

"MySQL dışında başka şeyler" için alan çıkarıldıktan sonra toplam buffer_pool için RAM'in% 70'i , örnek sayısına bakılmaksızın iyi olmalıdır.
Rick James

Hepsini "kalçadan ateş" olarak gördüğüm kadarıyla kabul edilmeye cevap veremem. Herkes merak ederse, ben 4G tampon havuzu boyutu ve 2 örnekleri ile gitti ve yaklaşık 60 sorgu / saniye ortalama mysql çalışan aynı makinede php-fpm + nginx çalışan 8G toplam bellek 8G ile Debian 8.1 üzerinde çok iyi çalışır.
Adergaard

Yanıtlar:


7

MySQL 5.5'e geri döndüğümde, aynı şeyi düşünürdüm.

O yıllar boyunca öğrendiğim şey şuydu: Arabellek Havuzu kurulu RAM'in yarısından büyükse ve innodb_buffer_pool_instances 1 (5.5 için varsayılan) ise, takas tehdidi her zaman yakındı.

Bunu daha önce tartıştım: Bir tampon havuzu örneklerinin boyutu ve sayısı ile ilgili bir kural var mı? . Bu yazıda, 162GB Tampon Havuzlu sunucuda 192GB RAM olan bir istemciden bir örnek verdim. Ne zaman innodb_buffer_pool_instances 1 idi, takas oldu. İnnodb_buffer_pool_instances değerini 2 olarak ayarladığımda , işler daha iyi hale geldi.

Sizin durumunuzda, Tampon Havuzu tam olarak yarım olduğundan, 1 değeri iyi olabilir. Şansım olmazdı. 2 olarak ayarlayacağım.

MySQL 5.6 varsayılan olarak 8 olduğundan, artık bunu düşünmenize gerek yok.

Bunu söyleyeceğim: akuzminsky'nin cevabı en yüksek prensibe sahiptir . Cevabım sadece geçmiş deneyimlere (iyi ve kötü) dayanarak kalçadan ateş etmektir.


Olmaz! Değiştirme, havuz örneklerine değil, ayrılan bellek miktarına bağlıdır.
Rick James

Varsayılanın 8 olduğunu bilmek güzel ... Ama 4'e kesilmiş veya 16'ya yükseltilmişse fark nedir? Herhangi bir hafıza / depolama cezası veya parası var mı? Gerçekten burada olmam tek nedeni, mysqltuner innodb_buffer_pool_instances (= 1) önerir ama her zaman onun önerilerine güvenmiyorum. Verilmiş, problemlerim yok, sadece merak ediyorum.
PJ Brunet

@PJBrunet, InnoDB arabellek havuzu RAM'in yarısından daha azsa, InnoDB arabellek havuzu örnekleri 1'de bırakılabilir.
RolandoMySQLDBA

6

Tampon havuzu muteks çekişmesini önlemek için tampon havuzu örneklerinin sayısı artırılmalıdır.

Tampon havuzu boyutu 8GB ile hiç tampon havuzu mutex çekişme göreceksiniz şüpheliyim.

GÜNCELLEME 0 :

Orijinal soruda toplam bellek 8GB iken cevapta 8GB tampon havuzundan bahsediyorum. Elbette, arabellek havuzu 8 GB'den az olmalıdır. 4GB iyi bir başlangıç ​​gibi geliyor ancak değiştirmenin gerçekleşmediğinden emin olun.

GÜNCELLEME 1 :

// Yasufumi'nin slaytlarından (son MySQL sürümlerinde çıktı biraz farklı olabilir)

Tampon havuzu muteksinde bir çekişme olup olmadığını belirlemek SHOW ENGINE INNODB STATUSiçin pik zaman boyunca bir düzine numune toplayın .

Ardından kabuk snippet'ini kullanarak toplayın:

#!/bin/sh
cat $1.innodb | grep "Mutex at " | cut -d"," -f1 | sort | uniq -c > /tmp/tmp1.txt 
cat $1.innodb | grep "lock on " | cut -d"-"
-f2- | sort | uniq -c > /tmp/tmp2.txt
cat /tmp/tmp1.txt /tmp/tmp2.txt | sort -n > $1.contention rm /tmp/tmp1.txt /tmp/tmp2.txt

bu şekilde çıktı verir:

.....
4 lock on RW-latch at 0x7fb86b2c9138 created in file dict/dict0dict.c line 1356
6 lock on RW-latch at 0x7fb86b2c4138 created in file dict/dict0dict.c line 1356
12 lock on RW-latch at 0x7fb86b2d9538 created in file dict/dict0dict.c line 1356
20 lock on RW-latch at 0x7fb86b2db138 created in file dict/dict0dict.c line 1356
22 Mutex at 0x7fb86b28f0e0 created file btr/btr0sea.c line 139
30 lock on RW-latch at 0x7fb86b2ba938 created in file dict/dict0dict.c line 1356
36 lock on RW-latch at 0x7fb86b2bad38 created in file dict/dict0dict.c line 1356
71 Mutex at 0x7fb86b28ecb8 created file buf/buf0buf.c line 597
164 lock on RW-latch at 0x7fb86b28f0b8 created in file btr/btr0sea.c line 139

Çok sayıda arabellek havuzu muteksi beklediğini görürseniz, birden çok arabellek havuzu örneğini düşünmenin zamanı gelmiştir. Çekişmenin ~ 48G'den daha küçük bir tampon havuzunda gerçekleşmesi olası değildir.


1
Ama yok değil RAM sadece 8GB bir 8G buffer_pool var!
Rick James

Hangi dbsize yani innodb tampon havuzu boyutunda o zaman örnekleri düşünmeye başlarsınız? Cevabınızı bu nispeten küçük seviyelerde birden fazla olmanız için bir neden olmadığı şeklinde yorumluyorum . Doğru? Bu konuda bir kaynağın var mı? MySQL belgeleri "çok gigabayt" diyor ki bu benim için bir şeyleri ifade etmenin çok bulanık bir yoludur. Aslında, 2 GB çok ama sanırım bundan daha büyük bir veri kümesine atıfta bulunuyorlar ...
Adergaard

2

İşletim sisteminizde böyle bir durum varsa "swappiness" değerini 1 olarak ayarlayın. Sorun aşırı agresif bir OOM olabilir.


0

Eşzamanlı olarak çalıştırmak istediğiniz MySQL iş parçacıklarının maksimum sayısına uyacak şekilde ayarlamanız önerilir. Çekirdek sayısını kullanıyorum.

Ben de set innodb_read_io_threadsve innodb_write_io_threadsbu numarayı eşleşecek.

Eğer innodb_buffer_pool_instancesçok düşükse, sizin ipler muhtemeldir semafor bekler takılıyorum. Bu, sistemin meşgul olması gerekse bile hem CPU'nun hem de I / O'nun boşta görünmesini sağlar - ve uygulama gecikmeniz çatıdan geçer.

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.