Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
Slowness because of high memory contention when the job 'Flow Engine Event Handler' is running - Support and Troubleshooting
  • >
  • Knowledge Base
  • >
  • Support and Troubleshooting (Knowledge Base)
  • >
  • Slowness because of high memory contention when the job 'Flow Engine Event Handler' is running
KB0817583

Slowness because of high memory contention when the job 'Flow Engine Event Handler' is running


3926 Views Last updated : Jan 21, 2025 public Copy Permalink
KB Summary by Now Assist

Issue

 

Slowness because of high memory contention when the job 'Flow Engine Event Handler' is running

Cause

 

You can experience slowness on the app node where the job Flow Engine Event Handler is running because of high memory contention, due to flow(s) looping tens of thousands or hundreds of thousands of times in "for each" flow logic.  

Resolution

The workaround is to refactor the flow to take the steps inside the for each loop and move them into a separate subflow. Then either:
1) (pre-Orlando) Create an action with a script step that used scriptable flow api to call the subflow (sn_fd.FlowApi.executeSubflow(...)).  Call this action inside your loop.
2) (Orlando and newer) Use dynamic subflow to call the subflow.  Call this subflow inside your loop.


Either option will cause the subflow execution to occur in a separate context, dividing up the steps and reducing the maximum memory used at any one time. You will know it is working by looking at sys_flow_context table and seeing that a context is created for the parent flow and then subsequent contexts are created for the subflow on each iteration.

You may also see some benefit to changing the property com.snc.process_flow.reporting.level to value to OFF which was previously suggested.

Related Links

1) Documentation will give you more insight on the property com.snc.process_flow.reporting.level: Link: https://docs.servicenow.com/csh?topicname=flow-execution-details.html&version=latest

 

Please see this PRB as well. Most of these high memory issues can be related to this PRB1407971.


The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.