遅いフローやキューに格納されたフローのトラブルシューティング<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } フローの実行が予想よりも遅い場合、この記事は問題の特定と解決に役立ちます。バックグラウンドで実行されるフローは、フロージョブによって処理されます。フローが非同期で開始または再開されると、イベントが作成されます。2 秒ごとに実行されるフロージョブは、これらのイベントを取得し、対応するフローを実行します。 フロー処理の遅延は、いくつかの理由で発生する可能性があります。以下は、いくつかの一般的な原因とその対処方法です。 1.イベントバースト 問題: 多数のイベントが同時にトリガーされると、多くの場合、大量のインポート、更新、またはその他のイベントが原因で、フローにリンクされた多くのレコードに影響を与える可能性があります。これにより、フロー実行要求を処理するシステムのキャパシティが過負荷になる可能性があります。デフォルトでは、各ノードには作業を処理する 3 つのフローデザイナージョブがあり、完了するまでに時間がかかる場合があります。 識別方法:sysevent テーブルで、name=flow.fire および state が ready で始まるレコードを確認します。これらのレコードの多くがイベントバーストを示していることを示します。 ソリューション： 大規模なインポートでは、フローの代わりにインポートセットを使用することを検討してください。最後の手段として、フロー容量を増やしてイベントバーストの影響を軽減します。これを行うには、ノード数を増やすか、フローエンジンイベントハンドラージョブの数を増やします。 2.長時間実行されるフロー 問題: 一部のフローは完了までに時間がかかります。ノードあたりデフォルトの 3 つのフローエンジンイベントハンドラージョブでは、実行時間の長いフローが終了するか待機ステージに達するまで、新しいフローイベントがブロックされる可能性があります。 識別方法:sys_flow_context.runtime 値 (降順でソート) を調べて、長時間実行されているフローコンテキストを見つけます。また、 sysevent テーブルの order by processing_duration と name-flow.fire を確認して、どのイベントに時間がかかっているかを確認します。(sysevent.instance はフロー context_id) ソリューション： 長時間実行されるフローを避けるシステムのアクティビティが低い時間帯に、長時間実行されるフローをスケジュールします。フロー容量を追加します。イベントバーストと同様に、これは最後の手段にすぎません。これを行うには、ノードの数を増やすか、フローエンジンのイベントハンドラージョブの数を増やします 3.ビジースケジューラー 問題: フローは、スケジューラーに依存するフローデザイナージョブを介して実行されます。スケジューラーに負荷がかかると、フローデザイナーのジョブが実行するスロットを確保できず、フローキューにバックアップが作成されることがあります。 識別方法:sys_triggerを確認し、名前STARTSWITHフローエンジンイベントと親 != null でフィルタリングします。各行の next_action に注意してください。過去 10 分を超えてはなりません。スケジュール済みジョブが多数ある (sys_trigger行が多い) 場合、フローデザイナーがしばらく実行されないことがあります。 ソリューション： 一部のジョブの優先度を 100 より大きい優先度に下げます。これにより、同じく優先度 100 で実行されるフローエンジンイベントハンドラーとの競合が回避されます。非同期 BR を同期 BR に変更 (レコード更新の前または後)100 未満の優先度で実行されるフロージョブを追加します。このオプションについては、開発フローエンジンに相談してください。 4.ジョブに対する次のアクション 問題: next_action が filer nameSTARTSWITHflow engine event^parent!=NULLでsys_triggerジョブに大きく過去にないはずです。 解決策： パフォーマンスチームに相談し、フロージョブの次のアクションをsys_trigger現在にリセットすることを検討してください。 5.フローエンジンイベントハンドラーのキャパシティが不足しています 問題: 古い PRB ワークアラウンドにより、フローエンジンイベントハンドラーの数がノードごとに 1 つに減少しましたが、これはお勧めできません。単一のフローがスレッド容量を消費すると、そのノード上の他のすべてのフローがブロックされます。 解決策: com.glide.hub.flow_engine.event_handler.workers を 3 に調整してから、プロパティを削除することを検討してください。 注: Quebec リリース以降、フローイベントは生成されたノードに固定されます。ノードがイベントを処理できない場合、イベントを別のノードに委任するのに com.glide.nowmq.events.max_ready_wait_seconds 秒 (Xanadu リリース以降は 60 秒) かかります。 特定のノードでのイベント処理の XML 統計情報を https://<instance_name>/xmlstats.do?include=flowstatsで確認します。 最新情報については、「 ワークフロースタジオのフロー、サブフロー、およびアクションの一般的なガイドライン」を参照してください。