Kullanıcılar mysqldump devam ederken sistemin yavaş çalıştığından şikayet ediyor

MYSQL veritabanı (ibdata1) 73 GB boyutundadır ve INNODB tabloları için Windows 2008 O / S üzerinde ayrılmış bir veritabanı sunucusu olarak çalışacak şekilde yapılandırılmıştır. Yedeklemeyi mysqldump mysqldump --skip-opt --quick --single-transaction --create-options --extended-insert --disable-keys --add-drop-table --complete-insert - set-charset - sıkıştır --log-hata = Proddb0635.err -u kök -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

Proddb0635.sql yedek dosyası, veritabanı sunucusundan ayrı bir sunucuda depolanır. RAM 12 GB'dir. INNODB Arabellek Havuzu boyutu 6 GB'dir. Ek bellek 32 MB. Sorgu Önbellek boyutu 2 GB Net arabellek uzunluğu 16 M Maks. paket boyutu 1 GB.

mysql sürümü 5.0.67'dir.

Yedekleme çalışmadığında kullanıcılar performanstan memnunlar.

Yedekleme çalışırken INNODB Buffer havuzu isabet oranı% 100'e yakın yüksektir. Bekleyen okuma veya bekleyen yazma yok. innodb wait free 0 CPU kullanımı yüksek değil min% 9 - maks. 15 Şu anda Windows Görev Yöneticisi 10GB RAM kullanıldığını gösteriyor. Sorgu Önbelleğini yalnızca 2 GB RAM ile artırmalı mıyım? mysqlld-nt 9,2 GB RAM alıyor ve mysqldump 5 MB RAM alıyor. Alos, döküm dosyasının boyutunun --compress seçeneğinin varlığında veya yokluğunda aynı olduğunu kaydetti.

İNNODB Tampon Havuzu boyutunu küçültebilir miyim?

Teşekkürler

Windows'ta büyük bir dosyayı başka bir sunucuya ittiğinizde, belleğin kullanıcı işlemleri yerine Sistem önbelleğine tahsis edilmesiyle sonuçlandığı bilinen bir sorun var. Sistem önbelleğine ne kadar bellek ayrıldığını görmek için görev yöneticisinin Fiziksel Bellek (MB) bölümüne bakabilirsiniz.

Bu, yerel bir diske yedekleme yapılarak ve ardından uzak makinenin bu dosyayı çekmesini sağlayarak çözülebilir.

Koşullarınız göz önüne alındığında mysqldump performansını iyileştirme hakkında bazı düşüncelerim var. İşte emriniz:

mysqldump --skip-opt --quick - tek işlem --create-options --extended-insert --disable-keys - add-drop-table --complete-insert --set-karakter kümesi - sıkıştır - -log-error = Proddb0635.err -u kök -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

Fark ettiğim ilk şey, çıktıyı bir dosya sistemine yönlendiriyor olmanızdır. 'DevNas' yazıyor, bu yüzden bunun Ağa Bağlı Depolama olduğunu varsayacağım . Yedeklemeler için NAS hayranıyım, ancak üretim trafiğinden ayrı bir fiziksel NIC'ye bağlı olması gerekiyor . Bant genişliğini doyurmayabilir, ancak yine de rekabet ederler. Bu, --quick bayrağı nedeniyle daha fazla sorun yaratacaktır, çünkü bellekte tutmak yerine her satırı temizler.

Gördüğüm bir sonraki şey, çağırdığın - sıkıştır. -H anahtarını kullanmadığınız için yerel olarak mysql çalıştırdığınız anlaşılıyor. Bu, bu bağlamda gereksiz olan yerel CPU'yu kullanabilir. - sıkıştırma gerekli mi? Dosya içeriklerini değil, yalnızca mysqldump istemcisi ile mysql sunucusu arasındaki verileri sıkıştırır.

Sonra --single-işlem bayrağını kullandığınızı görüyorum. Bu, mysqldump'ın bir parçası olarak her seçimde test ettiği için ekstra CPU'ya neden olacak.

Bunun performansla ilgisi yoktur, ancak yalnızca MyISAM ( manuel ) üzerinde çalışan --disable anahtarlarını kullanırsınız .

Mysqldump'ı çevrimdışı bir ana bilgisayardan uzaktan çalıştırmayı ve tamamlandıktan sonra döküm işleminin NAS'a taşınmasını denemek isteyebilirsiniz , bu işlemin mümkün olduğunca çoğunu banttan çıkarmak.

GÖZLEM # 1

İşte InnoDB'ye karşı bir mysqldump gerçekleştirirken akılda tutulması gereken bir şey.

InnoDB Arabellek Havuzu'ndaki kirli sayfalar önce diske akıtılmalıdır. Bir mysqldump, içinde hala kirli sayfalar bulunan bir InnoDB tablosunun temizlenmesini tetikler.

İnnodb_max_dirty_pages_pct adlı bir sunucu seçeneği var . Varsayılan değer 75'tir ve MySQL'in 5.5'ten önceki sürümlerinde MySQL 5.5 ve 90'dır. Bir üretim ortamında bu sayıyı varsayılan değerde bırakmak sorun değildir.

InnoDB Arabellek Havuzunda çok fazla kirli sayfanız olup olmadığını görmek için şunu çalıştırın:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty';

BTW bir sayfa 16K şovdan:

SHOW GLOBAL STATUS LIKE 'Innodb_page_size';

InnoDB ve mysqldump söz konusu olduğunda, bu sayıyı iki koşulda düşürebilirsiniz.

DAĞITIM 1: Kalıcı olarak 0'a ayarlayın

Bunu my.ini dosyasına ekleyin:

[mysqld]
innodb_max_dirty_pages_pct=0

Bu InnoDB Tampon Havuzu zayıf ve ortalama tutacaktır. Boşaltılan InnoDB tablosunu temizleme adımı hızlı olacaktır, çünkü mysqldump üzerinde işlem yapmadan önce mümkün olduğunca birkaç kirli sayfanın (belki 0) temizlenmesi gerekir.

Tek dezavantajı, yüksek trafik alan bir DB'den mysqldump ise, kirli sayfayı daha sık dışarı atması nedeniyle yazma G / Ç'sinde daha küçük bir artış olabilir. Bunu çalıştırarak restartnig mysql olmadan böyle olup olmadığını belirleyebilirsiniz:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Ayarı 12-24 saat boyunca bırakın, yazma performansı kabul edilebilirse, gitmeye hazırsınız. Değilse, aşağıdakilerle ayarlayın:

SET GLOBAL innodb_max_dirty_pages_pct = 90;

DAĞITIM 2: Mysqldump'tan yaklaşık 1 saat önce 0 olarak ayarlayın

SET GLOBAL innodb_max_dirty_pages_pct = 0;

MySQLDump'ı çalıştırın

SET GLOBAL innodb_max_dirty_pages_pct = 90;

GÖZLEM # 2

Bir mysqldump seçeneği olarak --complete-insert'e sahipsiniz . Bu, VALUES deyiminden önce her INSERT aşamasına sütun adlarını gömer. --Extended-insert ile bile, eklenen her satır grubunda sütun adları mysqldump'a gönderilir. Mysqldump'a gönderilen -tecomplet-insert'i kaldırarak bayt miktarını azaltabilirsiniz.

ÖNERİ

Slave olarak ayarlanabilecek başka bir Windows Server'ınız varsa, mysqldumps üretim makinesinden değil, o slave'den yapın.