MySQL Çoğaltma Performansı


15

MySQL 5.5 çoğaltma performansı ile iki makine, çoğunlukla deyim tabanlı çoğaltma ile myISAM tabloları arasında ciddi bir sorun yaşıyorum. İkili günlükler ve mysql veri dizininin her ikisi de aynı Fusion ioDrive'da bulunur.

Çoğaltmayı yaklaşık olarak duraklatmamız gerektiğinde sorun son zamanlarda büyük bir sorundu. 3 saat. Başka bir yük olmadan tekrar yakalamak yaklaşık 10 saat sürdü.

Yetişmek için 10 saat

Çoğaltmanın performansını nasıl artırabilirim? Sadece 1 mySQL iş parçacığı veri yazarken, B makinesi temelde boştadır (küçük, IO, 16 üzerinden maksimum 2 çekirdek, çok fazla RAM). İşte sahip olduğum bazı fikirler:

  • Satır tabanlı çoğaltmaya geçin. Testlerde bu sadece% 10-20 performans artışı sağladı
  • Çok iş parçacıklı çoğaltma ile mySQL 5.6 sürümüne geçin. Verilerimizi kolayca ayrı veritabanlarına bölebiliriz ve karşılaştırmalar bunun yardımcı olacağını gösteriyor, ancak kod üretime hazır görünmüyor.
  • Çoğaltmayı hızlandırmaya yardımcı olacak bazı yapılandırma değişkenleri

Birincil sorun, 3 saat durakladıktan sonra yakalamak için 10 saat gerekiyorsa, çoğaltmanın 10 saat içinde 13 saat veri yazdığı veya gelen veri hızının% 130'unda yazabileceği anlamına gelir. Master makineye yakın gelecekte en az iki kez yazar, bu yüzden umutsuzca çoğaltma performansını iyileştirmek için bir yola ihtiyaç duyar.

Makine A:

  • Usta
  • 24GB RAM
  • 1.2 TB Fusion ioDrive2
  • 2x E5620
  • Gigabit ara bağlantısı

my.cnf:

[mysqld]
server-id=71
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp

log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306

log-bin=/data_fio/mysqlbinlog/mysql-bin.log
binlog-format=STATEMENT
replicate-ignore-db=mysql

log-slave-updates = true

# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000

# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32

user=mysql

symbolic-links=0

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysql]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

Makine B:

  • Köle
  • 36GB RAM
  • 1.2 TB Fusion ioDrive2
  • 2x E5620
  • Gigabit ara bağlantısı

my.cnf:

[mysqld]
server-id=72
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp

log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306

# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000

# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32

user=mysql

symbolic-links=0

plugin-load=archive=ha_archive.so;blackhole=ha_blackhole.so

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysql]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

B makinesi temelde boşta . Bu benim MySQL 5.1 çoğaltma deneyimimdir. Çoğaltma tek iş parçacıklıdır ve diğerleri boşta otururken bir CPU en üst düzeye çıkarılır.
Stefan Lasiewski

köle dışında yedekleme yapıyor musun?
Mike

@ stefan-lasiewski Açıkça söylemek gerekirse, bu MySQL 5.5, ama evet. Tek iş parçacıklı ve çok sinir bozucu
Nick

@Mike Evet, ayrıca gün boyunca dakikalar süren yoğun sorgular. Çoğaltma ~ 100s kadar yavaşlar ve sonra yeniden yakalamak biraz zaman alır. Bu sorguları çalıştıran hizmet bir sorgu çalıştırır, yakalamak için bekler, sonra başka bir çalıştır, bekle, vb ... Çoğaltmayı hızlandırabilirsek, bu sorguları çalıştırma sıklığımızı artırabiliriz
Nick

1
@ stefan-lasiewski Evet - Eğer hiçbir şey kopyalamayı durdurmazsa, açıkça geride kalmaz. Birincil sorun, çoğaltma hızının master üzerinde artan yazmaların bir darboğazı olmasıdır. 1s yakalamak için 3.3s alır, bu çoğaltma 3.3s veri 4.3s yazma, ya da sadece gelen veri hızının% 130% çoğaltmak anlamına gelir. En azından çift yazma bu sunucuya yükleyin.
Nick

Yanıtlar:


4

Vay be, bu sorun için korkunç bir donanım var. Btree aramalarında% 20-50 daha iyi performans için belki Sandy / Ivy Bridge CPU'lara yükseltme haricinde donanım akıllıca atabileceğiniz daha fazla bir şey yok.

Forte'mın Innodb olduğunu lütfen unutmayın.

  1. Myisam olduğunuzu görmezden gelin ve fark etmeyecekmiş gibi davranın.
  2. Bu sorunun, yükseltmeniz için yeterli hız olduğunu varsayalım. Evet, bir yükseltmedir.

Innodb, bu sık erişilen satırları arabellek havuzunda depolayarak tüm bu bellekten büyük ölçüde yararlanmanıza yardımcı olabilir. İstediğiniz kadar büyük olarak ayarlayabilirsiniz (örneğin, belleğin% 80'i) ve en son erişilen veriler için daha fazla yer açmak için yeni okuma / yazma işlemleri diskte kalması gerekene kadar bellekte kalır . Bellekte FusionIO'larınızdan daha hızlı bir büyüklük sırasıdır.

Çevrenize bir nimet olabilecek uyarlanabilir karmalar, otomatik inc kilitleme mekanizmaları vb. Gibi daha birçok Innodb özelliği vardır. Ancak verilerinizi benden daha iyi biliyorsunuz.

Innodb dünyasında, kölenizi optimize etmek için iyi bir kısa vadeli çözüm - köle üzerinde efendinizde bulunan her dizine gerçekten ihtiyacınız var mı? Endeksleri, insert / update / siler üzerinde bir top ve zincir vardır BİLE Fusion IO kartları ile. IOPS burada her şey değildir. Sandy / Ivy köprü procsları çok daha iyi bellek verimi ve bilgi işlem performansına sahiptir - şu anda sahip olduğunuz Westmeres'de büyük bir fark yaratabilirler. (Şekil% 20-50 genel). Slave'de ihtiyacınız olmayan tüm dizinleri kaldırın !

İkincisi ve neredeyse kesinlikle sadece innodb için geçerlidir, mk-prefetch hangi güncellemeleri ve köle bunları yazmadan önce bilebilir. Bu, mk-prefetch'in önce bir okuma sorgusu çalıştırmasına izin verir, böylece tek repl, yazma sorgusunu çalıştırdığı zaman verileri bellekte olmaya zorlar. Bu, verilerin hızlı bir büyüklük performans kazancı sırası olan fusionIO'da değil bellekte olduğu anlamına gelir. Bu, BÜYÜK bir fark yaratır, birden fazla beklenebilir. Birçok şirket bunu kalıcı bir çözüm olarak kullanmaktadır. Percona Toolkit'e göz atarak daha fazlasını öğrenin .

Üçüncüsü ve en önemlisi, bir kez Innodb'e geçtiğinizde Tokutek'e mutlaka göz atın. Bu adamlar, Innodb'un yazma / güncelleme / silme performansını uzun bir atışla aşan bazı müthiş şeyler var. Temel avantajlardan biri olarak çoğaltma hızını geliştirdiler ve Fusions crazy IOPS'un neden Btrees durumunda hala size yardımcı olmayacağını kıyaslamalarından görebilirsiniz . (Not: Benim tarafımdan bağımsız olarak doğrulanmadı.) Onlar btree indeksinin yerini tutamayan bir şekilde kullanırlar;

Tokutek'i evlat edinmeyi düşünmek üzereyim. Yazma hızını çok fazla serbest bırakırlarsa, daha fazla dizin eklememe izin verir. Verileri ve indeksleri bu kadar harika oranlarda (alıntı yaptıkları 25x) sıkıştırdıklarından, artırılmış veriler için (performans, bakım) fiyat bile ödemezsiniz. Motorları için ($), önceden sıkıştırılmış GB, IIRC başına 2500 $ / yıl ödersiniz. Verilerin çoğaltılması durumunda indirim yaparlar, ancak Tokutek'i kölenize yükleyebilir ve efendinizi olduğu gibi tutabilirsiniz. MIT Algoritms Açık Eğitim Yazılımı dersindeki teknik ayrıntılara göz atın . Alternatif olarak, bloglarında tonlarca teknik içerik ve videoyu izlemek için 1:20 olmayanlar için düzenli beyaz sayfalar var. Bu videonun ayrıca okumaların ne kadar hızlı olduğuna dair Big-O formülü verdiğine inanıyorum. Bende varokumaların daha yavaş olduğunu varsaymak (Her zaman bir ödünleşme vardır!), ama formül benim için ne kadar karmaşık olduğunu ölçmek için çok karmaşık. Bunun kabaca aynı olduğunu iddia ediyorlar, ama matematiği anlamayı tercih ederim (muhtemelen değil!). Bunu keşfetmek benden daha iyi bir durumda olabilirsiniz.

Ps Tokutek'e bağlı değilim, ürünlerini hiç çalıştırmadım ve onlara baktığımı bile bilmiyorlar.

Güncelleme :

Bu sayfada başka sorularınız olduğunu görüyorum ve içeri gireceğimi düşündüm:

İlk olarak, istisnai bir ortamınız yoksa köle ön getirme neredeyse kesinlikle myisam için işe yaramaz. Bunun nedeni, önceden getirmenin yazmak istediğiniz tabloları kilitlemesi veya köle iş parçacığının, önceden getirme arka plan programının ihtiyaç duyduğu tabloyu kilitlemesidir. Tablolarınız çoğaltma için son derece dengeli ise ve farklı tablolar yuvarlak bir şekilde yazılıyorsa, bu işe yarayabilir - ancak bunun çok teorik olduğunu unutmayın. "Yüksek Performanslı Mysql" kitabında "Çoğaltma Sorunları" bölümünde daha fazla bilgi bulunmaktadır.

İkincisi, muhtemelen köleniz 1.0-1.5'lik bir yüke sahiptir, çalışan başka procs veya sorgularınız varsa ancak 1.0 temel çizgisi varsa daha yüksek olabilir. Bu, muhtemelen CPU'ya bağlı olduğunuz anlamına gelir, bu da muhtemelen gemideki FusionIO'nuzdur. Daha önce de bahsettiğim gibi, Sandy / Ivy Bridge biraz daha cazibe verecek, ancak muhtemelen en az gecikmeyle sizi daha zor zamanlardan geçirmeye yetmeyecek. Bu slave üzerindeki yük çoğunlukla salt yazılırsa (yani çok fazla okuma değil), CPU'nuz neredeyse kesinlikle btree ekleme / silme konumlarını hesaplama zamanı harcıyor. Bu, kritik olmayan dizinlerin kaldırılmasıyla ilgili yukarıdaki fikrimi güçlendirmelidir - bunları daha sonra tekrar ekleyebilirsiniz. Hiper iş parçacığını devre dışı bırakmak işe yaramaz, daha fazla CPU düşmanınız değildir. 32GB ram'in üzerine çıktığınızda, 64GB diyelim, ram dağıtımı hakkında endişelenmeniz gerekiyor, ancak o zaman bile semptomlar farklıdır.

Son olarak ve en önemlisi (bu bölümü atlamayın;)), şimdi RBR (Satır tabanlı çoğaltma) çalıştırdığınızı varsayıyorum çünkü geçiş yaparken önemsiz bir performans artışından bahsettiniz. Ancak, burada daha da fazla performans elde etmenin bir yolu olabilir . Mysql bug 53375 , birincil anahtar olmadan çoğaltılan tablolarınız varsa ortaya çıkabilir. Slave temelde birincil anahtardan başka bir şey kullanabilecek kadar akıllı değildir, bu nedenle birisinin olmaması çoğaltma iş parçacığını her güncelleştirme için tam bir tablo taraması yapmaya zorlar. Bir düzeltme, sadece iyi huylu, vekil bir otomatik artırıcı birincil anahtar eklemektir. Bunu sadece tablo büyük olsaydı yapardım (birkaç binlerce binlerce satır veya daha büyük). Bu, elbette, masada başka bir endeks bulundurmanın maliyetidir, bu da CPU'da ödediğiniz fiyatı getirir. Buna karşı çok az teorik argüman olduğuna dikkat edin, çünkü InnoDB yapmazsanız perde arkasına bir tane ekler. Bununla birlikte, hayali olan 53375'e karşı yararlı bir savunma değildir. Tungsten de bu sorunun üstesinden gelebilir, ancak Tungsten'i kullanırken kodlamanızın düz olduğundan emin olmanız gerekir . Onunla son oynadığımda, UTF8 olmayan herhangi bir dizenin çoğaltılması gerektiğinde korkunç bir şekilde ölecekti. Bundan vazgeçtim.


Zaman ayırdığınız için çok teşekkürler! Burada verdiğiniz bilgileri gerçekten takdir ediyorum. InnoDB'ye geçmek, bir süredir düşündüğümüz bir şeydi, çoğunlukla sıra seviyesinde kilitlemenin faydaları için. Bu bana düşünce için yiyecek verir. Tekrar teşekkürler.
Nick

Vay canına, bu ciddi bir şekilde parlak mysql analizi :)
Kevin

4

cevap değil ancak daha fazla esneklik için tungsten çoğaltıcı ve ticari ürünlerini düşünebilirsiniz . darboğaz tek çekirdekli% 100 cpu kullanımı nedir?


Teşekkürler! Bu ilginç bir çözüm, ancak 3. taraf yazılımları MySQL'e takmaktan biraz çekinmem. Dokümanlarda "Gelecekteki MySQL sürümlerini beklemek için yükseltmeye veya test edilmemiş alternatiflere taşınmaya gerek yok" yazıyor, bu yüzden MySQL 5.6'nın destekleyeceği şeye benziyor gibi görünüyor. Tungsten Replicator ile herhangi bir deneyiminiz var mı?
Nick

hayır, sadece saygın mysql ekosistem katkısının onlar için çalıştığını bilin [ datacharmer.blogspot.com ]. darboğaz nasıl olur - sınırlayıcı faktör olan tek çekirdekli bir yük olduğundan emin misiniz?
pQd

Bilgi için teşekkürler. RE: sınırlayıcı faktör, hayır emin değilim. Iostat, Fusion ioDrive'ın <10 MB / s yazma işlemi yaptığını bildirdiği için I / O olduğunu düşünmüyorum. Cihazın çok daha fazlasını yapabileceğinden eminim. Öte yandan, her zaman% 100 oranında sabitlenen 1 ve aralıklı olarak 1 ek çekirdek vardır, diğerleri boşta kalır. Hiper iş parçacığını devre dışı bırakmaya ne dersiniz?
Nick

@Nick - üzgünüm, hiper iş parçacığı hakkında tavsiye edemez. ama deneyin ... ayrıca - mysql şablonları ile munin veya kaktüsler yüklemeyi deneyin ve neler olduğunu daha ayrıntılı olarak inceleyin.
17:00 'de pQd

Continuent milletinden bu gönderiye göz atın : scale-out-blog.blogspot.ca/2011/10/… Alıntı: "Genel olarak, tek iş parçacıklı yerel çoğaltmanın G / Ç sınırında muhtemelen işe yaramayacağını güvenle söyleyebiliriz önokuması SSD'ler ve / veya köle bazı birleşimi gitmeden durum ".
HTTP500

2

Yani köle yedekleri yapıyorsanız .. ve myiasm tabloları kullanıyorsanız .. bozulmaları önlemek için yedekleme yapmak için tabloları kilitliyorsunuz. Böylece yedekleme tamamlanana kadar çoğaltma çalışamaz .. sonra yetişir.


Kesinlikle. Yedekleme veya uzun sorgular için tabloları düzenli olarak kilitleriz, ancak IO iş parçacığı devam ettiğinde sorun çoğaltma hızındadır. Gelen verilerin hızının yalnızca% 130'unda çoğaltıldığını tahmin ediyorum, bu da çoğaltma hızını iyileştiremediğimiz sürece bu kurulumu ne kadar daha fazla ölçeklendirebileceğimizi sınırlıyor. bu mantıklı mı?
Nick
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.