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


22.2.3.1 パフォーマンススキーマイベントタイミング

イベントは、サーバーソースコードに追加されたインストゥルメンテーションを使用して収集されます。インストゥルメントはイベントの時間を測定しますが、これはパフォーマンススキーマがイベントにどれくらいの時間がかかるかを知らせる方法です。タイミング情報を収集しないようにインストゥルメントを構成することもできます。このセクションでは、使用可能なタイマーとそれらの特性、およびイベント内のタイミング値を表す方法について説明します。

2 つのテーブルはタイマー情報を提供します。

  • performance_timers は、使用可能なタイマーとそれらの特性を一覧表示します。

  • setup_timers は、どのタイマーがどのインストゥルメントに使用されるかを示します。

setup_timers 内の各タイマー行は、performance_timers に示されているいずれかのタイマーを表している必要があります。

タイマーの精度とそれらに伴うオーバーヘッドの量はさまざまに異なります。使用可能なタイマーとそれらの特性を確認するには、performance_timers テーブルをチェックしてください。

mysql> SELECT * FROM performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE       |      2389029850 |                1 |             72 |
| NANOSECOND  |            NULL |             NULL |           NULL |
| MICROSECOND |         1000000 |                1 |            585 |
| MILLISECOND |            1035 |                1 |            738 |
| TICK        |             101 |                1 |            630 |
+-------------+-----------------+------------------+----------------+

TIMER_NAME カラムには使用可能なタイマーの名前が表示されます。CYCLE は CPU (プロセッサ) サイクルカウンタに基づいたタイマーを表します。特定のタイマーに関連付けられた値が NULL の場合、そのタイマーはプラットフォームでサポートされていません。NULLのない行は、setup_timers で使用できるタイマーを示しています。

TIMER_FREQUENCY は、1 秒あたりのタイマー単位数を示します。サイクルタイマーの場合、頻度は一般に CPU 速度に関連します。示された値は、2.4GHz プロセッサを搭載するシステムで取得されました。ほかのタイマーは固定の数秒に基づきます。TICK の場合、頻度はプラットフォームごとに異なることがあります (たとえば、100 ティック/秒を使用するものや、1000 ティック/秒を使用するものがあります)。

TIMER_RESOLUTION は、タイマー値が一度に増加するタイマー単位数を示します。タイマーの分解能が 10 の場合、その値は毎回 10 ずつ増加します。

TIMER_OVERHEAD は特定のタイマーで 1 つのタイミングを取得するためのオーバーヘッドの最小サイクル数です。タイマーはイベントの開始と終了で呼び出されるため、イベントあたりのオーバーヘッドは表示される値の 2 倍になります。

有効なタイマーを確認し、タイマーを変更するには、setup_timers テーブルにアクセスします。

mysql> SELECT * FROM setup_timers;
+-----------+-------------+
| NAME      | TIMER_NAME  |
+-----------+-------------+
| idle      | MICROSECOND |
| wait      | NANOSECOND  |
| stage     | NANOSECOND  |
| statement | NANOSECOND  |
+-----------+-------------+

mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
    -> WHERE NAME = 'wait';
mysql> SELECT * FROM setup_timers;
+-----------+-------------+
| NAME      | TIMER_NAME  |
+-----------+-------------+
| idle      | MICROSECOND |
| wait      | MICROSECOND |
| stage     | NANOSECOND  |
| statement | NANOSECOND  |
+-----------+-------------+

デフォルトで、パフォーマンススキーマは各インストゥルメントの種類で使用可能な最高のタイマーを使用しますが、ユーザーが別のものを選択することもできます。

待機の時間を測定する場合、もっとも重要な基準は、タイマーの精度を犠牲にする可能性があっても、オーバーヘッドを削減することであるため、CYCLE タイマーを使用することがもっとも適切です。

ステートメント (またはステージ) の実行にかかる時間は、一般に単一の待機の実行にかかる時間より桁違いに大きくなります。ステートメントの時間を測定するために、もっとも重要な基準は、プロセッサの周波数の変更に影響を受けない正確な測定基準を設定することであるため、サイクルに基づいていないタイマーを使用することがもっとも適切です。ステートメントのデフォルトのタイマーは NANOSECOND です。タイマーを 2 回呼び出す (ステートメントの起動時に 1 回、その終了時に 1 回) ことによって発生するオーバーヘッドは、ステートメント自体の実行に使用される CPU 時間と比較して桁違いに小さいため、サイクルタイマーと比較した追加のオーバーヘッドは大きくありません。CYCLE タイマーを使用することにはメリットがなく、欠点だけです。

サイクルカウンタによって提供される精度はプロセッサ速度によって異なります。プロセッサが 1 GHz (10 億サイクル/秒) 以上で実行する場合、サイクルカウンタはナノ秒未満の精度を実現します。サイクルカウンタを使用することは、実際の時間を取得するより、はるかに負荷が小さくなります。たとえば、標準 gettimeofday() 関数は数百サイクルかかる可能性があり、これは 1 秒あたり数千または数百万回発生する可能性のあるデータ収集では、許容できないオーバーヘッドです。

サイクルカウンタには欠点もあります。

  • エンドユーザーは、何分の 1 秒などの時計の単位でタイミングを知ることを期待します。サイクルから秒に変換することは大きな負荷がかかる可能性があります。このため、変換はすばやいかなり概算的な乗算演算です。

  • ラップトップが節電モードになったときや熱の生成を抑えるために、CPU の速度が低下したときなどに、プロセッササイクルレートが変わることがあります。プロセッサのサイクルレートが変動した場合、サイクルから実時間単位への変換でエラーが発生することがあります。

  • サイクルカウンタは、プロセッサやオペレーティングシステムによって、信頼できない場合や使用できない場合があります。たとえば、Pentium では、命令は RDTSC (C 命令ではなくアセンブリ言語) であり、理論上オペレーティングシステムはユーザーモードプログラムのその使用を妨げることができます。

  • 異常実行またはマルチプロセッサ同期に関する一部のプロセッサの詳細により、カウンタが最大 1000 サイクルごとに高速になったり、低速になったりするように見えることがあります。

現在、MySQL は、x386 (Windows、OS X、Linux、Solaris、およびその他の Unix フレーバー)、PowerPC、および IA-64 のサイクルカウンタと連携します。

setup_instruments テーブルにはイベントを収集するインストゥルメントを示す ENABLED カラムがあります。このテーブルには、時間が測定されるインストゥルメントを示す TIMED カラムもあります。インストゥルメントが有効にされていない場合、イベントを生成しません。有効にされているインストゥルメントの時間が測定されない場合、インストゥルメントによって生成されたイベントの TIMER_STARTTIMER_END、および TIMER_WAIT タイマー値が NULL になります。これによって、サマリーテーブルの合計、最小、最大、および平均の時間値の計算時に、それらの値が無視されます。

イベント内で、イベントのタイミングの開始時に、有効なタイマーによって指定された単位で時間が保存されます。表示には、選択されたタイマーに関係なく、時間は標準単位に正規化するために、ピコ秒 (1 兆分の 1 秒) で示されます。

setup_timers テーブルへの変更はただちにモニタリングに影響します。すでに進行中のイベントは、開始時間に元のタイマーを使用し、終了時間に新しいタイマーを使用する可能性があるため、予測不可能な結果に至る場合があります。タイマーを変更した場合、TRUNCATE TABLE を使用して、パフォーマンススキーマの統計をリセットする必要がある場合があります。

サーバー起動時のパフォーマンススキーマの初期化で、タイマーベースライン (時間ゼロ) が発生します。イベント内の TIMER_START および TIMER_END 値はベースライン以降のピコ秒を表します。TIMER_WAIT 値はピコ秒での期間です。

イベント内のピコ秒値は概算です。それらの精度は、ある単位から別の単位への変換に伴う通常の誤差の形式に左右されます。CYCLE タイマーが使われ、プロセッサのレートがさまざまに異なる場合、ドリフトが発生することがあります。このため、サーバーの起動から経過した時間の正確な測定基準として、イベントの TIMER_START 値を見ることは妥当ではありません。一方、開始時間や期間によって、イベントを順序付けるために、ORDER BY 句に TIMER_START 値または TIMER_WAIT 値を使用することは適切です。

イベントでマイクロ秒などの値ではなく、ピコ秒を選択したことには、パフォーマンス上の根拠があります。1 つの実装目標は、タイマーに関係なく、統一された時間単位で結果を表示することでした。理想の世界では、この時間単位は時計の単位のように見え、適度に正確である、つまりマイクロ秒です。ただし、サイクルまたはナノ秒をマイクロ秒に変換するには、すべてのインストゥルメンテーションで除算を実行する必要がある場合があります。除算は多くのプラットフォームで高い負荷がかかります。乗算は負荷が高くないため、それを使用しています。そのため、時間単位は、大きな精度の損失がないように十分に大きな乗数を使用した、可能なかぎり最大の TIMER_FREQUENCY 値の整数の倍数です。その結果、時間単位がピコ秒になります。この精度は疑似ですが、この決定によりオーバーヘッドを最小にすることができます。