MySQL table_cacheおよびOpened_tables


14

MySQLでtable_cacheが小さすぎるかどうかを評価するためにOpen_tablesとOpened_tablesの比較を使用する人々を見てきました。ただし、Opened_tablesはアップタ​​イム全体で累積されるため、これは有効な比較ではありません。唯一の注意点は、おそらくOpened_tablesが失敗した場合にのみバンプされることです。ただし、1秒あたりに開かれるテーブルがまだ小さい場合でも、徐々に大きくなることはおそらく問題ではありません。

Open_tablesとOpened_tablesを比較することが有効でない場合、これに関する測定データを取得する別の方法はありますか?

これはMySQL 5.0にありますが、バージョン間の違いも歓迎します。


この質問は、刺激的な質問なので気に入っています。これにより、MySQL開発者にDBサーバーの健全性を測定するためにステータス変数を最大限に活用するように促すための+1が得られます。
-RolandoMySQLDBA

回答:


7

大きなtable_cacheを持つ最大の理由は、LOCK_open mutexがホットにならない。5.5より前のMySQLでは、テーブルをオープン/クローズしようとするときに多くの競合が発生するため、これをできるだけ制限する必要があります。つまり、大きなテーブルキャッシュを使用します。

したがって、ヒットとミスの特定の比率については気にしません(実際、比率を完全に無視する必要があります- このブログ投稿では理由を説明しています)。気になるのはミス率です。これは1秒あたりの発生回数が多いほど、競合が発生する可能性が高くなるためです(1つのスレッドが別のスレッドがロックを解除するまで待機する必要があります)。

ミス率をどのように見つけますか?1日の最も忙しい時間帯に数秒間隔でOpened_Tablesのサンプルをいくつか取得します。各サンプルに増加がある場合は、table_cacheを増やすことができるかどうかを確認することをお勧めします。

注:稼働時間との比較は特にお勧めしません。


5

まず、これらのステータス変数を考えてみましょう。

Open tables開いているテーブルの数。

Opened_tables:開かれたテーブルの数。Opened_tablesが大きい場合、おそらくtable_open_cacheの値が小さすぎます。

驚くべきことに、あなたの質問に対する答えは質問自体の中にあります。

2つの変数は、もう1つのステータス変数をミックスに投入する場合にのみ意味があります:Uptime(またはFLUSH STATUSの後の新鮮な平均のUptime_since_flush ステータス)。

Open_tables agsinst (Opened_tables / Uptime)を比較する必要があります。Open_tablesが(Opened_tables / Uptime)を上回った場合、懸念の原因があり、次のようなことに注意を向ける必要があります。

更新2011-08-31 12:18 EDT

また、Uptimeの代わりにUptime_since_flush_statusを使用して、特定の期間のOpened_tables成長の修正パターンを取得することを提案した理由に注意してください。

たとえば、FLUSH STATUS;毎週月曜日の真夜中に実行する場合、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は絶えず変化するか、別の天井または台地にぶつかる可能性があります。したがって、この種のチューニングには、ステータス変数内で異なるユニットを使用することが重要になります。

更新2011-08-31 12:42 EDT

OpenTableFactorに対して実行したSQLクエリは、MySQL 5.0以降では機能しません。MySQL AdministratorまたはMONyogを使用している場合、クエリおよびモニターの式を使用してグラフをカスタマイズできます。MONyogは、SQLLiteを使用して履歴を収集し、後で履歴グラフを作成します。これは、MySQLのどのバージョンでも実行できます。


いくつかの良い提案がありますが、累積値を現在の値と比較するよりも、異なる単位で2つのことを比較する必要はないと思います。そして、これが単にミスを測定するかどうかという問題が残っています。
サムブライトマン

3

table_cacheドキュメントページのユーザーコメントの1つから:

Opened_tablesは、table_cache内の使用可能なファイル記述子が枯渇したときに、テーブルを開くために割り当てられた追加のファイル記述子の数の実行中の集計を保持するステータス変数です。...

table_cache価値を超えたときに増分されることを意味します。したがって、私が通常これをチェックする方法はと比較opened_tablesすることuptimeですが、ここで重要なのは、設定された間隔(たとえば、1分間に1回、10分間)を取ることです。増加している場合は、増加する必要がある可能性がありますtable_cache

言及すべきいくつかの注意事項:

  • 上記のドキュメント内の別のコメント:「ステータス変数 'Opened_tables'も、一時テーブルを作成するたびに2ずつ増加します。」そのため、クエリで多くの一時テーブルが必要な場合、これがの急激な増加の原因になる可能性がありますopened_tables。次のクエリを使用して、一時テーブルの使用状況を確認できます。

    SHOW GLOBAL STATUS LIKE '%tmp%';

  • table_cacheのを増加させない、あまりにも

    そのような振る舞いの理由は、もしあなたが大きなノーを持っているならです。複数のテーブルとそれらの複雑なクエリを実行する複数の接続を結合する複雑なクエリを持つテーブルの場合、MySQLはアルゴリズムを使用して、最も最近使用されていない記述子を見つけ、閉じて、置換する場合、すべてのファイル記述子のキャッシュ(table_cache)を使用することになります新しい記述子を使用します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.