このページは機械翻訳したものです。
パフォーマンススキーマに関連付けられたいくつかのステータス変数があります。
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_memory_classes_lost | 0 |
| Performance_schema_metadata_lock_lost | 0 |
| Performance_schema_mutex_classes_lost | 0 |
| Performance_schema_mutex_instances_lost | 0 |
| Performance_schema_nested_statement_lost | 0 |
| Performance_schema_program_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_lostxxx
のロードできなかったインストゥルメントの数を示します。Performance_schema_
は、オブジェクトの種類xxx
_instances_lostxxx
の作成できなかったインストゥルメントの数を示します。Performance_schema_
は、オブジェクトの種類xxx
_handles_lostxxx
のオープンできなかったインストゥルメントの数を示します。Performance_schema_locker_lost
は、「失われた」か、または記録されなかったイベント数を示します。
たとえば、相互排他ロックがサーバーソースにインストゥルメントされているが、サーバーが実行時にインストゥルメンテーション用のメモリーを割り当てることができない場合、それは Performance_schema_mutex_classes_lost
を増分します。 mutex は同期オブジェクトとして機能しますが (つまり、サーバーは通常どおり機能します)、そのパフォーマンスデータは収集されません。 インストゥルメントを割り当てることができる場合、それはインストゥルメントされた相互排他ロックインスタンスの初期化に使用できます。 グローバル mutex などのシングルトン mutex の場合、インスタンスは 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_delete
は setup_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.size
Status: 76
*************************** 4. row ***************************
Type: performance_schema
Name: events_waits_history.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.7.15「SHOW ENGINE ステートメント」を参照してください。