複数CPUのスケーリング

プロトタイプとしてのデモ・アプリケーションの実行

パフォーマンスへの影響: 不定

TimesTenで実行される概算スケーリングを確認する方法の1つとして、使用しているシステムでいずれかのスケーラブル・デモ・アプリケーション(tptbmなど)を実行する方法があります。

tptbmアプリケーションには、マルチユーザーのスループット・ベンチマークが実装されています。これでは、TimesTen処理およびSELECT、UPDATE、INSERTなどを組み合せたトランザクションを実行するプロセス数を変更するオプションを含め、その実行方法を制御できます。tptbm -helpを実行すると、オプションの完全なリストが表示されます。

デフォルトでは、このデモは、トランザクションごとに1つの処理を実行します。トランザクションごとの処理数を増やして、実際のアプリケーションに近づけることができます。トランザクションが大きくなると、アプリケーションのプロファイルによって、スケーラビリティが向上する場合と低下する場合があります。

このデモのマルチプロセッサ・バージョンを実行すると、複数CPUシステムでのアプリケーションのパフォーマンスを予測して評価できます。デモでのスケーラビリティが高く、アプリケーションでのスケーラビリティが低い場合は、アプリケーションを簡略化して問題の箇所を確認します。TimesTenのコールをコメント・アウトしても、アプリケーションに問題があるためスケーリングが不十分なままになる場合があります。

また、たとえば、シミュレートされたアプリケーション・データの一部が正しく生成されていないため、数行の同じ行がすべての処理でアクセスされていることが発見される場合があります。アクセスでデータが変更される場合、そのタイプのローカライズされたアクセスは、スケーラビリティを大幅に阻害することになります。

tptbmおよびその他のデモ・アプリケーションの詳細は、クイック・スタートのホームページ(installation_dir/quickstart.html)を参照してください。「Sample Programs」の下のODBCリンクに移動してください。

CPU当たりのデータベース集中型接続の数の制限

パフォーマンスへの影響: 不定

SYS.SYSTEMSTATS表のlock.timeoutsフィールドまたはlock.locks_granted.waitフィールドを確認します。これらの値が大きい場合は、過度の競合が発生している可能性を示し、スケーリングが不十分になることがあります。

TimesTenはCPU集中型であるため、CPU当たりのデータベース集中型の接続の数を1つのみにすることで、最適なスケーリングが実現されます。4CPUシステムまたはハイパースレッド機能を持つ2CPUシステムを使用する場合、4プロセッサ・アプリケーションのパフォーマンスは良好ですが、8プロセッサ・アプリケーションのパフォーマンスは低くなります。アクティブなスレッド間での競合が多くなりすぎます。ただし、多くのトランザクションが永続的にコミットされる場合、このルールは適用されません。この場合、ファイル・システムへのI/O操作が増加するために接続が極度にCPU集中型にはならず、システムでより多くの同時接続をサポートできるようになります。

読取り処理の使用(使用可能な場合)

パフォーマンスへの影響: 不定

読取り処理のスケーラビリティは、書込み処理より優れています。読取りと書込みのバランスが、アプリケーションの実際のワークロードを反映していることを確認してください。

準備、再準備および接続の制限

パフォーマンスへの影響: 不定

準備はリソースを大量に消費する操作であり、SQL実行操作よりもスケーラビリティがありません。可能なかぎり、パラメータ化されたSQL文を使用し、常に、複数回実行される文を事前に準備してください。

SYS.SYSTEMSTATS表のstmt.prepares.count列は、アプリケーションによって文が直接準備された頻度を示します。stmt.prepares.count列の値が大きい場合は、次のことを確認します。

アプリケーションでパラメータ化された文が使用されています。
アプリケーションでは該当するSQL文を1回のみ準備し、単一の実行ごとには準備していません。
アプリケーションではデータベースから頻繁に接続および切断しません。している場合は、アクティブな期間が長い接続を使用することを検討してください。

接続および切断操作は、リソースを大量に消費し、スケーラビリティを損なう操作となります。アプリケーションでの接続および切断操作の数を最小化してください。パフォーマンスを高めるには、パラメータ化され再準備されたSQL文を使用して、長期間のアクティブな接続を使用します。

アプリケーションで頻繁な接続および切断操作を回避できない場合、または存続期間が長い接続を使用するようにアプリケーションを変更できない場合は、接続プーリングを使用することを検討してください。接続プーリングは、接続および切断操作の頻度を減らし、アプリケーションがデータベースから頻繁に接続および切断する場合よりも準備済の文の利用率を向上させることができます。

リカバリ時の索引再構築のパラレル実行

パフォーマンスへの影響: 不定

マルチプロセッサ・システムでは、RecoveryThreadsを最小値に設定すると(使用可能なCPUの数、索引の数)、リカバリが必要な場合に、索引をパラレルで再構築できるようになります。

再構築が必要な場合、進行状況はユーザー・ログで確認できます。RecoveryThreadsを使用可能なCPUの数より大きい値に設定すると、リカバリに必要な時間が、シングルスレッドの場合より長くなります。

プライベート・コマンドの使用

パフォーマンスへの影響: 不定

複数の接続で同じコマンドを実行する場合、それらの接続は、1つのコマンド・ロックによって制御される共通のコマンド構造にアクセスします。コマンドの共有およびロックへの競合を回避するには、PrivateCommandsを1に設定します。

プライベート・コマンドを使用すると、使用する一時領域の量が増えますが、コストに見合った調整が容易になります。

『Oracle TimesTen In-Memory Databaseリファレンス』のPrivateCommandsを参照してください。