MySQL iş parçacıkları, sorgu önbelleği devre dışı bırakıldığında neden genellikle "öğeleri serbest bırakıyor" durumunu gösteriyor?

Çalıştırdığımda SHOW PROCESSLIST, "öğeleri serbest bırakma" durumunda çok sayıda INSERT / UPDATE iş parçacığı vardır.

MySQL kılavuzu, bir iş parçacığının bu durumda olmasının nedeninin en azından bir kısmının sorgu önbelleğini içerdiğini - muhtemelen değiştirilen veriler nedeniyle önbelleğe alınmış sorguları geçersiz kılacağını önerir.

Ancak, my query_cache_size0 olarak ayarlanır ve sorgu önbelleğini tamamen devre dışı bırakmalıdır.

Bu durumda çok fazla iş parçacığının olması için başka nedenler olurdu?

İlgili tablolar InnoDB depolama motorunu kullanır.

İnnodb_thread_concurrency değerini kontrol edin.

Sistemim için değeri 8'den 32'ye çıkaran MySql belgelerindeki yönergelere göre , "serbest öğeler" durumunu bildiren iş parçacıklarının sayısında belirgin bir düşüşe neden oldu. Ayrıca, obesrved ortalama sorgu süresi bir büyüklük sırasına göre düştü.

Bu, genel sunucu performansında büyük bir fark yaratsa da, "serbest öğeler" gümüş kurşun değildi. Donanım ekosistemim bu durumun çoğunlukla "yavaş" diskli sistemlerde (2x10k disk baskını 1) görüldüğünü ve daha hızlı depolanan sistemlerde (12x15k disk baskını 10) daha az yaygın olduğunu varsaymamı sağlıyor. Bu nedenle, disk performansının kontrol edilmesi de gerekebilir.

İyi şanslar!

Ayrıca:

Hangi innodb_thread_concurrency varsayılan değerinin kullanılan 5.0 nokta sürümüne bağlı olarak kökten farklı olduğunu belirtmek gerekir.

Varsayılan değer birkaç kez değişti: MySQL 5.0.8 öncesi 8, 20 (sonsuz) 5.0.8'den 5.0.18'e, 0 (sonsuz) 5.0.19'dan 5.0.20'ye ve 8 (sonlu) 5.0.21'den üzerinde. - kaynak

Bu, 5.0.20'den 5.0.21'e zararsız görünen bir yükseltmenin, varsayılanı sonsuzdan 8'e değiştirdiği ve beraberinde performans sonuçları getirdi.

Öğeleri serbest bırakmak, geçici yapıların, arabelleklerin vb. Yerleştirildiği bir sorgu yürütme aşamasıdır. Bazı sorgu önbellek çalışmaları bu aşamada yapılır, ancak orada olan tek şey bu değildir. Bu aşamanın diğer aşamalara göre ne kadar sürdüğünü görmek için GÖSTER PROFİLLERİNİ kullanmanızı öneririm ve tüketilen zaman bir endişe olursa, fakir adamın profilcisi ve oprofile gibi araçlarla sorun giderme.

"Serbest öğeler" ve sorgu önbelleği ile ilgili bir hata raporu vardı . Hata kapalı olmasına rağmen, innodb_thread_concurrency'dan bahsedilmedi .

Buna paralel olarak, Mayıs ayında Percona Live NYC'de Ronald Bradford ile konuştum. Ben ona innodb_thread_concurrency tweeked bir durum anlattım çünkü MySQL 5.5'in çoklu InnoDB Tampon Havuzu bir ton iplik kilitleme üretti ve büyük olasılıkla ihtiyacım olan önbellek veri birden çok tampon havuzları arasında yayılmış olduğundan şüphelendim.

Bana açıkça innodb_thread_concurrency karşısında değer ayarlamamam gerektiğini söyledi. Her zaman sıfır (0) olan varsayılan değer olsun. Bunu yaparak, InnoDB depolama alanının kaç tane innodb_concurrency_tickets üreteceğini kendi belirleyeceğine karar vermiş olursunuz . Sonsuz eşzamanlılık bunu yapar.

'Eşyaları serbest bırakma' büyük olasılıkla innodb_thread_concurrency için sınırlar koyduğumuzda daha sık görülür. Bu her zaman sıfır olmalıdır (0). Bir risk alırdım ve innodb_concurrency_tickets yükseltmek ve yardımcı olup olmadığını görmek.

Aynı belirtilerle ilgili bir sorunumuz vardı. InnoDB günlük dosyalarına sahip diskin dolduğu ortaya çıktı. Kontrol etmeye değer.

Başka bir ipucu: Innodb fsync () olabilir. Ayarlamayı deneyin

innodb_flush_log_at_trx_commit = 2

My.cnf içinde

Daha sonra innodb log dosyası her 1-2 saniyede bir diske temizlenir, bunun yerine her işlemde ob. Veri bütünlüğüne hafif ceza, hızda büyük kazanç.