式キューの調整

式のエンジンは、サーバー・リソース、式カウント、 個々のインストール済み環境の複雑さに応じて調整を必要とする場合があります。 一般に、プロセスでは一度に 1 つのパラメーターに対してパフォーマンスの調整と測定を行い、 それ以上パフォーマンスが向上しなくなるまで繰り返します。 レコードの追跡は維持する必要があります。ハードウェアや使用状況、 セットアップが変更されるたびに、新しい調整が必要です。
管理者は、個々のインストール済み環境ごとに以下のアプリケーションを確認する必要があります。
表 1. 式キューの調整のアプリケーション設定
設定 単位 デフォルト ランタイム* 説明 調整のヒント
formula.queue.maxage 時間 24 はい 式キューの履歴を保持する最大時間数。 実行済みの式のみがプルーニングされます。 これは式を使用して実行されます。 実行済みの項目を保持する目的は、 式の統計 (「拡張」 > 「式キュー」) のため、 および評価ループを確認するためです。 ループを評価する場合、高スループットのセットアップでこの数字を小さくすると、 テーブル・サイズを抑えることができます。
formula.queue.maxsize 項目 500000 はい 式キュー内の最大項目数。 クリーンアップ・タスクでは、履歴のプルーニングによって項目数がこの数値を超えないようにします。 実行済みの式のみがプルーニングされます。 これは、最大存続期間の設定をオーバーライドします。 パフォーマンス向上のためには、 高負荷の期間はキュー履歴のサイズを抑えるように、それ以外の場合は履歴を保存するように、 この数字を調整します。この数字の近似値は、 最大存続期間の平均スループットを少し下回るくらいです。
formula.execution.batch.size 項目 30 はい 割り振りが実行されるたびに 1 つのスレッドに割り振られる式キューの項目数。 項目に「開始済み」のマークが付けられ、スレッドが実行され、完了してから、 新しいバッチが割り振られます。 式は、複数のノードの複数のスレッドで同時に実行されますが、 常に依存性を基準にした発生順に実行されます。キューに入っている 2 つの式が互いに関係がない場合は、 追加された順とは関係なく実行することができます。 式の項目は、別の項目の値に応じて異なることがあります。式の項目は、対応する項目 (式の項目はこの項目の値に依存します) が式の前に実行されなければ、実行されないこともあります。この場合 (並行して処理される場合) は、衝突や順序の不整合、 冗長作業を避けるために割り振りが必要になります。割り振りには少しコストがかかるので、 式の一部は、上記の要件で、および任意の順序で実行されるという条件で、 一度だけ割り振られます。 割り振られる式が多いと、割り振りのオーバーヘッドは節約されますが、 並行性は「ロック」されます (逆も同じです)。一般的な規則は、 式の依存関係チェーンが長い場合はこの数字を少なくし、 依存関係チェーンが短いか、依存関係がほとんどない場合は数字を大きくするというものです。 この値は実行時に変更できるので、最適の条件が見つかるまで調整してください。 10 より小さいか 200 より大きい値は最適値ではありません。
formula.cleanup.interval ミリ秒 1800000 いいえ 式キューをクリーニングする頻度。 ここでは、最大存続期間と最大サイズの設定値が適用されます。キューのプルーニングのみが 実行されます。最初のクリーニングはサーバーの始動時で、 その時点で特別な保守が行われます。さらに、2 週間ごとに、 タイマーによる式の整合性のチェックが実行されます (夜間)。 ほとんどの場合はデフォルトで問題はありません。 スループットが高い場合は、クリーニングに時間がかかりますが、より頻繁に実行する必要があります (逆も同じです)。 したがって、この時間をあまり大きくしないように気をつけてください。 時間を増やしすぎると、負荷が急に増えたとき (例えば属性のインポートや追加の後など) に、実行が停止したり、パフォーマンスが落ちたりといった現象が起こることがあります。
formula.background.interval ミリ秒 10000 いいえ まだ割り振られていない新しい式を実行する式キューの 確認の頻度。バッチが完了した場合は、 この間隔を待たずにすぐに新しい確認が行われます。 次の間隔が過ぎてもキューが「実行」されない場合は、 新しいワーカー・スレッドが spawn されるため、労力は倍になります。 Rational® Focal Point™ の初期のバージョンでは、実行は非同期で即時に行われていました。 式がデータベースに移動すると、 このようなことをデッドロックのリスクを伴わずに実行することは不可能になりました。 これは、実行する新しい式について式キューを確認する間隔です。 つまり、ユーザーは最大限この時間 (プラス実行時間)、 式の実行を待たなければなりません。この間隔が短すぎると、 リソースを無駄に消費するだけになります。これはまた、 並行性の増加にも影響を与えます。前回の間隔時に開始されたワーカー・スレッドが、 その間隔の終わりまでに完了しない場合は、別のスレッドが (thread.per.nodes まで) 開始されます。 増加の程度がゆるやかなら、この数字を小さくすることができます。式がめったに使用されない場合は、 数字を少し大きくすることができます。
formula.max.background.threads.per.node count 2 いいえ 各ノードで式を実行する並行スレッドの最大数。 実際の最大数は、アプリケーションのスレッド・プールに空きスレッドがあるかどうかによって 動的に変わります。 background.interval に記述されている並行性の増加によって、 実行する作業が増えれば、間隔ごとに、ノード上の式評価スレッドの数が増えます。 これが最大であることに注意してください。 これには、コア (仮想またはそれ以外) の数に関連して自動的に調整される、アプリケーションのスレッド・プールに空きスレッドが必要です。 また、プール内の最後のスレッドを消費しないように、 上限が設定されます。この数字は、どの操作も中断されずに実行できるので、実験が可能です。 パフォーマンスの向上は保証されませんが、これは主に、 保持するデータベースの並行性機能によって決まるためです。 キュー内の式が評価されないことが頻繁に起こるようになるのは、この値が小さすぎることを示しています。
formula.cleanup.enabled ブール値 true はい 式キューのクリーンアップはデフォルトで有効になっています。 デバッグ目的以外、またはクリーンアップを禁止する必要があるパフォーマンス測定を実行している場合以外は、 絶対に無効にしないでください。 この設定で調整を行うことはできません。 設定を変更しないでください。デフォルトの「true」のままにしておいてください。

フィードバック