22.15 問題を診断するためのパフォーマンススキーマの使用

パフォーマンススキーマは、DBA が「大まかな推量」ではなく、実際に測定して、パフォーマンスのチューニングを行うのに役立つツールです。このセクションでは、この目的でパフォーマンススキーマを使用するいくつかの方法について説明します。ここでの説明は、セクション22.2.3.2「パフォーマンススキーマイベントフィルタリング」で説明しているイベントフィルタリングの使用に依存します。

次の例では、パフォーマンスボトルネックの調査など、反復される問題の分析に使用できる 1 つの方法を示しています。開始するには、パフォーマンスが「遅すぎる」とみなされ、最適化が必要な反復可能なユースケースが必要であり、すべてのインストゥルメンテーションを有効にすべきです (事前フィルタリングなし)。

1. ユースケースを実行します。

2. パフォーマンススキーマテーブルを使用して、パフォーマンスの問題の原因を分析します。この分析は事後フィルタリングに大きく依存します。

3. 除外する問題領域については、対応するインストゥルメントを無効にします。たとえば、問題が特定のストレージエンジンのファイル I/O に関連していないことが分析に示されている場合、そのエンジンのファイル I/O インストゥルメントを無効にします。次に、履歴およびサマリーテーブルを切り捨て、これまでに収集されたイベントを削除します。

4. ステップ 1 のプロセスを繰り返します。

   繰り返しのたびに、パフォーマンススキーマの出力、特に events_waits_history_long テーブルに格納される、無意味なインストゥルメントによって発生する「ノイズ」が減っていき、このテーブルが固定のサイズである場合、当面の問題の分析に関連するデータが増えていきます。

   繰り返しのたびに、調査は問題の原因に近づいていくはずであり、「シグナル/ノイズ」率が改善するにつれて、分析が簡単になります。

5. パフォーマンスボトルネックの原因を突き止めたら、次のような適切な修正措置をとります。

   • サーバーパラメータ (キャッシュサイズ、メモリーなど) をチューニングします。

   • クエリーを違う方法で書いてチューニングします。

   • データベーススキーマ (テーブル、インデックスなど) をチューニングします。

   • コードをチューニングします (これはストレージエンジンまたはサーバー開発者のみに適用されます)。

6. ステップ 1 から再開して、パフォーマンスへの変更の効果を確認します。

mutex_instances.LOCKED_BY_THREAD_ID および rwlock_instances.WRITE_LOCKED_BY_THREAD_ID カラムは、パフォーマンスボトルネックまたはデッドロックの調査にきわめて重要です。これは、次のようなパフォーマンススキーマインストゥルメンテーションによって可能になります。

1. スレッド 1 は相互排他ロックを待機してスタックしているとします。

2. スレッドが何を待機しているかを特定できます。

   SELECT * FROM events_waits_current WHERE THREAD_ID = thread_1;

   たとえば、events_waits_current.OBJECT_INSTANCE_BEGIN にあるように、スレッドが相互排他ロック A を待機していることがクエリー結果に示されます。

3. 相互排他ロック A を保持しているスレッドを特定できます。

   SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;

   たとえば、mutex_instances.LOCKED_BY_THREAD_ID にあるように、相互排他ロック A を保持しているのがスレッド 2 であることがクエリー結果に示されます。

4. スレッド 2 が何を実行しているかを確認できます。

   SELECT * FROM events_waits_current WHERE THREAD_ID = thread_2;