it-swarm.asia

MySQL table_cache dan Opened_tables

Saya telah melihat orang menggunakan perbandingan Open_tables dan Opened_tables untuk menilai apakah table_cache terlalu kecil di MySQL. Namun, saya percaya bahwa Opened_tables bersifat kumulatif di seluruh waktu aktif, jadi ini bukan perbandingan yang valid. Satu-satunya peringatan yang mungkin Opened_tables hanya menabrak merindukan - meskipun itupun jika tabel yang dibuka per detik masih kecil, itu mungkin tidak masalah untuk itu tumbuh secara bertahap.

Jika membandingkan Open_tables dengan Opened_tables tidak valid, apakah ada cara lain untuk mendapatkan data yang diukur untuk ini?

Ini ada di MySQL 5.0, tetapi perbedaan antar versi juga diterima.

14
Sam Brightman

Alasan terbesar untuk memiliki table_cache besar adalah agar LOCK_open mutex tidak panas. MySQL sebelum 5.5 memiliki banyak pertentangan ketika Anda mencoba untuk membuka/menutup tabel, jadi Anda ingin membatasi melakukan ini sebanyak mungkin, yaitu memiliki cache tabel besar.

Jadi, Anda tidak peduli dengan rasio hit dan miss (infact Anda harus mengabaikan rasio sama sekali - posting blog ini menjelaskan alasannya ). Apa yang Anda pedulikan adalah miss rate , karena semakin sering ini terjadi per detik, semakin tinggi kemungkinan Anda akan memiliki pertengkaran (satu utas harus tunggu utas lainnya untuk melepaskan kunci.)

Bagaimana Anda mengetahui tingkat kesalahan? Anda mengambil beberapa sampel Opened_Tables terpisah beberapa detik selama periode tersibuk hari itu, dan jika ada peningkatan dalam setiap sampel, mungkin ide yang baik untuk melihat apakah Anda dapat meningkatkan table_cache.

Catatan: Saya sangat tidak merekomendasikan membandingkan dengan uptime.

7
Morgan Tocker

Pertama, mari kita pertimbangkan variabel status tersebut:

Buka tabel : Jumlah tabel yang terbuka.

Opened_tables : Jumlah tabel yang telah dibuka. Jika Opened_tables besar, nilai table_open_cache Anda mungkin terlalu kecil.

Anehnya, jawaban atas pertanyaan Anda ada di dalam pertanyaan itu sendiri.

Dua variabel hanya akan lebih masuk akal jika Anda melemparkan satu variabel status lagi ke dalam campuran: ptime (atau ptime_since_flush status untuk rata-rata baru setelah FLUSH STATUS =).

Anda harus membandingkan Open_tables agsinst (Opened_tables/Uptime) . Jika Open_tables naik di atas (Opened_tables/Uptime) , sekarang Anda memiliki alasan untuk khawatir dan harus tetap membuka mata untuk hal-hal seperti berikut:

UPDATE 2011-08-31 12:18 EDT

Harap perhatikan mengapa saya juga menyarankan untuk menggunakan Uptime_since_flush_status daripada Uptime untuk mendapatkan memperbaiki pola pertumbuhan Opened_tables untuk periode tertentu.

Misalnya, jika Anda menjalankan FLUSH STATUS; setiap hari Senin di tengah malam, Anda dapat menghasilkan OpenTableFactor:

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;

Faktor tabel terbuka ini sama dengan jumlah yang mewakili jumlah tabel terbuka pada saat tertentu terhadap jumlah rata-rata tabel terbuka selama periode tertentu. Dengan FLUSH HOSTS; setiap minggu/hari/Tuan rumah, rata-rata itu berlawanan dengan minggu/hari/jam.

Berikut adalah contoh dari salah satu klien majikan saya:

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)

Klien ini biasanya memelihara sekitar 7745 OpenTableFactor pada maks. Jika OpenTableFactor turun tiba-tiba (bahkan jika sedikit), itu bisa menunjukkan pola lalu lintas yang lebih rendah, conenctions yang dibatalkan tinggi, dan sebagainya. Jika OpenTableFactor tidak pernah berubah (walaupun sedikit), ini dapat memberi Anda kesempatan untuk mengubah pengaturan ini:

Setelah disesuaikan, OpenTableFactor dapat berubah secara konstan atau mengenai plafon atau dataran tinggi lainnya. Dengan demikian, menggunakan unit yang berbeda dalam variabel status menjadi vital untuk jenis penyetelan ini.

UPDATE 2011-08-31 12:42 EDT

Permintaan SQL yang saya jalankan untuk OpenTableFactor tidak berfungsi untuk MySQL 5.0 dan kembali. Jika Anda menggunakan Administrator MySQL atau MONyog , Anda bisa menyesuaikan grafik menggunakan rumus dalam kueri dan monitor. MONyog mengumpulkan sejarah menggunakan SQLLite untuk grafik historis selanjutnya. Ini dapat dilakukan untuk semua versi MySQL.

5
RolandoMySQLDBA

Dari salah satu komentar pengguna pada table_cache halaman dokumentasi:

Opened_tables adalah variabel status yang membuat penghitungan jumlah deskriptor file tambahan yang telah dialokasikan untuk membuka tabel pada saat-saat ketika deskriptor file yang tersedia di table_cache telah habis. ...

Artinya bertambah ketika Anda memeriksa table_cache nilai. Jadi cara saya biasanya memeriksa ini adalah untuk membandingkan opened_tables dengan uptime, tetapi kuncinya di sini adalah untuk mengambilnya pada interval yang ditetapkan (misalnya per menit selama sepuluh menit, misalnya). Jika itu meningkatkannya mungkin menjadi indikasi Anda perlu meningkatkan table_cache.

Beberapa peringatan untuk menyebutkan:

  • Komentar lain dalam dokumentasi di atas: "Variabel status 'Opened_tables' juga akan bertambah 2 setiap kali Anda membuat tabel sementara." Jadi jika pertanyaan Anda membutuhkan banyak tabel sementara, ini bisa menjadi penyebab peningkatan cepat dalam opened_tables. Anda dapat melihat penggunaan tabel sementara Anda menggunakan kueri berikut:

    SHOW GLOBAL STATUS LIKE '%tmp%';

  • Jangan menambah table_cache juga tinggi

    Alasan untuk perilaku seperti itu adalah bahwa, jika Anda memiliki tidak besar. tabel dengan kueri rumit yang bergabung dengan beberapa tabel dan beberapa koneksi yang menjalankan kueri rumit itu, Anda mungkin akhirnya menggunakan semua cache deskriptor file Anda (table_cache) dalam hal itu MySQL menggunakan algoritma untuk menemukan deskriptor yang terakhir digunakan, menutupnya, dan menggantikan dengan deskriptor baru.

3
Derek Downey