MySQL table_cache ve Opened_tables

Ben insanlar tablo_cache MySQL çok küçük olup olmadığını değerlendirmek için Open_tables ve Opened_tables karşılaştırmasını kullandık gördük. Ancak, Opened_tables çalışma süresi boyunca kümülatif olduğuna inanıyorum, bu yüzden bu geçerli bir karşılaştırma değil. Belki de Opened_tables sadece özlüyor çarpması tek uyarı - o zaman bile saniyede açılan tablolar hala küçük olsa da, muhtemelen yavaş yavaş büyümesi için bir sorun değildir.

Open_tables ile Opened_tables karşılaştırması geçerli değilse, bunun için ölçülen veri almanın başka bir yolu var mı?

Bu MySQL 5.0 üzerinde, ancak sürüm arasındaki farklar da kabul edilir.

Büyük bir table_cache olmasının en büyük nedeni, LOCK_open muteksinin sıcak olmamasıdır. 5.5'ten önceki MySQL, tabloları açmaya / kapatmaya çalıştığınızda çok fazla çekişmeye sahiptir, bu nedenle bunu olabildiğince kısıtlamak, yani büyük bir tablo önbelleğine sahip olmak istersiniz.

Bu nedenle, isabetlerin özlüyorsa belirli bir oranını umursamıyorsunuz (aslında oranları tamamen görmezden gelmelisiniz - bu blog yazısı nedenini açıklıyor ). Önem verdiğiniz şey kaçırılma oranıdır , çünkü bu saniyede ne kadar çok olursa, çekişme şansınız o kadar yüksek olur (bir iş parçacığının kilidi serbest bırakması için başka bir iş parçacığının beklemesi gerekir.)

Kaçırma oranını nasıl tespit edersiniz? Günün en yoğun döneminde birkaç saniye arayla birkaç Opened_Tables örneği alırsınız ve her bir örnekte artışlar varsa, table_cache'yi şişirip kaldıramayacağınızı görmek iyi bir fikir olabilir.

Not: Kesinlikle çalışma süresi ile karşılaştırmayı önermiyorum.

İlk olarak, bu durum değişkenlerini ele alalım:

Açık tablolar : Açık olan tablo sayısı.

Opened_tables : Açılan tablo sayısı. Opened_tables büyükse, table_open_cache değeriniz muhtemelen çok küçüktür.

Şaşırtıcı bir şekilde, sorunuzun cevabı sorunun kendisinde yatıyor.

: Eğer karışımı içine bir daha durum değişkeni atmak eğer iki değişken sadece daha mantıklı olur Uptime (veya Uptime_since_flush statü sonra taze ortalamalar için FLUSH Durum ).

Open_tables agsinst (Opened_tables / Uptime) 'ı karşılaştırmalısınız . Open_tables'ın üstüne çıkarsa (Opened_tables / Uptime) , şimdi endişe için bir nedeniniz var ve aşağıdaki gibi şeylere göz kulak olmalısınız:

• netstat
• iostat
• sunucu yükü
• Bağlantı Sayısı ( max_connections'a yaklaşırken )
• İptal edilen istemciler
• Durdurulmuş bağlantılar
• Yavaş sorgular

GÜNCELLEME 2011-08-31 12:18 EDT

Belirli bir dönemde düzeltilmiş bir Opened_tables büyüme modeli elde etmek için neden Uptime yerine Uptime_since_flush_status kullanılmasını önerdiğimi lütfen unutmayın .

Örneğin, FLUSH STATUS;her Pazartesi gece yarısı çalışırsanız, bir OpenTableFactor oluşturabilirsiniz:

SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM
(SELECT variable_value Uptime FROM information_schema.global_status
WHERE variable_name = 'Uptime_since_flush_status') up,
(SELECT variable_value Open_tables FROM information_schema.global_status
WHERE variable_name = 'Open_tables') opn,
(SELECT IF(variable_value=0,1,variable_value) Opened_tables
FROM information_schema.global_status
WHERE variable_name = 'Opened_tables') opnd;

Bu açık tablo faktörü, belirli bir dönem boyunca ortalama açılan tablo sayısına karşı herhangi bir anda açık tablo sayısını temsil eden sayıya eşittir. Bir ile FLUSH HOSTS;her hafta / gün / konak, ortalama hafta / gün / saat aykırıdır.

İşte benim işveren müşterilerimden bir örnek:

mysql> SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM     (SELECT variable_value Uptime FROM information_sc    hema.global_status     WHERE variable_name = 'Uptime_since_flush_status') up,     (SELECT variable_value Open_tables FROM informat    ion_schema.global_status     WHERE variable_name = 'Open_tables') opn,     (SELECT IF(variable_value=0,1,variable_value) Opened_ta    bles     FROM information_schema.global_status     WHERE variable_name = 'Opened_tables') opnd;
+----------+-------------+---------------+-------------------+
| Uptime   | Open_tables | Opened_tables | OpenTableFactor   |
+----------+-------------+---------------+-------------------+
| 14385123 | 16326       | 30429078      | 7717.996519579068 |
+----------+-------------+---------------+-------------------+
1 row in set (0.00 sec)

Bu istemci normalde maksimum 7745 OpenTableFactor tutar. OpenTableFactor aniden düşerse (az da olsa), daha düşük trafik düzenlerini, yüksek iptal edilen bağlantıları vb. Gösterebilir. OpenTableFactor asla değişmezse (biraz da olsa), size bu ayarları değiştirme fırsatı sunabilir:

• open_files_limit
• innodb_open_files
• table_open_cache

Ayarlandıktan sonra, OpenTableFactor sürekli olarak değişebilir veya başka bir tavana veya platoya çarpabilir. Böylece, durum değişkenleri içinde farklı birimlerin kullanılması bu tür ayarlar için hayati önem taşır.

GÜNCELLEME 2011-08-31 12:42 EDT

OpenTableFactor için çalıştırdığım SQL sorgusu MySQL 5.0 ve geri için çalışmıyor. Eğer kullanıyorsanız MySQL Yöneticisi veya MONyog , sen sorgu ve monitörün içinde formül kullanılarak bir grafik özelleştirebilirsiniz. MONyog, daha sonraki tarihsel grafikleme için SQLLite kullanarak tarihi toplar. Bu, MySQL'in herhangi bir sürümü için yapılabilir.

Table_cache dokümantasyon sayfasındaki kullanıcı yorumlarından birinden :

Opened_tables, table_cache dosyasındaki kullanılabilir dosya tanımlayıcılarının tükendiği zamanlarda tabloları açmak için ayrılmış ek dosya tanımlayıcılarının sayısının sürekli çalışmasını sağlayan bir durum değişkenidir. ...

Yani table_cachedeğerinizin üzerine çıktığınız zaman artmaktadır . Normalde bu kontrol yolu karşılaştırmaktır Yani opened_tablesbirlikte uptime, ama burada anahtar bir dizi aralık üzerine almaktır (örneğin dakikada on dakikadan kez). Artarsa, artırmanız gereken bir gösterge olabilirtable_cache .

Bir kaç söz:

• Yukarıdaki dokümanlarda yer alan bir başka yorum: "Her bir geçici tablo oluşturduğunuzda" Opened_tables "durum değişkeni 2 artırılacaktır." Bu nedenle, sorgularınız çok sayıda geçici tablo gerektiriyorsa, bu hızlı bir artışın nedeni olabilir opened_tables. Geçici tablo kullanımınızı aşağıdaki sorguyu kullanarak görebilirsiniz:

  SHOW GLOBAL STATUS LIKE '%tmp%';

• Table_cache öğesini çok yüksek artırmayın

  Böyle bir davranışın nedeni, eğer büyük hayırınız varsa. karmaşık sorguları olan tabloları içeren ve bu karmaşık sorguları çalıştıran birden fazla bağlantı içeren tablolardan tüm dosya tanımlayıcılarınızın önbelleğini (table_cache) kullanabilirsiniz, bu durumda MySQL en son kullanılan tanımlayıcıyı bulmak için algoritma kullanır, kapatır ve değiştirir yeni bir tanımlayıcıyla.