Performance Perception
CData Virtuality Studio の結果設定では、クエリのパフォーマンスが異なる場合があります。UserはQueryの結果をすぐに見ることができます。これは、結果がCData Virtuality Studio にストリーミングされるためです。特注のクエリを別のデータセットに結合する場合、そのクエリ全体を評価する必要があり、予想以上に時間がかかることがあります。同じことがデータのレプリケーションにも当てはまります。最初の結果のバッチは非常に速く表示されますが、レプリケーションではクエリ全体を評価する必要があり、レプリケーション先への転送がレプリケーションジョブの時間に追加されます。
Using the Monitoring Tool
単一のクエリのパフォーマンスは、Webベースのモニタリングツールを使用して分析することができます。クエリが選択されると、CData Virtuality Server の消費リソースに関する以下の情報が表示されます:
- CPU Utilization - クエリの実行に使用されるCPU の割合。つまり、プッシュダウンできない部分の計算に必要なCData Virtuality Server のリソース;
- メモリバッファ - バッファに格納されているメモリの量 - ガベージコレクションは一定の間隔で未使用のリソースを掃除しますが、すぐには掃除しないため、この情報は正確ではありません;
- ディスクバッファ - メモリに格納できず、ディスクに流出する必要があるメモリ量。SSDはバッファよりもはるかに遅いため、データをディスクバッファに保存する必要が生じると、すぐにパフォーマンスが低下します;
- Total buffers- バッファの総数;
- スレッドによって割り当てられたメモリ- クエリ結果を格納するメモリ・バッファとは対照的に、スレッドによって割り当てられたメモリはプロセス自体のRAM使用量を示します。
以下の例では、あるクエリが2つの異なるテーブルを結合し、その結果を3つ目のデータベースシステムに書き込んでいます:
- CPU使用率が非常に低いのは、クエリが完全にプッシュダウンされ、CData Virtuality Server のクエリエンジンで計算を実行する必要がないためです;
- 結果をターゲット・データベースに書き込む前にメモリに格納するため、メモリ・バッファの使用量が増えます;
- 中間結果の格納はメモリ・バッファで十分なので、ディスク・バッファは使用しません;
- バッファの総数は、予想どおり、メモリバッファと並列で実行されます;
- すべてのクエリはプッシュダウンできるため、クエリ実行のためにメモリが割り当てられることはほとんどありません。
システム上にLONGジョブが存在する場合、同一のクエリのパフォーマンスが異なることがあります。この原因として考えられるのは、クエリと同時に実行されるジョブによってシステムに負荷がかかっていたことです。ジョブ履歴を使用すると、多くのジョブが並列で実行されている時間帯を特定することができます。ボトルネックを取り除く戦略として、負荷の低い時間帯にジョブをスケジューリングし、ジョブを均等に「分散」させる方法があります。従属スケジューリング機能は、他のジョブが完了したときにジョブをキックオフするのに役立ちます。これをさらに拡張するために、ジョブはカスケードでスケジューリングすることができ、同時ではなく前後で実行されます。
パフォーマンス・モニタリング・ツールの詳細については、Performance Monitoringをご参照ください。