问题现象

白天客户访问负载均衡端口，发现访问不到应用，远程排查是没有启动his。帮其启动后即修复了此漏洞。晚上突然接到顾问电话说was用着用着就宕机，重启was又启动不起来。双机水平集群，启动dmgr、nodeagent、master都很顺利正常启动，启动ncMem01、ncMem02时发现启动异常，直接宕机。要求先进行修复，让客户先做完个单子后在排查原因。

问题分析

看其was堆内存配置的4G，启动后内存直接被撑爆，并没有回收的现象。整个服务器内存64G，直接给ncMem01、ncMem02内存分配到10G，启动后依旧宕机。最后分到到15G，ncMem01、ncMem02启动成功。

启动后内存状况

nmc看了下线程信息，发现在server上没有异常的线程。除了启动的基本线程外没有其他卡住的线程。排查了定时任务列表也没有正在跑的定时任务。

ncMem01

ncMem02

做完单据后，调小内存，手动生成了dump文件，发现占用内存比较大的都是tb 预算的东西。

当时询问了顾问是否打了补丁，顾问反馈系统是从1909升2105，所以近期打了一堆补丁，为了解决业务问题。UFO-公式编辑全局节点，所有者权益变动表，一点进去就报错 【未知的错误】

报表数据中心点击显示【未知的错误】

为了把业务报错影响到最低，所以需要帮顾问定位到具体哪个补丁造成的。在patch_ufo计算空指针PubRuleExecute（专项）0408\replacement\modules\epmp\classes\nc\ms\tb\formula\core 中找到dump文件中显示占用内存的相关代码。

撤掉此补丁后系统恢复正常。

解决方案

撤掉patch_ufo计算空指针PubRuleExecute（专项）0408补丁。

其他

过与开发沟通，发现这个是升迁留下的历史问题。最开始是UFO公式所有者权益表打不开打了一个补丁，可以打开了，但是公式修改后不生效。然后再打这个有问题的补丁。      但客户是从1909升级到2105的，补丁不兼容。最后业务报错通过实施手段，把报表公式删了，再重新设置报表公式后就可以计算了。