应用表单加载导致超时

典型现象/特征

1. 流程相关接口出现超时报错，例如发送、查看详情、提交、取回、回退、撤销等
2. 页面报"其他人正在提交该流程相关待办，请稍后重试！"

排查确认步骤

1. 1.从K8S面板中确认审批应用POD状态是否正常。
2. 2.访问thread-info监控页面，检查是否有线程耗时很久，并且堆栈信息中存在了类似：com.seeyon.boot.starter.dynamicloader.DynamicLoader.load()
3. 3.检查jvm-info中（ 系统运维接口），metaspace的使用大小，如果超过80%则是危险，90%以上大概率表单加载过多。
4. 4.检查已加载表单数量，通过url: {host}/service/{appName}/dynamic/loaded-app查询，检查加载表单数量，和nacos中配置的LRU是否保持一致。
5. 5.查看应用日志，查询日志中是否存在OOM( 元空间内存溢出)，亦或者是2中提到的堆栈报错
6. 6.看看K8S日志，是否有OOM Kill。 K8S的oomkiller

分析工具

1. 一键采集工具
2. 系统监控查看说明
3. 系统日志查看指引
4. 业务场景复现与比对

常见应急恢复策略

1. 从nacos中下线掉状态不对的POD，临时增加一个POD，并且当新的POD刚刚上线到NACOS的时候，先手动下线，待新的POD预加载表单完毕后，再手动上线临时新增的POD
2. 如果是表单加载有明显报错，则走正常的客户问题单
3. 如果是K8S的OOMKill，则检查POD的yaml配置和nacos配置，检查关键配置：

a、JVM启动配置-Xmx、-XX:MaxMetaspaceSize -> 比如值分别为a和b（单位G）
b、resources.limits.memory 比如值为c （单位G）
c、Nacos中的tomcat.max-threads和threadpool.max-size的值总和，比如值为d （单位个）
配置是否合理，计算公式: a + b + d * 1024M < c 才算合理，否则请调整参数，使其满足这个公式