MySQLでtable_cacheが小さすぎるかどうかを評価するためにOpen_tablesとOpened_tablesの比較を使用している人を見てきました。ただし、Opened_tablesは稼働時間全体で累積的であるため、これは有効な比較ではありません。唯一の注意点は、おそらくOpened_tablesがミスにぶつかることだけです-それでも、1秒あたりに開かれるテーブルがまだ小さい場合でも、徐々に大きくなることはおそらく問題ではありません。
Open_tablesとOpened_tablesの比較が有効でない場合、これに関する測定データを取得する別の方法はありますか?
これはMySQL 5.0にありますが、バージョン間の違いも歓迎です。
大きなtable_cacheを使用する最大の理由は、 LOCK_open mutex がホットにならないようにするためです。 5.5より前のMySQLでは、テーブルを開いたり閉じたりするときに多くの競合が発生するため、これをできる限り制限する必要があります。つまり、テーブルキャッシュが大きくなります。
したがって、ヒットとミスの特定の比率を気にする必要はありません(実際には比率をすべて無視する必要があります- このブログ投稿で理由を説明しています )。あなたが気にしているのは、ミス率です。これが毎秒発生する回数が多いほど、競合が発生する可能性が高くなります(1つのスレッドが別のスレッドがロックを解放するのを待ちます。)
どのようにミス率を見つけますか? 1日の最も忙しい期間中に数秒間隔でOpened_Tablesのいくつかのサンプルをフェッチします。各サンプルに増加がある場合は、table_cacheを増やすことができるかどうかを確認することをお勧めします。
注:稼働時間と比較することは特にお勧めしません。
まず、これらのステータス変数について考えてみましょう。
Open tables :開いているテーブルの数。
Opened_tables :開かれたテーブルの数。 Opened_tablesが大きい場合は、table_open_cacheの値が小さすぎる可能性があります。
驚いたことに、あなたの質問への答えは質問自体の中にあります。
2つの変数は、1つ以上のステータス変数をミックスに投入した場合にのみ意味があります。 ptime (または ptime_since_flush statusFLUSH STATUS の後の新しい平均の場合=)。
Open_tables agsinst(Opened_tables/Uptime)を比較する必要があります。 Open_tablesが(Opened_tables/Uptime)を上回った場合、問題が発生しているため、次のようなことに注意する必要があります。
UPDATE 2011-08-31 12:18 EDT
UptimeではなくUptime_since_flush_statusを使用して一定期間のOpened_tablesの成長パターンを修正しました。
たとえば、FLUSH STATUS;
毎週月曜日の午前0時に、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;
このオープンテーブル係数は、特定の期間のオープンテーブルの平均数に対する、任意の瞬間のオープンテーブルの数を表す数になります。とともに FLUSH HOSTS;
毎週/日/ホスト、その平均は週/日/時間に対するものです。
これは私の雇用主のクライアントの1つからのサンプルです。
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)
このクライアントは通常、最大で約7745のOpenTableFactorを維持します。 OpenTableFactorが突然(少しでも)低下する場合は、トラフィックパターンの低下、中断の多い接続などを示している可能性があります。 OpenTableFactorが(少しでも)変更されない場合、これらの設定を変更する機会が与えられる可能性があります。
調整後、OpenTableFactorは絶えず変化したり、別の天井や高原にぶつかったりすることがあります。したがって、ステータス変数内で異なるユニットを使用することは、この種のチューニングにとって重要になります。
UPDATE 2011-08-31 12:42 EDT
OpenTableFactorに対して実行したSQLクエリは、MySQL 5.0以降では機能しません。 MySQL Administrator または MONyog を使用している場合、クエリとモニターの式を使用してグラフをカスタマイズできます。 MONyogはSQLLiteを使用して履歴を収集し、後で履歴グラフを作成します。これは、MySQLのどのバージョンでも実行できます。
table_cache ドキュメントページのユーザーコメントの1つから:
Opened_tablesは、table_cacheで利用可能なファイル記述子が使い果たされたときにテーブルを開くために割り当てられた追加のファイル記述子の数の実行中の集計を保持するステータス変数です。 ...
つまり、table_cache
の値を超えると、値が増加します。したがって、これを通常チェックする方法は、opened_tables
とuptime
を比較することですが、ここで重要なのは、設定された間隔(たとえば、1分に1回、10分以上)でそれを取得することです。それが増加している場合mayは、table_cache
を増加する必要があることを示しています。
言及すべきいくつかの警告:
上記のドキュメントの別のコメント:「ステータス変数 'Opened_tables'も、一時テーブルを作成するたびに2ずつ増加します。」したがって、クエリで多くの一時テーブルが必要な場合、これがopened_tables
の急激な増加の原因である可能性があります。次のクエリを使用して、一時テーブルの使用状況を確認できます。
SHOW GLOBAL STATUS LIKE '%tmp%';
そのような振る舞いの理由は、あなたが大いにない場合です。複数のテーブルを結合する複雑なクエリとそれらの複雑なクエリを実行する複数の接続を持つテーブルの場合、MySQLがアルゴリズムを使用して最も使用されていない記述子を見つけ、それを閉じて置換する場合、すべてのファイル記述子のキャッシュ(table_cache)を使用することになります。新しい記述子でそれを。