| Oracle® Fusion Middleware Oracle Enterprise Data Qualityの管理 12c (12.1.3) E59395-01 |
|
 前 |
 次 |
この章では、EDQシステムのパフォーマンスを最適化するために使用できるサーバーのプロパティについて、およびそのプロパティの様々な環境での構成方法について説明します。
内容は次のとおりです。
EDQには、システムの様々な側面を構成するために使用される多くのプロパティがあります。これらのうち比較的少数がシステムのパフォーマンス特性の制御に使用されます。
EDQでのパフォーマンス・チューニングは多くの場合CPUコアという言葉で説明されます。この章では、これはRuntime.availableProcessors()メソッドへのコールにより返される、Java仮想マシンによりレポートされるCPUの数のことです。
チューニング制御はdirector.propertiesファイル内のプロパティとして公開されます。このファイルはoedq_local_home構成ディレクトリにあります。
使用できるチューニング・プロパティは次のとおりです。
|
|
このプロパティは、起動された各バッチ・ジョブに使用されるスレッドの数を決定します。このプロパティのデフォルト値はゼロで、これは使用可能な各CPUコアに対しシステムが1スレッドを開始することを意味します。このプロパティの値にゼロ以外の正の整数を指定して、スレッドの数を明示的に指定できます。たとえば、各バッチ・プロセスに合計で4スレッドを開始する場合は、 |
|
|
このプロパティは、間隔モードで実行中に各プロセスで使用されるスレッドの数を決定します。これは、同時に処理できるリクエストの数も定義します。デフォルトの動作では、間隔モードで実行中の各プロセスに対し1スレッドが実行します。 |
|
|
このプロパティは、データの結果データベースへの書込みに使用されるスレッドの数を決定します。これらのスレッドはシステム全体の結果および出力データのキューにサービスを提供するので、システムで実行しているすべてのプロセスで共有されます。このプロパティのデフォルト値はゼロで、これは使用可能な各CPUコアに対しシステムが1出力を使用することを意味します。このプロパティの値にゼロ以外の正の整数を指定して、出力スレッドの数を明示的に指定できます。たとえば、各バッチ・プロセスに合計で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に設定することができます。プロセス数と同じスレッド数を使用することで、リクエストの最大数を同時に処理できるようになります。
|
注意:
|
JVMパラメータはEDQのインストール中に構成する必要があります。詳細は、『Oracle Fusion Middleware Enterprise Data Qualityのインストールと構成』を参照してください。パフォーマンスを改善するためにこれらのパラメータをインストール後にチューニングする必要が生じた場合、この項の手順に従います。
|
注意: この項のすべての推奨事項はJava HotSpot仮想マシンを使用するEDQインストールに基づきます。実装の性質により、これらの推奨事項は他のJVMにも適用されることがあります。 |
次のエラー・メッセージがログ・ファイルに記録された場合、使用可能な最大PermGen領域を増加する必要があります。
java.lang.OutOfMemoryError: PermGen space
これを行うには、EDQサーバーのJVMで-XX:MaxPermSizeパラメータの値を変更します。-XX:ReservedCodeCacheSizeパラメータを比例的に変更する必要もあります。たとえば、MaxPermSizeを1024mから2048mに倍増する場合、ReservedCodeCacheSizeも倍増する必要があります。
EDQ内でのパフォーマンス・チューニングに関する最も重大なデータベース・チューニング・パラメータはworkunitexecutor.outputThreadsです。このパラメータは、結果データおよびステージング済データの結果データベースへの書込みに使用されるスレッドの数、よってデータベース接続の数を決定します。アプリケーション・サーバーで実行中のすべてのプロセスはこのスレッドのプールを共有するので、特定の環境では処理がI/Oバウンドになるリスクがあります。CPUの使用率と比較して特にI/O集中になっているプロセスがあり、データベース・マシンがEDQアプリケーション・サーバーをホストしているマシンよりもより強力な場合、workunitexecutor.outputThreadsの値を増加することが適切な場合があります。追加のデータベース・スレッドはデータベースへのより多くの接続を使用し、データベースにより多くの負荷をかけます。
特定の状況下では、クライアントのヒープ・サイズの問題が発生することがあります。次に例を示します。
大規模なデータをクライアント側のExcelファイルにエクスポートしようとした場合。
多数のグループがある場合に一致レビューを開いた場合。
EDQでは、クライアントのヒープ・サイズの調整にblueprints.propertiesファイルのプロパティを使用できます。
すべてのJava Web Startクライアント・アプリケーションのデフォルトの最大クライアント・ヒープ領域を2倍にするには、EDQサーバーのconfig/propertiesディレクトリでblueprints.propertiesファイルを作成して(すでに存在する場合はそれを編集して)、次の行を追加します。
*.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
