4 EDQパフォーマンスのチューニング

この章では、EDQシステムのパフォーマンスを最適化するために使用できるサーバー・プロパティと、様々な状況でそれらのプロパティを構成する方法について説明します。

この章の内容は次のとおりです。

• プロパティ・ファイルの理解

• バッチ処理のチューニング

• リアルタイム処理のチューニング

• JVMパラメータのチューニング

• データベース・パラメータのチューニング

• クライアントのヒープ・サイズの調整

EDQには、システムの様々な状態を構成するために使用するプロパティが数多くあります。これらのうち比較的少数がシステムのパフォーマンス特性の制御に使用されます。

EDQのパフォーマンス・チューニングは、しばしばCPUコアの観点から論じられます。この章では、これはRuntime.availableProcessors()メソッドへのコールにより返される、Java仮想マシンによりレポートされるCPUの数のことです。

プロパティ・ファイルの理解

チューニング制御は、director.propertiesファイル内のプロパティとして公開されています。このファイルはoedq_local_home構成ディレクトリにあります。

使用できるチューニング・プロパティは次のとおりです。

プロパティ	説明
runtime.threads	このプロパティは、起動された各バッチ・ジョブに使用されるスレッドの数を決定します。このプロパティのデフォルト値はゼロで、これは使用可能な各CPUコアに対しシステムが1スレッドを開始することを意味します。このプロパティの値にゼロ以外の正の整数を指定して、スレッドの数を明示的に指定できます。たとえば、各バッチ・プロセスに合計で4スレッドを開始する場合は、runtime.threadsを4に設定します。
runtime.intervalthreads	このプロパティは、間隔モードで実行中に各プロセスで使用されるスレッドの数を決定します。これは、同時に処理できるリクエストの数も定義します。デフォルトの動作では、間隔モードで実行中の各プロセスに対し1スレッドが実行します。

プロパティ	説明
workunitexecutor. outputThreads	このプロパティは、データの結果データベースへの書込みに使用されるスレッドの数を決定します。これらのスレッドはシステム全体の結果および出力データのキューにサービスを提供するので、システムで実行しているすべてのプロセスで共有されます。このプロパティのデフォルト値はゼロで、これは使用可能な各CPUコアに対しシステムが1出力を使用することを意味します。このプロパティの値にゼロ以外の正の整数を指定して、出力スレッドの数を明示的に指定できます。たとえば、各バッチ・プロセスに合計で4スレッドを使用する場合は、workunitexecutor.outputThreadsを4に設定します。

バッチ処理のチューニング

EDQで提供されるデフォルトのチューニング設定は、主としてバッチ処理に使用するほとんどのシステムに適しています。すべての使用可能なコアを使用するジョブの実行時は、十分なスレッドが開始されます。複数のジョブが開始される場合、オペレーティング・システムはコア間の効率的な共有のために作業をスケジューリングできます。オペレーティング・システムがこれらの種類のワークロードのスケジューリングを実行できるようにするのがベスト・プラクティスです。

リアルタイム処理のチューニング

本番システムが大量のリアルタイム処理に使用されている場合、リアルタイムのレスポンスがクリティカルでなくなるまで、同時バッチおよびリアルタイム処理に使用しないでください。バッチ処理はリアルタイム・プロセスにより要求されるデータの処理に限って実行します。

リアルタイム・システムでのバッチ処理のチューニング

バッチ処理をリアルタイム処理に使用されているシステムで実行する必要がある場合、スケジュールされているメンテナンス期間など、リアルタイム・プロセスが停止しているときにバッチ作業を実行することがベスト・プラクティスです。この場合、runtime.threadsはデフォルト設定が適しています。

リアルタイム・サービスが実行している間にバッチ処理を実行する必要がある場合、runtime.threadsの値を、コアの合計数よりも小さく設定します。バッチ・プロセスで開始されるスレッドの数を削減することにより、これらのプロセスが実行時に使用可能なすべてのコアに負荷をかけるのを防ぎます。バッチが実行中に到着するリアルタイム・サービス・リクエストは、CPU時間をめぐってそれと競合することはありません。

リアルタイム・スレッド数のチューニング

ほとんどの本番システムでは、runtime.intervalthreadsのデフォルト値の1が適しています。デフォルト設定は、間隔モードで実行中のプロセスにより処理される指定したリアルタイム・サービスに対し、すべてのリクエストが順次処理されることを示しています。同じサービスに対し4つのリクエストが同時に到着した場合、1つのリクエストを処理する平均時間は100msなので、最初のメッセージは100ms後に処理され、2番目のメッセージは200ms後、などとなります。さらに、すべての作業は1つのコアで実行され、これは4コア・マシン上で3つのコアがアイドルであることを意味します。runtime.intervalthreadsを使用可能なコアの数と同じに設定することがベスト・プラクティスです。この構成では、受信リクエストを同時に処理することが可能で、リソースがより効率的に使用され、ターンアラウンドがより高速になります。開発環境では、runtime.intervalthreadsのデフォルト設定で十分です。

入出力負荷の高いリアルタイム・プロセスのチューニング

プロセスが大量のI/Oを実行する場合、runtime.intervalthreadsの値を使用可能なコアの数よりも増やしてみることができます。プロセスがI/O集中型で実行する場合、すべてのスレッドがディスクのアクティビティの完了を待ち、1つまたは複数のコアがアイドルになっているときがあります。存在するコアよりも多くのアクティブなスレッドを使用することで、1つのスレッドがI/Oのために停止したときに、そのスレッドが使用していたコアを別のスレッドが利用できるようになります。

リアルタイム・プロセスのチューニングの例

このリアルタイム・プロセスのチューニング方法の例では、4コアのIntelサーバーが使用されて4つの異なるWebサービスをサポートしています。WebサービスはCPU集中型で、最小限の入出力を実行します。Webサービスで使用されるデータの一部は、バッチ・モードでのデータの準備プロセスも含み、毎日更新される必要があります。Webサービスは同時リクエストのセットを断続的に受け取ります。夜間に、Webサービスはメンテナンスとデータ準備のために停止します。

このシナリオでは、runtime.threadsプロパティ・セットをデフォルト値のCPUコアごとに1スレッド(この場合は4スレッド)に設定したままにすることが適切です。できるだけ短い時間でデータ準備を実行することを目的に、またプロセスがI/Oバウンドになる可能性がないと想定して、runtime.intervalthreadsプロパティを4に設定することができます。プロセス数と同じスレッド数を使用することで、リクエストの最大数を同時に処理できるようになります。

注:

runtime.intervalthreadsの値を増やすことにより、メモリー要件、特に間隔の回転率が、大幅に増加することになります。

JVMパラメータのチューニング

JVMパラメータはEDQのインストール中に構成する必要があります。詳細は、Enterprise Data Qualityのインストールと構成を参照してください。パフォーマンスを改善するためにこれらのパラメータをインストール後にチューニングする必要が生じた場合、この項の手順に従います。

注:

この項のすべての推奨事項はJava HotSpot仮想マシンを使用するEDQインストールに基づきます。実装の性質により、これらの推奨事項は他のJVMにも適用されることがあります。

PermGen領域の設定

次のエラー・メッセージがログ・ファイルに記録された場合、使用可能な最大PermGen領域を増加する必要があります。

java.lang.OutOfMemoryError: PermGen space

そうするには、EDQサーバーのJVMで、-XX:MaxPermSizeパラメータの値を変更します。-XX:ReservedCodeCacheSizeパラメータを比例的に変更する必要もあります。たとえば、MaxPermSizeを1024mから2048mに倍増する場合、ReservedCodeCacheSizeも倍増する必要があります。

最大ヒープ・メモリーの設定

OutOfMemoryエラー・メッセージがログ・ファイルに記録された場合、最大ヒープ領域パラメータの-Xmxを増加する必要があります。ほとんどの場合、8GBの値で十分です。ただし、大規模なEDQインストールでは、最大ヒープ・サイズを大きくする必要がある可能性があるため、通常は、-Xmxパラメータをサーバー・メモリーの半分の値に設定することをお薦めします。

データベース・パラメータのチューニング

EDQ内でのパフォーマンス・チューニングに関して最も重要なデータベース・チューニングのパラメータは、workunitexecutor.outputThreadsです。このパラメータは、結果データおよびステージング済データの結果データベースへの書込みに使用されるスレッドの数、よってデータベース接続の数を決定します。アプリケーション・サーバーで実行中のすべてのプロセスはこのスレッドのプールを共有するので、特定の環境では処理がI/Oバウンドになるリスクがあります。CPU使用率の割に特別I/Oが集中するプロセスがあり、EDQアプリケーション・サーバーをホストするマシンよりデータベース・マシンのほうが強力である場合は、workunitexecutor.outputThreadsの値を増やすことが効果的な場合があります。追加のデータベース・スレッドはデータベースへのより多くの接続を使用し、データベースにより多くの負荷をかけます。

クライアントのヒープ・サイズの調整

特定の状況下では、クライアントのヒープ・サイズの問題が発生することがあります。次に例を示します。

• 大規模なデータをクライアント側のExcelファイルにエクスポートしようとした場合。

• 多数のグループがある場合に一致レビューを開いた場合。

EDQでは、blueprints.propertiesファイルのプロパティを使用してクライアント・ヒープ・サイズを調整できます。

すべてのJava Web Start クライアント・アプリケーションについてデフォルトの最大クライアント・ヒープ領域を2倍にするには、EDQサーバーのlocal構成ディレクトリにblueprints.propertiesファイルを作成(すでにある場合は編集)します。EDQ構成ディレクトリの詳細は、Oracle Enterprise Data QualityのインストールのEDQディレクトリの要件に関する項を参照してください。

次の行を追加します。

*.jvm.memory = 512m

注:

この値を大きくすると、すべての接続クライアントでヒープ・サイズが512MBに変更されることになります。これに付随して、他のアプリケーションが使用中の場合に、クライアントのパフォーマンスにその影響が及ぶことがあります。

特定アプリケーションのヒープ・サイズを調整するには、アスタリスク(*)を次のリストに示すクライアント・アプリケーションのブループリント名に置き換えます。

• director - (ディレクタ)

• matchreviewoverview - (一致レビュー)

• casemanager - (ケース管理)

• casemanageradmin - (ケース管理の管理)

• opsui - (サーバー・コンソール)

• diff - (構成分析)

• issues - (問題マネージャ)

注:

ダッシュボードはJava Web Startアプリケーションではないため、このプロパティで制御することはできません。

たとえば、ディレクタの最大クライアント・ヒープ領域を2倍にするには、次の行を追加します。

director.jvm.memory = 512m

複数のアプリケーションのクライアント・ヒープ領域を2倍にするには、単にこのプロパティを繰り返します。たとえば、ディレクタと一致レビューについては、次のようになります。

director.jvm.memory = 512m

matchreviewoverview.jvm.memory = 512m