Sık sorulan sorgu önbellek geçersiz kılma ek yükü buna değdi mi?


22

Şu anda, özellikle birçok tablonun üzerinde yürütülen yüksek sayıda INSERT, DELETE ve UPDATE ifadesi nedeniyle, sorgu önbellekten çok sayıda geçersizlik gördüğümüz bir MySQL veritabanı üzerinde çalışıyorum.

Belirlemeye çalıştığım şey, sorgu önbelleğinin bu tablolara karşı çalıştırılan SELECT ifadeleri için kullanılmasına izin vermenin hiçbir yararı olup olmadığıdır. Çok hızlı bir şekilde geçersiz hale geldiklerinden, bana öyle geliyor ki, en iyi şey, bu tablolarla SELECT ifadelerinde sadece SQL_NO_CACHE kullanmak olacaktır.

Sık sık geçersiz kılınan yükler buna değdi mi?

Düzenleme: Aşağıdaki @RolandoMySQLDBA kullanıcısının isteği üzerine, işte MyISAM ve INNODB.

InnoDB'nin

  • Veri Boyutu: 177.414 GB
  • Dizin Boyutu: 114,792 GB
  • Tablo Boyutu: 292.205 GB

MyISAM

  • Veri Boyutu: 379.762 GB
  • Dizin Boyutu: 80.681 GB
  • Tablo Boyutu: 460.443 GB

İlave bilgi:

  • Sürüm: 5.0.85
  • query_cache_limit: 1048576
  • query_cache_min_res_unit: 4096
  • query_cache_size: 104857600
  • query_cache_type: ON
  • query_cache_wlock_invalidate: OFF
  • innodb_buffer_pool_size: 8841592832
  • 24GB RAM

2
dom.as/tech/query-cache-tuner oldukça hoş bir şekilde özetliyor
Laurynas Biveinis

Hehe, çok anlayışlı.
Craig Sefton

Yanıtlar:


16

Sorgu önbelleğini yalnızca devre dışı bırakmalısınız

[mysqld]
query_cache_size = 0

ve sonra MySQL'i yeniden başlatın. Bunu neden önereyim ki ???

Sorgu Önbelleği her zaman InnoDB'ye işaret eder. Değişiklikler diğer işlemler için tekrarlanabilir okumaları etkilemezse, InnoDB'nin MVCC'sinin sorgu önbellekten sorguların sunulmasına izin vermesi iyi olurdu. Ne yazık ki, InnoDB sadece bunu yapmaz. Görünüşe göre, hızlı bir şekilde geçersiz kılınan ve muhtemelen tekrar kullanılmayan çok sayıda sorunuz var.

MySQL 4.0 altındaki InnoDB için, sorgu önbelleği işlemler için devre dışı bırakıldı. MySQL 4.1+ için InnoDB, sorgu önbelleğine tablo başına erişime izin verirken trafik polisi oynatır.

Sorunuzun perspektifinden bakıldığında, sorgu önbelleğini kaldırmanın gerekçesinin fazla değil, InnoDB'nin bunu nasıl yönettiğini söyleyebilirim.

InnoDB'nin sorgu önbelleği ile nasıl etkileşime girdiği hakkında daha fazla bilgi için, lütfen "Yüksek Performanslı MySQL (İkinci Sürüm)" kitabının 213-215. Sayfalarını okuyun. .

Verilerinizin tamamı veya çoğunluğu MyISAM ise, SQL_NO_CACHE kullanma orijinal fikrinizle devam edebilirsiniz.

Bir InnoDB ve MyISAM karışımınız varsa, önbellek özlemlerinizin ne kadar yüksek olduğuna bağlı olarak uygulamanız için doğru dengeyi bulmanız gerekecektir. Aslında, aynı kitabın 209-210. Sayfaları önbellek kayıplarının sebeplerine işaret ediyor:

  • Sorgu önbelleklenebilir değildir, çünkü özgün özellikli bir yapı içermez (CURRENT_DATE gibi) veya sonuç kümesi depolanamayacak kadar büyük olduğu için.
  • Sunucu sorguyu daha önce hiç görmemiş, bu nedenle sonuçlarını önbelleğe alma şansı hiç olmamıştı.
  • Sorgunun sonucu daha önce önbelleğe alındı, ancak sunucu tarafından kaldırıldı. Bu, saklamak için yeterli bellek olmadığı için, birileri sunucuya onu kaldırması için talimat verdiği veya geçersiz olduğu için olabilir.

ve önbelleğe alınamayan çok az sayıda sorgu ile yüksek önbellekleme özlemlerinin temel nedenleri şunlar olabilir:

  • Sorgu önbelleği henüz sıcak değil. Bu, sunucunun önbelleği sonuç kümeleriyle doldurma şansının olmadığıdır.
  • Sunucu daha önce görmediği sorguları görüyor. Çok fazla tekrarlanan sorunuz yoksa, bu önbellek ısındıktan sonra bile olabilir.
  • Çok fazla önbellek geçersizliği var.

GÜNCELLEME 2012-09-06 10:10 EDT

En son güncel bilgilerinize bakarken, query_cache_limit1048576 (1M) olarak ayarladınız. Bu, 1M olarak ayarlanmış herhangi bir sonucu sınırlar. Daha büyük bir şey alırsanız, önbelleğe alınmaz. Sahipkenquery_cache_size104857600 (100M) olarak ayarlanmış , bu yalnızca mükemmel bir dünyada ayarlanmış 100 önbelleğe alınmış sonuç için izin verir. Yüzlerce sorgu gerçekleştirirseniz, parçalanma oldukça hızlı bir şekilde gerçekleşecektir. Ayrıca, asgari boyut sonuç seti olarak 4096 (4K) vardır. Ne yazık ki, mysql sorgu önbelleğini birleştirmek için hiçbir iç mekanizmaya sahip değildir.

Sorgu önbelleğine sahip olmanız ve çok fazla RAM'iniz varsa, aşağıdakileri uygulayabilirsiniz:

SET GLOBAL query_cache_size = 0;
SELECT SLEEP(60);
SET GLOBAL query_cache_size = 1024 * 1024 * 1024;

sorgu önbelleğini temizlemek için. Tüm önbelleğe alınmış sonuçları kaybedersiniz, bu nedenle yoğun olmayan saatlerde bu satırları çalıştırın.

Ayrıca aşağıdakileri de tayin ederim:

  • query_cache_size = 1G
  • query_cache_limit = 8M

Bu 23G RAM bırakır. Aşağıdakileri yükselteceğim:

  • innodb_buffer_pool_size = 12G
  • key_buffer_size = 4G

Bu 7G bırakır. Bu işletim sistemi ve DB bağlantıları için yeterli olmalıdır.

InnoDB Buffer Pool verileri ve dizinleri önbelleğe alırken, anahtar arabelleğin yalnızca MyISAM dizin sayfalarını önbelleğe aldığını unutmayın.

Bir öneri: MySQL 5.5'e yükseltin, böylece InnoDB'yi birden fazla CPU için ve okuma / yazma G / Ç için birden fazla iş parçacığı için yapılandırabilirsiniz.

InnoDB için birden fazla CPU'ya erişimle bağlantılı olarak MySQL 5.5 kullanımı ile ilgili daha önceki yayınlarıma bakın

GÜNCELLEME 2012-09-06 14:56 EDT

Sorgu önbelleğini temizleme yöntemim oldukça aşırıdır çünkü önbelleğe alınmış verileri hortumlar ve tamamen farklı bir RAM kesimi oluşturur. Yorumunuzda belirttiğiniz gibi FLUSH QUERY CACHE(önerdiğiniz gibi) hatta RESET QUERY CACHEdaha iyi olurdu. Açıklama için, "iç mekanizma yok" dediğimde, tam olarak öyle demek istedim. Birleştirme gerekli ve manuel olarak yapılması gerekiyor. Crontab'd olması gerekecekti .

InnoDB'de DML'yi (INSERT'ler, UPDATE'ler, DELETE'ler) MyISAM'da olduğundan daha sık yaparsanız, başlangıçta söylediğim tümüyle sorgu önbelleğini kaldır derim.


Yanıtınız için teşekkürler. Ben o kitabım var ve onu yoğun bir şekilde kullanıyordum; Önbellek özlüyoruz için ana hatlarını belirlediğiniz nedenlerin farkındayım, ancak belirttiğim gibi, Com_select ve Qcache_inserts arasında gördüğümüz güçlü korelasyon nedeniyle önbellek geçersizliğini önemli bir sorun olarak belirledik. Oh, ve söz konusu DB INNODB ve MyISAM karışımı var.
Craig Sefton

İstediğiniz ek bilgi ile güncellendi. Teşekkürler.
Craig Sefton

Yanıtınız için teşekkürler, gerisini sabırsızlıkla bekliyorum. Tanımladığımız şeylerden biri, sorguların yaklaşık% 18'inin önbelleğe alınmadığıydı, bu nedenle ayarlarla ilgili önerileri kesinlikle takdir edin. Ne yazık ki kutu adanmış değil, ancak önerileriniz yardımcı olmalıdır. Parçalanma kesinlikle de bir konudur. Gördüğümüz geçersizliklerin sayısı konusunda hala gerçekten endişeliyim (önbelleğe alınmamış sorguların aksine), bu nedenle ek yükün buna değip değmeyeceği konusunda hala belirsiz. Görüşünüzü gerçekten takdir edin, çok teşekkür ederim.
Craig Sefton

"Sorgu önbelleğini birleştirmek için mysql'nin dahili bir mekanizması yok" hakkındaki yorumunuzla ilgili olarak, birleştirme komutunu çalıştıramaz FLUSH QUERY CACHEmısınız? Bakınız: dev.mysql.com/doc/refman/5.0/en/flush.html
Craig Sefton

Cevabım güncellendi ...
RolandoMySQLDBA 6:12

3

BAD: query_cache_size = 1G

Niye ya? Bir floş ne kadar zaman alacağına bağlı. Yani, bazı yazma işlemleri gerçekleştiğinde, değiştirilen tabloya referans bulmak için 1GB'ın tamamı taranacaktır. QC ne kadar büyük olursa, o kadar yavaş olur. Verileriniz nadiren değişmedikçe, 50M'den fazla olmayan bir boyut öneririm.

QC, hem MyISAM hem de InnoDB için genel giderler. Küresel bir Mutex çıkarır ve çok yakında çıkarır. Bu muteks, MySQL'in yaklaşık 8 çekirdekten daha fazla faydalanamamasının bir nedenidir.

SQL_NO_CACHE kadar fark edilmez sonra dışlama kilitlendi! Bu bayrak için tek kullanım hakkında kıyaslama için.

Genellikle RAM'i başka bir önbelleğe vermek daha iyidir.


2

Bunun için mükemmel bir durum düşünebiliyorum ve iyice test ettik ve üretimde çalıştırdık ... "Hızlı şerit" kümeleme stratejisi olarak adlandırıyorum:

MaxScale gibi bir proxy ile okuma-yazma bölmesi yaparsanız veya uygulamanız yetenekliyse, nadiren geçersiz kılan tablolara ilişkin okumaların bazılarını yalnızca sorgu önbelleği açık olan kölelere ve diğerlerini de bununla birlikte diğer kölelere gönderebilirsiniz. kapalı.

Bunun sonucunda yük testlerimiz sırasında kümeye yapılan 4M çağrılarını gerçekleştiririz (sonuç olarak kıyaslama yapmaz ... gerçek anlaşma). Uygulama, bazı şeyler için master_pos_wait () üzerinde bekler, bu nedenle çoğaltma iş parçacığı tarafından boğulur ve Qcache geçersiz kılma işlemini çok yüksek bir verimde beklemekte olduğumuzu görmemize rağmen, bu verim seviyeleri kümeden daha yüksektir Qcache olmadan yetenekli.

Bu işe yarar çünkü bu makinelerdeki küçük sorgu önbelleğinde geçersiz kılmak için nadiren ilgili bir şey yoktur (bu sorgular yalnızca seyrek güncellenen tablolarla ilgilidir). Bu kutular bizim "hızlı şeridimiz". Uygulamanın yaptığı soruların geri kalanı için, açılmadan kutulara gittikleri için Qcache ile uğraşmaları gerekmez.

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.