Red Hat Training

A Red Hat training course is available for Red Hat JBoss Data Virtualization

第2章 プラットフォームの要件

2.1. アーキテクチャーと必要性の評価

最低推奨サイズ
以下の最低条件を開始点としてください。これらの条件は期待される使用量に応じて調整する必要があります。
JBDS (Teiid Designer) – アプリケーションサーバーなし
  • 2 GB の RAM が最低でも必要ですが、大型のモデルにはより多くの RAM が必要です。
  • 最新のプロセッサー
  • インストールされた製品ファイルには 500 MB のディスク領域が必要です。
  • モデルプロジェクトや関連するアーティファクトには 2 GB 以上の領域が必要です。
以下の推奨サイズの目的は、サーバーの開始点 (最小サイズ) を提供することです。
以下は開始点で、推奨される最低条件になります。また、クライアントの情報が取得できないときも推奨サイズとして使用してください。
DV サーバーの最低条件は次のとおりです。
  • 16 GB の JVM メモリーサイズ。
  • 最新のマルチコア (デュアル以上) プロセッサーまたは最新のマルチコアプロセッサーを持つマルチソケットシステム
  • JBoss のサーバー製品と DV コンポーネントには 20 GB 以上のディスク領域が必要です:
  • インストールされた製品のファイルには 1 GB のディスクが必要です。
  • ログファイルとデプロイされたアーティファクトには 5 GB 以上が必要です。
  • BufferManager の maxBufferSpace には 50 GB (デフォルト) が必要です。
  • Modeshape (リポジトリー) が使用される場合、ファイル領域を最低でも 5 GB 増やす必要があります。
JVM フットプリントの最低条件を判断するには、平行性、データボリューム、および計画処理の 3 点を考慮します。
  • 同時性: 最大セッション、トランスポートスレッドプール、エンジンスレッドプール/エンジン (特に最大アクティブ値) の設定、および接続プールサイズを考慮します。
  • データボリューム: バッチサイズを基にデータソースから読み取られるデータの量を考慮します。デフォルトのプロセッサーバッチサイズは 256 で、行ごとに約 2k バイトをターゲットとし、約512kb のサイズでシステムを通過します。しかし、メモリー容量の多いマシンでは、バッチサイズを 512 に増加し、バッチごとにサイズを約 1mb にすることが推奨されます。
  • 計画処理: クエリー計画を基に行われるデータの追加処理を考慮します。通常、これには追加のメモリーが必要です (ソートなど)。
サイズの決定に使用される仮定は次のとおりです。
  • サーバーは調整されているため (スレッドプール、接続プールなど)、待機または最大のスループットなしで各クエリーは実行されます。
  • 計画ではデータソースごとに 1 つのソースクエリーがあります (複雑なクエリーが増えると、さらに多くのメモリーが必要になります)。
  • Teiid と同じ JVM で実行されている他のアプリケーションはありません (同じ JVM で他のアプリケーションが実行される場合は、追加のメモリー要件を考慮する必要があります)。
  • 非トランザクションの直線的な読み取りを実行します (Teiid は、事前にバッチフェッチを行いますが、これはメモリの要件が増えるため、バッチタイプが 2 倍になります)。
  • デフォルトのプロセッサーバッチサイズは 512 に設定されています (256 のデフォルトから変更)。これは、バッチのオーバーヘッドを低減するため、メモリー容量の多いマシンで推奨されます。
最小 JVM サイズを推定する式は (同時クエリー) * (4 * バッチバイト) + (2 * (計画ごとのソースクエリーの数 * ソースバイトの概算)) + オーバーヘッド になります。説明は次のとおりです。
  • 同時クエリー
  • バッチバイト: システムを通過するバッチを表します。256 バッチサイズをデフォルトで使用するとそのバイトサイズは約 512 kb になります。しかし、推奨される 512 バッチサイズを使用すると、各バッチは約 1mb になります。バッチバイトを 2 倍にするのは、別のバッチのプロセス中に部分的なバッチが読み出される場合にワークアイテムでバッチを格納するためです。
  • 2 * バッチバイト
  • 計画ごとのソースクエリー: クエリーのデータソースの数ですが、前提を基に制限されます。
  • 4 * バッチバイトのオンヒープのサイズ
  • オーバーヘッド: AS (約 300mb) の調整、追加の Teiid オーバーヘッド (キャッシュ、計画など)、および接続プールのオーバヘッドが含まれます。他の項目を算出するのは難しいため約 300mb のみが使用されますが、パフォーマンスを向上させるにはこれを検討する必要があります。
使用される正確な式は次のとおりです。
  • (同時クエリー) * (4 * バッチバイト) + (2 * ソースバイト) * ソースクエリーの数 + 300mb
  • (同時クエリー) * (4 * 1mb) + (2 * 512kb) * ソースクエリーの数 + 300mb
  • (同時クエリー) * (4mb) + (1mb) * ソースクエリーの数 + 300mb
  • 同時実行の数 * (5mb) * #ソースクエリー + 300mb

表2.1 設定

同時実行 ソースクエリーの数
100
200
2
1.3 gb
2.3 gb
5
2.8 gb
5.3 gb
10
5.3 gb
10.3 gb
最大同時クエリーを基に、以下を実行してシステムのエンジンを調整します。
  • maxActivePlans を最大同時クエリーに設定します。
  • maxThreads が maxActivePlans の 2 倍になるように設定します (トランザクションが使用される場合は 3 倍)。
  • 各データソースの最大プールサイズが最大同時ソースクエリーと同じになるように設定します (最大同時maxThreads が maxActivePlans の 5 倍クエリーが最小限になりますが、複数のソースクエリーが作成される原因となるサブクエリーがある場合、状況に応じて最大プールサイズを増加する必要があります)。
  • すべての調整を行った後、サーバーのメモリー容量に余裕がある場合、processBatchSize および connectorBatchSize を増やし (例: それぞれ 512 および 1024)、データソースおよびエンジンからのスループットを増加することを検討してください。メモリー不足の場合は、JVM サイズを増やしてください。6GB 以下のメモリーを持つマシンは 512 のままにし、これよりも大きなメモリーを持つマシンにはより大きなサイズを使用してください。