web-dev-qa-db-ja.com

table_cacheヒット率の何が問題になっていますか？

my.cnf 私が持っています：

table_cache            = 524288
open_files_limit        = 65535

どちらもmysql構成で許可されている最大値です。どちらも最大オープンファイル制限未満です。

# cat /proc/sys/fs/file-max
2097152

MySQL変数のステータス：

mysql> SHOW GLOBAL STATUS LIKE 'open%';
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| Open_files               | 193    |
| Open_streams             | 0      |
| Open_table_definitions   | 594    |
| Open_tables              | 802    |
| Opened_files             | 537248 |
| Opened_table_definitions | 4895   |
| Opened_tables            | 9174   |
+--------------------------+--------+
7 rows in set (0.00 sec)

サーバーには32GB RAMがあります。ほとんど無料！

それでも、mysqltunerスクリプトを実行すると：

それは言う：

[!!]テーブルキャッシュヒット率：13％（オープン853 /オープン6K）

Table_cacheのヒット率が低い理由は何ですか？

mysqlperformanceoptimizationmy.cnfcache
3
rahul286

ここで1つのことは、代わりにこのフォームを使用する必要があることです。

mysql> show global status like '%open%';

これらのカウンタの一部はグローバルであり、一部はセッションであるため、GLOBALキーワードを使用しないと、分割された数値セット（特にOpened_table*値）が得られます。

チューニングスクリプトの問題は、値が正しい範囲にあるかどうかを判断するときに考慮する必要があるすべての要因を考慮できない可能性があることです。たとえば、FLUSH TABLESを使用すると、 Opened_filesおよびOpened_tablesカウンターは、フラッシュされたすべてのテーブルが再びアクセスされるとすぐに再び開かれるため、すぐに増加します...これは、もちろん、何も否定的な意味を持ちません。

バックアップにmysqldumpを使用すると、通常、バックアッププロセスの最初にFLUSH TABLESまたはFLUSH TABLES WITH READ LOCKが発行されます。これは、毎日のバックアップを実行していて、サーバーの稼働時間が数回であっても非常に貧弱な「table_cacheヒット率」を簡単に目にすることができ、これも何の意味もありません。

「Table_cache hit rate」は、実際にはMySQLからの値ではありません。他の2つの値からの計算です。 mysqltunerで実行しているのは、open_tablesをop​​ened_tablesで除算することだけです（現在開いている数と、開いている数との比較）。

badprint "Table cache hit rate: $mycalc{'table_cache_hit_rate'}% (".hr_num($mystat{'Open_tables'})." open / ".hr_num($mystat{'Opened_tables'})." opened)\n";

したがって、これら2つの値を時間の経過とともに観察し、トラフィックが増加するバックアップ後の期間を除いて、Opened_tablesが急速に増加しない場合は、問題はありません。

これは私には誤警報のように見えます。

15
Michael - sqlbot