Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb


MySQL 5.6 リファレンスマニュアル  /  MySQL パフォーマンススキーマ  /  パフォーマンススキーマステータスモニタリング

22.5 パフォーマンススキーマステータスモニタリング

パフォーマンススキーマに関連付けられたいくつかのステータス変数があります。

mysql> SHOW STATUS LIKE 'perf%';
+-----------------------------------------------+-------+
| Variable_name                                 | Value |
+-----------------------------------------------+-------+
| Performance_schema_accounts_lost              | 0     |
| Performance_schema_cond_classes_lost          | 0     |
| Performance_schema_cond_instances_lost        | 0     |
| Performance_schema_digest_lost                | 0     |
| Performance_schema_file_classes_lost          | 0     |
| Performance_schema_file_handles_lost          | 0     |
| Performance_schema_file_instances_lost        | 0     |
| Performance_schema_hosts_lost                 | 0     |
| Performance_schema_locker_lost                | 0     |
| Performance_schema_mutex_classes_lost         | 0     |
| Performance_schema_mutex_instances_lost       | 0     |
| Performance_schema_rwlock_classes_lost        | 0     |
| Performance_schema_rwlock_instances_lost      | 0     |
| Performance_schema_session_connect_attrs_lost | 0     |
| Performance_schema_socket_classes_lost        | 0     |
| Performance_schema_socket_instances_lost      | 0     |
| Performance_schema_stage_classes_lost         | 0     |
| Performance_schema_statement_classes_lost     | 0     |
| Performance_schema_table_handles_lost         | 0     |
| Performance_schema_table_instances_lost       | 0     |
| Performance_schema_thread_classes_lost        | 0     |
| Performance_schema_thread_instances_lost      | 0     |
| Performance_schema_users_lost                 | 0     |
+-----------------------------------------------+-------+

パフォーマンススキーマステータス変数は、メモリー制約のためロードまたは作成できなかったインストゥルメンテーションに関する情報を提供します。これらの変数の名前にはいくつかの形式があります。

  • Performance_schema_xxx_classes_lost は、種類 xxx のロードできなかったインストゥルメントの数を示します。

  • Performance_schema_xxx_instances_lost は、オブジェクトの種類 xxx の作成できなかったインストゥルメントの数を示します。

  • Performance_schema_xxx_handles_lost は、オブジェクトの種類 xxx のオープンできなかったインストゥルメントの数を示します。

  • Performance_schema_locker_lost は、失われたか、または記録されなかったイベント数を示します。

たとえば、相互排他ロックがサーバーソースにインストゥルメントされているが、サーバーが実行時にインストゥルメンテーション用のメモリーを割り当てることができない場合、それは Performance_schema_mutex_classes_lost を増分します。相互排他ロックは、まだ同期オブジェクトとして機能します (つまり、サーバーは正常に機能し続けます) が、そのパフォーマンスデータは収集されません。インストゥルメントを割り当てることができる場合、それはインストゥルメントされた相互排他ロックインスタンスの初期化に使用できます。グローバル相互排他ロックなどのシングルトン相互排他ロックの場合、1 つのインスタンスだけが存在します。その他の相互排他ロックは、接続あたり、または各種キャッシュおよびデータバッファー内のページあたりに 1 つのインスタンスを持つため、インスタンスの数は時間の経過とともに変わります。接続の最大数または一部のバッファーの最大サイズを増やすと、一度に割り当てることができるインスタンスの最大数が増えます。サーバーが特定のインストゥルメントされた相互排他ロックインスタンスを作成できない場合、それは Performance_schema_mutex_instances_lost を増分します。

次の条件が維持されているとします。

  • サーバーは --performance_schema_max_mutex_classes=200 オプションを使用して起動されているため、200 相互排他ロックインストゥルメントのための空きがあります。

  • 150 相互排他ロックインストゥルメントはすでにロードされています。

  • plugin_a という名前のプラグインには 40 相互排他ロックインストゥルメントが含まれます。

  • plugin_b という名前のプラグインには 20 相互排他ロックインストゥルメントが含まれます。

サーバーは、次の一連のステートメントに示すように、プラグインに、それらが必要とする数と使用可能な数に応じて、相互排他ロックインストゥルメントを割り当てます。

INSTALL PLUGIN plugin_a

現在サーバーには 150+40 = 190 相互排他ロックインストゥルメントがあります。

UNINSTALL PLUGIN plugin_a;

サーバーにはまだ 190 インストゥルメントがあります。プラグインコードによって生成されたすべての履歴データはまだ使用できますが、インストゥルメントの新しいイベントは収集されません。

INSTALL PLUGIN plugin_a;

サーバーは 40 インストゥルメントがすでに定義されていることを検出したため、新しいインストゥルメントが作成されず、以前に割り当てられた内部メモリーバッファーが再利用されます。サーバーにはまだ 190 インストゥルメントがあります。

INSTALL PLUGIN plugin_b;

サーバーは 200-190 = 10 インストゥルメント (この例では、相互排他ロッククラス) の空きがあり、プラグインに 20 個の新しいインストゥルメントが含まれていることを認識します。10 個のインストゥルメントがロードされ、10 個は破棄されるか失われます。Performance_schema_mutex_classes_lost は失われたインストゥルメント (相互排他ロッククラス) の数を示します。

mysql> SHOW STATUS LIKE "perf%mutex_classes_lost";
+---------------------------------------+-------+
| Variable_name                         | Value |
+---------------------------------------+-------+
| Performance_schema_mutex_classes_lost | 10    |
+---------------------------------------+-------+
1 row in set (0.10 sec)

インストゥルメンテーションはまだ機能し、plugin_b の (部分) データを収集します。

サーバーが相互排他ロックインストゥルメントを作成できないと、次の結果が発生します。

  • インストゥルメントの行が setup_instruments テーブルに挿入されません。

  • Performance_schema_mutex_classes_lost が 1 増加します。

  • Performance_schema_mutex_instances_lost は変更されません。(相互排他ロックインストゥルメントが作成されない場合、あとでインストゥルメントされた相互排他ロックインスタンスの作成にそれを使用できません。)

先述のパターンは相互排他ロックだけでなく、すべての種類のインストゥルメントに当てはまります。

0 より大きい Performance_schema_mutex_classes_lost の値は 2 つのケースで発生する可能性があります。

  • 数バイトのメモリーを節約するには、サーバーを --performance_schema_max_mutex_classes=N で起動します。ここで N はデフォルト値未満です。デフォルト値を選択すれば、MySQL 配布で提供されるすべてのプラグインをロードするために十分ですが、一部のプラグインをロードしない場合にこれを減らすことができます。たとえば、配布内の一部のストレージエンジンをロードしないように選択できます。

  • パフォーマンススキーマ用にインストゥルメントされたサードパーティープラグインをロードしますが、サーバーの起動時に、プラグインのインストゥルメンテーションメモリー要件を考慮しません。それはサードパーティー製であるため、このエンジンのインストゥルメントメモリー消費は performance_schema_max_mutex_classes で選択されたデフォルト値で考慮されていません。

    サーバーにプラグインのインストゥルメント用の十分なリソースがなく、ユーザーが --performance_schema_max_mutex_classes=N を使用して、明示的に多く割り当てていない場合、このプラグインをロードすると、インストゥルメントが不足します。

performance_schema_max_mutex_classes に選択されている値が小さすぎる場合、エラーログにエラーが報告されず、実行時に障害が発生しません。ただし、performance_schema データベース内のテーブルの内容にイベントが含まれません。Performance_schema_mutex_classes_lost ステータス変数は、インストゥルメントの作成の失敗のために、一部のイベントが内部で削除されたことを示す唯一の目に見えるしるしです。

インストゥルメントが失われていない場合、それはパフォーマンススキーマに認識され、インスタンスのインストゥルメント時に使用されます。たとえば、wait/synch/mutex/sql/LOCK_deletesetup_instruments テーブル内の相互排他ロックインストゥルメントの名前です。サーバーの実行時に相互排他ロックの多くのインスタンスが必要であっても、コード内 (THD::LOCK_delete 内) で相互排他ロックの作成時に、この単一のインストゥルメントが使用されます。この場合、LOCK_delete は接続 (THD) ごとの相互排他ロックであるため、サーバーに 1000 接続がある場合、1000 スレッドと 1000 個のインストゥルメントされた LOCK_delete 相互排他ロックインスタンス (THD::LOCK_delete) が存在します。

サーバーにこれらの 1000 個のインストゥルメントされた相互排他ロック (インスタンス) すべてのための空きがない場合、一部の相互排他ロックはインストゥルメンテーション付きで作成され、一部はインストゥルメンテーションなしで作成されます。サーバーが 800 インスタンスしか作成できない場合、200 インスタンスが失われます。サーバーは実行し続けますが、Performance_schema_mutex_instances_lost を 200 増分し、インスタンスを作成できなかったことを示します。

0 より大きい Performance_schema_mutex_instances_lost は、--performance_schema_max_mutex_instances=N で割り当てられたものより多くの相互排他ロックを、コードで実行時に初期化した場合に発生する可能性があります。

結論として、SHOW STATUS LIKE 'perf%' に何も失われていないことが示されている (すべての値がゼロ) 場合に、パフォーマンススキーマデータは正確で信頼できます。何かが失われた場合、データは不完全であり、使用するように与えられたメモリーの量が不十分であったとすると、パフォーマンススキーマはすべてを記録できていません。この場合、特定の Performance_schema_xxx_lost 変数に問題の領域が示されます。

場合によって、意図的にインストゥルメントの不足を発生させることが適切なことがあります。たとえば、ファイル I/O のパフォーマンスデータに関心がない場合は、ファイル I/O に関連するすべてのパフォーマンススキーマのパラメータを 0 に設定して、サーバーを起動できます。ファイル関連のクラス、インスタンス、またはハンドルにメモリーが割り当てられず、すべてのファイルイベントが失われます。

SHOW ENGINE PERFORMANCE_SCHEMA STATUS を使用して、パフォーマンススキーマコードの内部操作を検査します。

mysql> SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G
...
*************************** 3. row ***************************
  Type: performance_schema
  Name: events_waits_history.row_size
Status: 76
*************************** 4. row ***************************
  Type: performance_schema
  Name: events_waits_history.row_count
Status: 10000
*************************** 5. row ***************************
  Type: performance_schema
  Name: events_waits_history.memory
Status: 760000
...
*************************** 57. row ***************************
  Type: performance_schema
  Name: performance_schema.memory
Status: 26459600
...

このステートメントは、さまざまなパフォーマンススキーマオプションがメモリー要件に与える効果について、DBA が理解できるようにすることを目的としています。フィールドの意味の説明については、セクション13.7.5.16「SHOW ENGINE 構文」を参照してください。


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.