イベントはプロデューサ/コンシューマ方式で処理されます。
-
インストゥルメントされたコードは、イベントのソースで、収集されるイベントを生成します。
setup_instrumentsテーブルは、イベントを収集できるインストゥルメント、それらが有効にされているかどうか、および (有効にされているインストゥルメントの場合) タイミング情報を収集するかどうかを一覧表示します。mysql> SELECT NAME, ENABLED, TIMED FROM performance_schema.setup_instruments; +---------------------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +---------------------------------------------------+---------+-------+ ... | wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES | | wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES | | wait/synch/mutex/sql/LOCK_lock_db | YES | YES | | wait/synch/mutex/sql/LOCK_manager | YES | YES | ...setup_instrumentsテーブルはイベント生成のもっとも基本的な制御の形式を提供します。 モニターされるオブジェクトやスレッドの種類に基づいて、イベント生成をさらに絞り込むには、セクション27.4.3「イベントの事前フィルタリング」に説明するように、ほかのテーブルを使用できます。 -
パフォーマンススキーマテーブルは、イベントの宛先で、イベントを消費します。
setup_consumersテーブルは、イベント情報を送信できるコンシューマの種類とそれらが有効にされているかどうかを一覧表示します。mysql> SELECT * FROM performance_schema.setup_consumers; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | events_stages_current | NO | | events_stages_history | NO | | events_stages_history_long | NO | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | NO | | events_transactions_current | YES | | events_transactions_history | YES | | events_transactions_history_long | NO | | events_waits_current | NO | | events_waits_history | NO | | events_waits_history_long | NO | | global_instrumentation | YES | | thread_instrumentation | YES | | statements_digest | YES | +----------------------------------+---------+
フィルタリングはパフォーマンスモニタリングのさまざまなステージで実行できます。
-
事前フィルタリング. これは、プロデューサから特定の種類のイベントのみが収集され、収集されたイベントが特定のコンシューマのみを更新するように、パフォーマンススキーマ構成を変更することによって行われます。 これを実行するには、インストゥルメントまたはコンシューマを有効または無効にします。 事前フィルタリングは、パフォーマンススキーマによって行われ、すべてのユーザーに適用されるグローバルな効果を持ちます。
事前フィルタリングを使用する理由:
オーバーヘッドを削減するため。 パフォーマンススキーマのオーバーヘッドは、すべてのインストゥルメントを有効にしていても最小であるはずですが、さらに縮小したいと考える可能性があります。 または、タイミングイベントに関心がなく、タイミングオーバーヘッドを解消するために、タイミングコードを無効にしたいと考えます。
関心のないイベントの現在のイベントまたは履歴テーブルへの入力を妨げるため。 事前フィルタリングにより、これらのテーブル内に、有効なインストゥルメントの種類の行のインスタンス用に多くの「空き」を残します。 事前フィルタリングでファイルインストゥルメントのみを有効にしている場合、非ファイルインストゥルメントの行は収集されません。 事後フィルタリングで、非ファイルイベントが収集され、ファイルイベントの少ない行が残されます。
特定の種類のイベントテーブルの保守を回避するため。 コンシューマを無効にすると、サーバーはそのコンシューマの宛先の保守に時間を費やさなくなります。 たとえば、イベント履歴に関心がない場合、履歴テーブルコンシューマを無効にして、パフォーマンスを向上できます。
-
事後フィルタリング. これには、クエリー内で、パフォーマンススキーマテーブルから情報を選択する
WHERE句を使用して、使用可能なイベントのうち表示したいものを指定することが含まれます。 事後フィルタリングは、各ユーザーが使用可能なイベントのうち関心のあるものを選択するため、ユーザー単位で実行されます。事後フィルタリングを使用する理由:
関心のあるイベント情報に関して、個々のユーザーの決断を避けるため。
事前フィルタリングの使用に課せられる制限が前もってわからない場合に、パフォーマンススキーマを使用して、パフォーマンスの問題を調査するため。
次のセクションでは、事前フィルタリングの詳細を説明し、フィルタリング操作でインストゥルメントやコンシューマを指定するためのガイドラインを提供します。 情報を取得するためのクエリーの書き方 (事後フィルタリング) については、セクション27.5「パフォーマンススキーマクエリー」を参照してください。