式キュー調整

式エンジンは、サーバー・リソース、式カウント、個々のインストール済み環境の複雑さに応じて調整を必要とする場合があります。 一般に、プロセスでは一度に 1 つのパラメーターに対してパフォーマンスの調整と測定を行い、 それ以上パフォーマンスが向上しなくなるまで繰り返します。 レコードの追跡は維持する必要があります。 ハードウェア、使用状況、およびセットアップが変更されると、新たな調整が必要になります。
管理者は、個々のインストール済み環境ごとに以下のアプリケーション設定を確認する必要があります。
表 1. 式キュー調整のアプリケーション設定
設定 単位 デフォルト 実行時* 説明 調整のヒント
formula.queue.maxage 時間 24 はい 式キュー履歴を保持する最大 (保証はありません) 時間数。 実行された式のみがプルーニングされます。 これは式クリーンアップ・ジョブによって行われます。 式キュー・テーブル内の実行されたキュー項目は、実行履歴として保持されます。 この論理は、実行ループを検査するため、および統計を生成するために使用されます。 統計が不要な場合は、この数値を高スループット・セットアップにおいて小さく設定すると、テーブル・サイズを小さく保つことができます。 適切なループ検査には少なくとも 1 時間の履歴が必要であるため、この値はゼロに設定しないでください。
formula.queue.maxsize 項目数 500000 はい 式キュー内で必要な最大項目数。 クリーンアップ・ジョブは、履歴をプルーニングすることで、項目数をこの数値より小さく保つように試みます。 実行された式のみがプルーニングされます。 この設定は、formula.queue.maxage 設定に優先します。 この数値を小さくすると、負荷の高い期間中に式キュー・サイズを小さく保ち、そうでない場合は履歴を保存することができます。 formula.queue.maxage 期間内の平均スループットをやや下回るように保つ程度が、この数値に適切な見積もり値です。
formula.execution.batch.size 項目数 30 はい 割り振りが実行されるたびに 1 つのスレッドに割り振られる式キューの項目数。 項目には「開始済み」のマークが付けられます。 スレッドはそれらを実行し、新規バッチの割り振り前にそれらを完了します。

これは重要な設定です。 背景情報: 式は、並行して、複数のノードの複数のスレッドで同時に順不同で実行されますが、常に依存性を基準にした発生順に実行されます。 例えば、キュー上の 2 つの式が無関係である場合、それらは追加された順序とは別の順序で実行される可能性があります。 そのため、式項目のインスタンスがあるか、または式項目が依存する項目があると、その式項目は実行されない場合があり、事前には予想できません。 この場合、および並行して実行される場合は、衝突、誤った順序、および重複する作業を避けるために、割り振りが必要になります。

割り振りは負担の大きい操作であるため、上記の要件、および指定の順序で実行される条件のもとでは、複数の式が一緒に割り振られます。 割り振られる式が多いと、割り振りのオーバーヘッドは節約されますが、 並行性は「ロック」されます (逆も同じです)。 一般的な規則は、 式の依存関係チェーンが長い場合はこの数字を少なくし、 依存関係チェーンが短いか、依存関係がほとんどない場合は数字を大きくするというものです。 この値は実行時に変更できるため、最適な条件が見つかるまで調整してください。 10 より小さいか 200 より大きい値は最適値ではありません。

formula.cleanup.interval ミリ秒 1800000 いいえ 式キューをクリーニングする頻度。 これには maxage および maxsize が適用されます。 通常は、キューのプルーニングのみが行われます。 最初のクリーニングはサーバーの始動時に行われます。この時点では特別な保守が行われます。 さらに、2 週間ごとに、 タイマーによる式の整合性のチェックが実行されます (夜間)。 多くの場合、デフォルトが妥当です。 スループットが高い場合は、クリーニングに時間がかかりますが、より頻繁に実行する必要があります (逆も同じです)。 この時間を長くしすぎないように注意してください。 時間を長くしすぎると、負荷が急に増えたとき (例えば属性のインポート後や追加後など) に、実行が停止するか、パフォーマンスが低下するおそれがあります。
formula.background.interval ミリ秒 10000 いいえ まだ割り振られていない新しい式を実行する式キューの 確認の頻度。 バッチが完了した場合は、 この間隔を待たずにすぐに新しい確認が行われます。 次の間隔が発生してもキューにまだ未評価の項目がある場合は、新しいワーカー・スレッドが spawn され、労力が増加します。 Rational® Focal Point™ の初期のバージョンでは、実行は非同期で即時に行われていました。 式がデータベースに移動されると、デッドロックのリスクを伴わないこのような実行は不可能になりました。 これは、実行する新しい式について式キューを検査する間隔、つまりユーザーが式の実行を待たなければならない (read: refresh) 最大時間 (実行時間を除く) です。 未評価キュー項目のポーリングは、このような項目がなければ負担は小さいため、時間は短くなります。 ただし、間隔が短すぎると、リソースが無駄に消費されることになります。 これは、並行性の増加にも影響します。 前の間隔で開始されたワーカー・スレッドが間隔内に終了しないと、別のスレッド (thread.per.nodes まで) が開始されます。 増加が遅すぎる場合、またはより短い評価待ち時間が必要な場合は、この数値を小さくしてください。 式がまれにしか使用されない場合は、この数値をわずかに大きくしてください。
formula.max.background.threads.per.node count 2 いいえ 各ノードで式を実行する並行スレッドの最大数。 実際の最大数は、アプリケーションのスレッド・プールに空きスレッドがあるかどうかによって 動的に変わります。 background.interval に記述されている並行性の増加によって、実行する作業が増えれば、間隔ごとにノード上の式評価スレッドの数が増えます。 このためには、アプリケーションのスレッド・プールに空きスレッドが必要です。 空きスレッドは、CPU コア (仮想または物理) の数に関連して自動的に調整されます。 また、プール内の最後のスレッドを消費しないように、上限が設定されます。 この数値を試すことができます。 良好なパフォーマンスは保証されません。 これは、維持すべきデータベースの並行性能力に大きく依存するためです。 キューに未評価の式が頻繁にある場合、およびデータベース負荷が低い場合は、この値が小さすぎることを示しています。
formula.cleanup.enabled ブール値 true はい 式キューのクリーンアップはデフォルトで有効になっています。 デバッグ目的以外、またはクリーンアップを禁止する必要があるパフォーマンス測定を実行している場合以外は、 絶対に無効にしないでください。 この設定に行うべき調整はありません。 この設定は変更しないでください。 デフォルト値「true」のままにしてください。

* 「実行時」は、アプリケーション設定が実行時に有効である (「はい」で示されています) か、始動時にのみ有効である (「いいえ」で示されています) かを示します。


フィードバック