SQLトレースと拡張イベントの「オブザーバーオーバーヘッド」の測定

SQL Serverは、サーバーに対して実行されたワークロードに関する診断データとトラブルシューティングデータを収集する2つの方法、SQLトレースと拡張イベントを提供します。 SQL Server 2012以降、拡張イベントの実装はSQL Traceと同等のデータ収集機能を提供し、これら2つの機能によって発生するオーバーヘッドの比較に使用できます。この記事では、さまざまな構成でSQLトレースと拡張イベントを使用するときに発生する「オブザーバーオーバーヘッド」を比較して、リプレイワークロードを使用してデータ収集がワークロードに与えるパフォーマンスへの影響を判断します。キャプチャと分散再生。

テスト環境

テスト環境は、6台の仮想マシン、1台のドメインコントローラー、1台のSQL Server 2012 Enterprise Editionサーバー、および分散リプレイクライアントサービスがインストールされた4台のクライアントサーバーで構成されています。この記事ではさまざまなホスト構成がテストされ、影響の比率に基づいてテストされた3つの異なる構成から同様の結果が得られました。 SQL Server Enterpriseエディションサーバーは、4つのvCPUと4GBのRAMで構成されています。残りの5台のサーバーは、1つのvCPUと1GBのRAMで構成されています。分散リプレイコントローラーサービスは、リプレイに複数のクライアントを使用するためにエンタープライズライセンスが必要なため、SQL Server2012Enterpriseエディションサーバーで実行されました。

テストワークロード

リプレイキャプチャに使用されるテストワークロードは、SQLServerに対してモックワークロードを生成するために昨年作成したAdventureWorksBooksOnlineワークロードです。このワークロードは、Books OnlineのサンプルクエリをAdventureWorksファミリーのデータベースに対して使用し、PowerShellによって駆動されます。ワークロードは4つのリプレイクライアントのそれぞれでセットアップされ、各クライアントサーバーからSQL Serverへの合計4つの接続で実行され、1GBのリプレイトレースキャプチャが生成されました。再生トレースは、SQL Server ProfilerのTSQL_Replayテンプレートを使用して作成され、スクリプトにエクスポートされ、ファイルへのサーバー側トレースとして構成されました。リプレイトレースファイルがキャプチャされると、分散リプレイで使用するために前処理され、リプレイデータがすべてのテストのリプレイワークロードとして使用されました。

再生設定

再生操作は、ストレスモード構成を使用して、テストSQLServerインスタンスに対して最大量の負荷を駆動するように構成されました。さらに、この構成では、思考と接続の時間スケールが短縮され、再生トレースの開始からイベントが実際に発生してから再生操作中に再生されるまでの時間の比率が調整され、イベントを次の場所で再生できるようになります。最大スケール。リプレイのストレススケールも、spidごとに構成されます。再生操作の構成ファイルの詳細は次のとおりです。

<?xml version="1.0" encoding="utf-8"?>
<Options>
  <ReplayOptions>
    <Server>SQL2K12-SVR1</Server>
    <SequencingMode>stress</SequencingMode>
    <ConnectTimeScale>1</ConnectTimeScale>
    <ThinkTimeScale>1</ThinkTimeScale>
    <HealthmonInterval>60</HealthmonInterval>
    <QueryTimeout>3600</QueryTimeout>
    <ThreadsPerClient>255</ThreadsPerClient>
    <EnableConnectionPooling>Yes</EnableConnectionPooling>
    <StressScaleGranularity>spid</StressScaleGranularity>
  </ReplayOptions>
  <OutputOptions>
    <ResultTrace>
      <RecordRowCount>No</RecordRowCount>
      <RecordResultSet>No</RecordResultSet>
    </ResultTrace>
  </OutputOptions>
</Options>

各リプレイ操作中に、次のカウンターのパフォーマンスカウンターが5秒間隔で収集されました。

• プロセッサ\％プロセッサ時間\_合計
• SQL Server \ SQL Statistics \ Batch Requests / sec

これらのカウンターは、サーバー全体の負荷と、比較のために各テストのスループット特性を測定するために使用されます。

構成のテスト

合計7つの異なる構成がDistributedReplayでテストされました：

• ベースライン
• サーバー側のトレース
• サーバー上のプロファイラー
• リモートプロファイラー
• イベントをevent_fileに拡張
• イベントをring_bufferに拡張
• イベントをevent_streamに拡張

各テストを3回繰り返して、結果がさまざまなテスト間で一貫していることを確認し、比較のための平均結果セットを提供しました。最初のベースラインテストでは、SQL Serverインスタンスに追加のデータ収集は構成されていませんが、SQL Server 2012に付属するデフォルトのデータ収集（デフォルトのトレースとsystem_healthイベントセッション）は有効のままになっています。これは、ほとんどのSQL Serverの一般的な構成を反映しています。これは、データベース管理者にメリットがあるため、デフォルトのトレースまたはsystem_healthセッションを無効にすることは一般的に推奨されていないためです。このテストは、追加のデータ収集が実行されていたテストと比較するための全体的なベースラインを決定するために使用されました。残りのテストは、SQL Server Profilerに付属しているTSQL_SPsテンプレートに基づいており、次のイベントを収集します。

• セキュリティ監査\監査ログイン
• セキュリティ監査\監査ログアウト
• Sessions \ ExistingConnection
• ストアドプロシージャ\RPC：開始
• ストアドプロシージャ\SP：完了
• ストアドプロシージャ\SP：開始
• ストアドプロシージャ\SP：StmtStarting
• TSQL \ SQL：BatchStarting

このテンプレートは、テストに使用されたワークロードに基づいて選択されました。これは主に、SQL:BatchStartingによってキャプチャされたSQLバッチです。 イベント、そしてhierarchyidのさまざまなメソッドを使用したいくつかのイベント 、SP:Startingによってキャプチャされます 、SP:StmtStarting 、およびSP:Completed イベント。サーバー側のトレーススクリプトは、SQL Server Profilerのエクスポート機能を使用してテンプレートから生成され、スクリプトに加えられた変更は、maxfilesizeを設定することだけでした。 パラメータを500MBに設定し、トレースファイルのロールオーバーを有効にして、トレースが書き込まれたファイル名を指定します。

3番目と4番目のテストでは、SQL Server Profilerを使用して、サーバー側のトレースと同じイベントを収集し、Profilerアプリケーションを使用したトレースのパフォーマンスオーバーヘッドを測定しました。これらのテストは、SQLServer上でローカルにSQLProfilerを使用して実行され、別のクライアントからリモートで実行され、Profilerをローカルまたはリモートで実行することでオーバーヘッドに違いがあるかどうかを確認しました。

拡張イベントを使用した最終テストでは、SQL Server 2012のトレースから拡張イベントへの変換スクリプトを使用して作成されたイベントセッションに基づいて、同じイベントと同じ列を収集しました。テストには、SQL Serverのevent_file、ring_buffer、および新しいストリーミングプロバイダーの評価が含まれていました。各ターゲットがサーバーのパフォーマンスに課す可能性のあるオーバーヘッドを決定するために、個別に2012年。さらに、イベントセッションはデフォルトのメモリバッファオプションで構成されていましたが、NO_EVENT_LOSSを指定するように変更されました EVENT_RETENTION_MODEの場合 event_fileおよびring_bufferテストのオプションで、サーバー側のトレースの動作をファイルに一致させます。これにより、イベントの損失がないことも保証されます。

結果

1つの例外を除いて、テストの結果は驚くべきものではありませんでした。ベースラインテストでは、13分35秒で再生ワークロードを実行でき、テスト中の1秒あたりの平均バッチリクエスト数は2345でした。サーバー側のトレースを実行すると、再生操作は16分40秒で完了しました。これは、パフォーマンスが18.1％低下します。 Profiler Tracesは全体的にパフォーマンスが最も低く、Profilerがサーバー上でローカルに実行された場合は149分、Profilerがリモートで実行された場合は123分と20秒を要し、パフォーマンスがそれぞれ90.8％と87.6％低下しました。拡張イベントテストは最高のパフォーマンスを発揮し、event_fileに15分15秒、ring_bufferターゲットに15分40秒かかり、パフォーマンスが10.4％と11.6％低下しました。すべてのテストの平均結果を表1に示し、図2にグラフ化します。

表1-すべてのテストの平均結果

図2–結果のグラフ

拡張イベントストリーミングテストは、実行されたテストのコンテキストではかなり公平な結果ではなく、結果を理解するためにもう少し説明が必要です。表の結果から、拡張イベントのストリーミングテストが16分35秒で完了し、パフォーマンスが34.1％低下したことがわかります。ただし、図3に示すように、グラフを拡大してスケールを変更すると、ストリーミングが最初はパフォーマンスにはるかに大きな影響を与え、その後、他の拡張イベントテストと同様の方法で実行を開始したことがわかります。 ：

図3–結果を拡大

これについての説明は、SQL Server 2012の新しい拡張イベントストリーミングターゲットの設計にあります。event_streamの内部メモリバッファーがいっぱいになり、クライアントアプリケーションによって十分な速度で消費されない場合、データベースエンジンはevent_streamは、サーバーのパフォーマンスに深刻な影響を与えないようにします。これにより、図4のエラーと同様のエラーがSQL Server 2012ManagementStudioで発生します。

図4–サーバーによって切断されたevent_stream

結論

SQL Serverから診断データを収集するすべての方法には、「オブザーバーオーバーヘッド」が関連付けられており、高負荷のワークロードのパフォーマンスに影響を与える可能性があります。 SQL Server 2012で実行されているシステムの場合、拡張イベントは最小限のオーバーヘッドを提供し、SQLトレースと同様のイベントと列の機能を提供します（SQLトレースの一部のイベントは拡張イベントの他のイベントにロールアップされます）。イベントデータをキャプチャするためにSQLトレースが必要な場合（拡張イベントデータを活用するためにサードパーティツールが再コーディングされるまで）、ファイルへのサーバー側トレースはパフォーマンスのオーバーヘッドを最小限に抑えます。 SQL Server Profilerは、再生の継続時間が10倍になり、スループットが大幅に低下することからわかるように、ビジー状態の本番サーバーでは回避する必要のあるツールです。

プロファイラーを使用する必要がある場合、結果はSQL Serverプロファイラーをリモートで実行することを好むように見えますが、このシナリオで実行された特定のテストに基づいてこの結論を明確に引き出すことはできません。リモートプロファイラーの結果がSQLServerインスタンスでのコンテキスト切り替えの低下の結果であるかどうか、またはVM間のネットワークがリモート収集のパフォーマンスへの影響を低下させる要因となったかどうかを判断するには、追加のテストとデータ収集を実行する必要があります。これらのテストのポイントは、プロファイラーが実行されていた場所に関係なく、プロファイラーが被る重大なオーバーヘッドを示すことでした。最後に、拡張イベントのライブイベントストリームも、データの収集に実際に接続されている場合はオーバーヘッドが高くなりますが、テストで示されているように、データベースエンジンは、イベントに遅れをとった場合にライブストリームを切断して、深刻な影響を防ぎます。サーバーのパフォーマンス。