# 动作流执行超时或内存不足等问题解决手册

来源快照：`result_data_new_260518.json`

- 来源 ID：`1227843103339716621`
- 模块：低代码平台e-builder
- 目录：常见问答 - 动作流
- space ID：`1157961794811633670`
- 原文链接：未提供
- 产品基线：未提供

## 正文

# 动作流执行超限问题解决手册

### 一、什么是“动作流并发控制”？

  简单来说， 动作流并发控制就是给动作流设置的“安全红线”，防止它“跑的太疯”把系统搞宕机。

你可以把动作流并发控制设置想象成交通信号灯系统：

动作流就像路上的车辆

服务器资源就像道路的宽度和长度

执行设置就是交通信号灯和限速标志

如果没有信号灯和限速标志：

车辆可能拥堵在一起（并发过多）

有些车开得太久不结束（执行时间过长）

大货车占满道路（内存使用过大）

车辆绕圈不停（循环次数过多）

一次运送太多货物（单次查询数据量过大）

动作流并发控制就是为了防止这些问题，确保“交通”顺畅，系统稳定运行。

二、

### 动作流并发控制的作用

在低代码平台中，“动作流”是一系列自动执行的操作步骤。而 **“动作流并发控制”**  就是平台提供的、对这一个动作流的运行过程进行资源限制和保护的配置功能。

 

它主要控制以下**五个核心指标** ：

控制指标| 作用| 原因  
---|---|---  
**并发数量**|  同一时间，允许这个动作流运行多少个实例。| 防止瞬间涌入太多请求，像“踩踏事件”一样堵死服务器。  
**最长执行时间**|  这个动作流单次运行最多能持续多久。| 防止某个动作流“卡死”，长期霸占资源不释放。  
**最大运行内存**|  这个动作流运行过程中，最多能占用多少内存空间。| 防止动作流加载过大数据（如巨型Excel），吃光服务器内存导致整个系统瘫痪。  
**最大循环次数**|  动作流里的循环组件最多能重复执行多少次。| 防止因为逻辑错误写出“死循环”，无限消耗资源。  
**数据源单次查询最大条数**|  执行一次数据源查询，最多能返回多少条数据。| 防止一次查询拉取百万条数据，压垮数据库和网络。  
  
 

**目的** ：不是为了限制用户，而是为了**保护整个系统的稳定性和所有用户的体验** ，让每一个动作流都能在安全、合理的范围内可靠地完成工作。

三、

### 动作流设置指引

具体操作说明参考执行设置文档：

[https://www.e-cology.com.cn/sp/doc/docDetail/1139882224522305645](https://www.e-cology.com.cn/sp/doc/docDetail/1139882224522305645)

 

入口：进入后台管理， 平台引擎->ESB中心->动作流列表 ->对应动作流 -> 更多设置->设置（10.0.2510.01及以上叫 设置，低于10.0.2510.01基线叫 执行设置）

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843262132002817&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

![](https://weapp.eteams.cn/papi/file/preview?fileId=1228151550504386576&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

 

四、

### 快速定位问题与解决

1、

找到动作流执行失败的记录。

2、

查看错误信息中的关键词：

超时 → 检查【最长执行时间】设置

内存 → 检查【最大运行内存】设置

循环次数→ 检查【最大循环次数】设置

查询条数 → 检查【数据源单次查询最大条数】设置

限流 → 检查【并发数量】限制

3、

**先****按常见问题类型分析优化动作流配置，****再****调整修改最大限制；**

4、

如果你的业务确实需要处理更大数据、运行更长时间，可申请特殊调整：

如需解除限制，申请流程：

需发送邮件至chengxin@weaver.com.cn，格式如下： 

邮件标题：动作流限制放开申请

客户名称：XXX

申请人：XXX

申请放开限制：（附上限制报文截图）

声明：我已知晓动作流该限制是为了防止：在大数据量、高并发情况下，可能引发的系统性能（卡慢、宕机等）问题。经我方综合评估，愿意承担放开限制后可能引发的后续性能问题。

 

五、

### 常见问题（FAQ）

1.

#### 动作流执行超时怎么办

问题1：动作流报文日志提示：“执行失败，动作流执行超时，超时时间：100 seconds”

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843257802211332&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

##### 为什么会这样？

动作流里某个步骤处理时间太长

循环次数设置太多，一直执行不完

等待外部系统（如数据库、第三方接口、其他服务）响应时间太长

##### 如何确定超时原因？

**示例场景1：**

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843257802211331&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

**第一步：检查是否存在某个步骤处理时间过长**

根据动作流报文日志组件右上角确认【耗时】：（1秒=1000毫秒）

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843266468913154&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

可得出DML操作组件耗时120.06秒=2分钟，耗时过大

检查后发现是SQL查询的步骤太慢，于是：

1、给数据库查询添加索引优化

2、将一次查询10万条数据改为每次查询1万条，分10次处理

3、将【最长执行时间】从100秒调整为300秒

问题解决！

问题2：动作流报文日志提示：“执行失败，动作流执行超时，超时时间：600 seconds”

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843262132002821&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)根据此提示可确认用户已经调整【最长执行时间】至最大了

**第二步：检查动作流配置是否合理**

**示例场景2：**

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843253540798467&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

根据动作流报文日志可确认配置了循环且双层嵌套：

再点击动作流报文右上角【查看原始数据】按钮检查确认循环耗时：

第一个循环costTime：109616ms=109.616s

第二个循环，循环到第56次时超时终止了

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843270685335555&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843270830989312&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843266468913156&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

由上可知循环次数过多导致数据操作超时，且双层嵌套循环影响执行效率和性能。于是：拆分动作流：

1、第一层循环可用定时批量触发代替

2、第二层循环可采用分批循环

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843257872564226&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

问题即可解决！

如果循环内部有很多耗时操作，可通过MQ的方式进行异步处理，具体操作说明参考配置文档：

[ _https://www.e-cology.com.cn/sp/doc/docDetail/2002040845295057123_](https://www.e-cology.com.cn/sp/doc/docDetail/2002040845295057123 "https://www.e-cology.com.cn/sp/doc/docDetail/2002040845295057123")

#####  怎么解决？

由以上示例场景总结可得动作流执行超时的解决方案如下：

###### 方法一：优化动作流设计

**减少不必要的循环**

检查循环组件是否真的需要

如果循环是为了处理多条数据，考虑是否可以分批处理

**拆分复杂动作流**

如果一个动作流步骤太多，考虑拆分成多个小动作流

使用“触发动作流”组件连接它们

**优化慢步骤**

检查是否有调用外部接口的步骤响应很慢

考虑是否可以使用缓存减少重复查询

###### 方法二：检查并调整“最长执行时间”设置

1.

进入动作流执行设置页面；入口见目录：动作流设置指引。

2.

找到【最长执行时间】选项；

3.

根据你的业务需求调整：

如果是高频执行的动作流：建议 ≤ 100秒

如果是低频执行的动作流：建议 ≤ 600秒

4.

保存设置

 

 

 

2.

#### 动作流内存超出限制怎么办

**示例场景1：** 动作流报文日志提示：“执行失败，内存超出动作流最大运行内存限制，可在动作流列表 -> 执行设置  -> 最大运行内存中设置。threshold=4096KB；size=5922KB；”

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843253622906881&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

##### 为什么会这样？

一次加载了太多数据到内存中

变量或缓存占用过多，没有及时清理

图片、文件等大对象处理不当

##### 如何确认当前动作流内存大小

点击查看动作流实例报文日志，点击右上角的【查看原始数据】复制粘贴到txt文档里查看一下文档大小，1MB = 1024KB，确认当前动作流内存大小

![](https://weapp.eteams.cn/papi/file/preview?fileId=1247869358883479561&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

##### 如何确定内存超限原因？

由以上报文日志可确定内存大小5922KB，DML操作组件中的数据量较大导致。且已经超过低频执行的动作流【最大运行内存】4096KB。此情况可根据实际情况申请解除限制或者优化DML操作中的SQL。

 

如需解除限制，需发送邮件至chengxin@weaver.com.cn，格式如下： 

邮件标题：动作流限制放开申请

客户名称：XXX

申请人：XXX

申请放开限制：（附上限制报文截图）

声明：我已知晓该限制是为防止大数据量、高并发引发的系统性能问题，愿意承担放开后的风险。

**示例场景2：** 动作流报文日志提示：“执行失败，内存超出动作流最大运行内存限制，可在动作流列表 -> 执行设置  -> 最大运行内存中设置。threshold=10240KB；size=14274KB；”

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843270656802816&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

根据动作流报文日志可确定最大运行内存已经放开到10MB了，现在都有15MB+了，且表单数据中存在大量图片及文件。

因此：尽量压缩图片大小，不能太大，压缩图片后问题得以解决。

 

**示例场景3：** E10调用E9接口传数据的时候，出现这个动作流报文日志提示：“执行失败，内存超出动作流最大运行内存限制，可在动作流列表 -> 执行设置  -> 最大运行内存中设置”。（开的是低并发，且只有两条数据），还有什么办法能让数据推送过去吗？

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843270656802818&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

根据需求可拆分动作流：在循环下面加MQ发送组件，上传附件接口放在MQ接收的动作流去实现，MQ的参数设置配置附件接口需要的参数接即可；

具体操作说明参考配置文档：

[ _https://www.e-cology.com.cn/sp/doc/docDetail/2002040845295057123_](https://www.e-cology.com.cn/sp/doc/docDetail/2002040845295057123 "https://www.e-cology.com.cn/sp/doc/docDetail/2002040845295057123")

 

##### 怎么解决？

由以上示例场景总结可得动作流内存超限的解决方案如下：

###### 方法一：优化内存使用

1.

分批处理大数据，不要一次性加载。

2.

大文件可先压缩大小再处理。

###### 方法二：检查并调整“最大运行内存”设置

1.

进入动作流设置页面；入口见目录：动作流设置指引。

2.

找到【最大运行内存】选项；

3.

根据你的业务需求调整：

如果是高频执行的动作流：建议 ≤ 2048KB（约2MB）

如果是低频执行的动作流：建议 ≤ 4096KB（约4MB）

4.

保存设置

 

3.

#### 动作流循环次数超限怎么办

示例场景1：动作流报文日志中循环次数超过100次，但是实际只循环了100次。循环执行一部分就停了。

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843266440699906&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

##### 为什么会这样？

循环条件设置错误，导致死循环

循环次数设置太多，一直执行不完

 

根据示例场景1的需求，循环数据量超过100次，调整最大循环次数后可满足需求。

 

示例场景2：动作流报文日志中循环次数超过1000次

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843266468913153&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

由上可知循环次数已超过动作流最大循环次数限制。分析该场景后可采用分批循环：

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843257872564226&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

也可拆分多个动作流通过MQ的方式进行异步处理，具体操作说明参考配置文档：

[ _https://www.e-cology.com.cn/sp/doc/docDetail/2002040845295057123_](https://www.e-cology.com.cn/sp/doc/docDetail/2002040845295057123 "https://www.e-cology.com.cn/sp/doc/docDetail/2002040845295057123")

#####  怎么解决？

由以上示例场景总结可得动作流循环次数超限的解决方案如下：

###### 方法一：优化循环逻辑

**避免死循环**

确保循环条件有终止的时候

可以在循环中添加【跳出循环】组件，强制跳出避免继续无效循环

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843262028292101&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

**减少不必要的循环**

如果循环是为了查找数据，考虑使用查询条件直接过滤

如果循环是为了处理数据，确保数据量不会过大

**分批处理**

如果循环数据量大，考虑分批循环处理

###### 方法二：检查并调整“最大循环次数”设置

1.

进入动作流执行设置页面；入口见目录：动作流设置指引。

2.

找到【最大循环次数】选项；

3.

根据你的业务需求调整：

如果是高频执行的动作流：建议 ≤ 100次

如果是低频执行的动作流：建议 ≤ 1000次

4.

保存设置。

 

4.

#### 查询数据条数超限怎么办

数据源查询组件中最大查询条数超过100条如何处理

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843262142365698&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

##### 为什么会这样？

一次查询试图获取太多数据

查询条件过于宽泛，没有限制结果数量

##### 怎么解决？

###### 方法一：优化查询方式

**拆分查询**

如果必须处理大数据，拆分为分批查询，具体操作说明参考配置文档：

[ _https://www.e-cology.com.cn/sp/doc/docDetail/2002040845295057123_](https://www.e-cology.com.cn/sp/doc/docDetail/2002040845295057123)

 

**添加查询条件缩小结果集**

添加时间范围限制

添加状态过滤条件

只查询需要的数据，不要查询全部

###### 方法二：检查并调整“数据源单次查询最大条数”设置

1.

进入动作流执行设置页面；入口见目录：动作流设置指引。

2.

找到【数据源单次查询最大条数】选项。

3.

根据你的业务需求调整：

如果是高频执行的动作流：建议 ≤ 100条

如果是低频执行的动作流：建议 ≤ 1000条

4.

保存设置。

调整后显示效果：

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843253483347970&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

5.

#### 并发数据超限怎么办

问题现象：多个请求同时触发动作流时，部分请求被拒绝，提示【触发限流】。

 ![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843257951428610&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

##### 为什么会这样？

同时触发的动作流执行请求太多

动作流执行时间过长，占用了并发名额

##### 如何区分不同限流？

**动作流并发限流：** ESB_EXECUTE_LIMIT

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843257904144386&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

**租户并发限流：** ESB_TENANT_EXECUTE_LIMIT，日志中含有“TENANT”标识

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843266534752260&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)

##### 怎么解决？

###### 方法一：优化执行策略

**对于高频场景，建议使用【高并发】模式**

**错峰执行**

如果多个动作流可以不同时执行，错开执行时间

可以使用定时触发，设置不同的开始时间

**使用队列机制**

对于可以异步处理的任务，使用消息队列，避免同步等待导致并发占用

###### 方法二：检查并调整“并发数量”设置

1.

进入动作流执行设置页面；入口见目录：动作流设置指引。

2.

找到【并发数量】选项。

3.

根据你的业务需求调整：

如果是高频执行的动作流：建议 ≤ 10个

如果是低频执行的动作流：建议 ≤ 1个

4.

保存设置。

###### 方法三：租户并发限流可进入租户管理平台调整最大同时运行实例数量

 

![](https://weapp.eteams.cn/papi/file/preview?fileId=1227843262028292100&type=redirect&customParam=%7B%22isExtDist%22%3Atrue%2C%22distributeId%22%3A%22%22%2C%22externalId%22%3A%22%22%2C%22appId%22%3A%22%22%7D)
