パフォーマンススキーマは、DBA が「大まかな推量」ではなく、実際に測定して、パフォーマンスのチューニングを行うのに役立つツールです。 このセクションでは、この目的でパフォーマンススキーマを使用するいくつかの方法について説明します。 ここでの説明は、セクション27.4.2「パフォーマンススキーマイベントフィルタリング」で説明しているイベントフィルタリングの使用に依存します。
次の例では、パフォーマンスボトルネックの調査など、反復される問題の分析に使用できる 1 つの方法を示しています。 開始するには、パフォーマンスが「遅すぎる」とみなされ、最適化が必要な反復可能なユースケースが必要であり、すべてのインストゥルメンテーションを有効にすべきです (事前フィルタリングなし)。
ユースケースを実行します。
パフォーマンススキーマテーブルを使用して、パフォーマンスの問題の原因を分析します。 この分析は、フィルタリング後に大きく依存します。
除外する問題領域については、対応するインストゥルメントを無効にします。 たとえば、問題が特定のストレージエンジンのファイル I/O に関連していないことが分析に示されている場合、そのエンジンのファイル I/O インストゥルメントを無効にします。 次に、履歴およびサマリーテーブルを切り捨て、これまでに収集されたイベントを削除します。
-
ステップ 1 のプロセスを繰り返します。
反復のたびに、パフォーマンススキーマの出力 (特に
events_waits_history_longテーブル) に含まれる「「ノイズ」」の数が少なく、重要でないインストゥルメントによって発生する「「ノイズ」」が少なくなり、このテーブルのサイズが固定されている場合は、手動での問題の分析に関連するより多くのデータが含まれます。「signal/noise」 比率が改善され、分析が容易になるため、反復ごとに調査が問題の根本原因に近づいて近づく必要があります。
-
パフォーマンスボトルネックの原因を突き止めたら、次のような適切な修正措置をとります。
サーバーパラメータ (キャッシュサイズ、メモリーなど) をチューニングします。
クエリーを違う方法で書いてチューニングします。
データベーススキーマ (テーブル、インデックスなど) をチューニングします。
コードをチューニングします (これはストレージエンジンまたはサーバー開発者のみに適用されます)。
ステップ 1 から再開して、パフォーマンスへの変更の効果を確認します。
mutex_instances.LOCKED_BY_THREAD_ID および rwlock_instances.WRITE_LOCKED_BY_THREAD_ID カラムは、パフォーマンスボトルネックまたはデッドロックの調査にきわめて重要です。 これは、次のようなパフォーマンススキーマインストゥルメンテーションによって可能になります。
スレッド 1 は相互排他ロックを待機してスタックしているとします。
-
スレッドが何を待機しているかを特定できます。
SELECT * FROM performance_schema.events_waits_current WHERE THREAD_ID = thread_1;たとえば、
events_waits_current.OBJECT_INSTANCE_BEGINにあるように、スレッドが相互排他ロック A を待機していることがクエリー結果に示されます。 -
相互排他ロック A を保持しているスレッドを特定できます。
SELECT * FROM performance_schema.mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;たとえば、
mutex_instances.LOCKED_BY_THREAD_IDにあるように、相互排他ロック A を保持しているのがスレッド 2 であることがクエリー結果に示されます。 -
スレッド 2 が何を実行しているかを確認できます。
SELECT * FROM performance_schema.events_waits_current WHERE THREAD_ID = thread_2;