ヘッダーをスキップ
Oracle TimesTen In-Memory Databaseオペレーション・ガイド
リリース7.0
E05167-03
  目次へ
目次
索引へ
索引

前へ
前へ
次へ
次へ
 

マルチCPUへのスケーリング

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

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

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

tptbmアプリケーションには-procパラメータがあり、このパラメータによってTimesTen処理を実行するプロセスの数を変更できます。また、このアプリケーションには、READ、WRITEおよびINSERTを組み合せたトランザクションを指定するための他のパラメータもあります。

tptbm -helpを実行すると、オプションの完全なリストが表示されます。たとえば、ハッシュ索引またはTツリー索引のいずれをtptbmで使用するかを指定できます。

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

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

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

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

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

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

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

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

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

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

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

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

準備にはスケーラビリティがありません。複数回実行されるコマンドは事前に準備するようにしてください。SYS.MONITOR表のCMD_PREPARESおよびCMD_REPREPARES列に、コマンドが準備された回数、または(索引の作成および削除が原因で)コマンドが自動的に再準備された回数が示されます。いずれかの値が大きい場合は、接続プーリングを実行するようにアプリケーションを変更して、接続の確立および切断がほとんど発生しないようにします。

接続にはスケーラビリティがありません。複数回実行されるコマンドは事前に準備するようにしてください。SYS.MONITOR表のDS_CONNECTS列を参照します。このフィールドの値が大きい場合は、接続プーリングを実行するようにアプリケーションを変更して、接続の確立および切断がほとんど発生しないようにします。

レプリケーションのトランスミッタとレシーバおよびXLAリーダーの制限

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

レプリケーション処理およびXLA処理では、大量のロギングのオーバーヘッドが発生します。レプリケーションのスケーラビリティは、トランスミッタまたはレシーバ(あるいはその両方)の数が制限されている場合に最も高くなります。レプリケーションのトポロジを調べ、簡略化できるかどうか確認します。通常、XLAのスケーラビリティは、リーダーの数が制限されている場合に最も高くなります。アプリケーションのリーダー数が多い場合は、その数を削減できるかどうかを確認します。

XLAおよびレプリケーションを監視して、読取りがディスクからではなく、ログ・バッファから行われていることを確認してください。同時実行される更新が多いと、レプリケーションが処理されない場合があります。サブスクライバでは、更新はシングルスレッドです。確認の頻度が減少すると、XLAのスループットを向上できます。

SYS.MONITOR表のLOG_FS_READS列およびLOG_BUFFER_WAITS列の値を確認して、必要なリーダーおよびトランスミッタの数を見積もります。この情報は、接続が確立または解放されるたび、およびトランザクションがコミットまたはロールバックされるたびにシステムによって更新されます。

LogFlushMethod=2を設定すると、RETURN TWOSAFEレプリケーション処理、およびDURABLE TRANSMITが指定されたRETURN RECEIPT処理のパフォーマンスを向上できます。

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

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

マルチプロセッサ・システムでは、RecoveryThreadsを最小値(使用可能なCPUの数、索引の数)に設定すると、リカバリが必要な場合に、索引をパラレルで再構築できるようになります。再構築が必要な場合、進行状況はユーザー・ログで確認できます。RecoveryThreadsを使用可能なCPUの数より大きい値に設定すると、リカバリに必要な時間が、シングルスレッドの場合より長くなります。

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

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

マルチプロセッサ・システムでは、複数のスレッドで同じコマンドを実行する場合、スループットまたはレスポンス時間を向上させるためにPrivateCommands=1を設定します。プライベート・コマンドを使用すると、使用される一時領域の量が増加します。