フローがキューに入れられているか、実行が遅延しています最新情報については、 https://docs.servicenow.com/csh?topicname=design-considerations-consolidated&version=latest を参照してください。 フローの実行で待機時間が発生する場合は、この記事が役に立ちます。 バックグラウンドで実行されるフローは、フロージョブによって実行されます。フローを非同期的に開始/再開する要求があると、イベントが作成され、フロージョブ (2 秒ごとに実行) が作業を取得してフローを実行します。 フローの処理が遅れるのはなぜですか? イベントの受け取りが遅れる理由が 1 つ以上ある可能性があります。 1.イベントのバースト:一括インポート/更新や、多くのレコードに影響を与えるイベント、およびそれらのテーブルレコードにフローが添付されている場合が原因の場合があります。フロー実行の一括要求が作成されます。デフォルトでは、作業を処理する各ノードには 3 つのフローデザイナージョブがあり、処理に時間がかかる場合があります。 この問題を確認するには、sysevent テーブルをクエリし、フィルター名=flow.fireを入力し、ステータスが「準備完了」で始まります。多くのレコードが表示される場合は、処理フローに遅延が生じることが予想されます。 検討事項： フローではなくインポートセットを使用して大規模なインポートを処理する。フロー容量を追加すると、これの影響がわかりますが、常に最後のオプションと見なす必要があります。これを行うには、ノードの数を増やすか、フローエンジンのイベントハンドラージョブの数を増やします。 2.長時間実行されているフロー:一部のフローは完了までに時間がかかります。デフォルトでは、ノードごとに 3 つのフローエンジンイベントハンドラージョブがあるため、これらのスレッドがすべて実行時間の長いフローを実行している場合、そのノードは、実行時間の長いフローが待機中/終了ステージに到達しない限り、新しいフローイベントを処理できません。 sys_flow_context.runtime 値 (ソートの説明) を参照して、実行時間の長いフローコンテキストがあるかどうかを確認できます。sysevent テーブル order by processing_duration および name = flow.fire を参照して、どのイベントに時間がかかっているかを確認する価値があります。(sysevent.instance はフロー context_id) 検討事項： 長時間実行されるフローを避ける。システムの負荷が小さい長時間実行フローを実行する。フロー容量を追加すると、これの影響がわかりますが、常に最後のオプションと見なす必要があります。これを行うには、ノードの数を増やすか、フローエンジンのイベントハンドラージョブの数を増やします。 3.スケジューラーがビジー状態:フローは、スケジューラーの許可によりフローデザイナージョブを介して実行されます。スケジューラーが圧倒されると、フローデザイナージョブがしばらくの間実行するスロットを取得できず、フローキューがバックアップされる可能性があります。STARTSWITH フローエンジンイベントと親 != null という名前でsys_triggerしてフィルタリングする場合は、確認する価値があります。各行next_action、過去 10 分>ないように注意してください。 スケジュール済みジョブが多数ある (sys_trigger行が多い) 場合、フローデザイナージョブがしばらく実行されない可能性があります。 検討事項： 一部のジョブの優先度を 100 >下げると、同じく優先度 100 で実行されるフローエンジンイベントハンドラーとの競合が回避されます。一部の非同期 BR を同期 BR に変更する。 (レコード更新の前または後)100 未満の優先度で実行されるフロージョブを追加します。このオプションについては、開発フローエンジンに相談してください。 4.ジョブの次のアクション:ファイラー名STARTSWITHフローエンジンevent^parent!=NULLでsys_triggerジョブにnext_actionことを確認します。これは過去のことであってはなりません。 検討事項 パフォーマンスチームに相談し、フロージョブのsys_triggerで次のアクションを現在にリセットすることを検討してください 5.十分なフローエンジンイベントハンドラー容量がない: フローエンジンイベントハンドラーの数をノードあたり 1 つに減らす回避策がある古い PRB がありました。単一のフローがスレッド容量を消費する場合、そのノード上の他のすべてのフローがブロックされるため、これはお勧めしません。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