新功能上线4天后，突然出现

此类问题包含：请求等待时间过长

初步解决方案

1、使用现有资源，将服务提供方分为两组，分别是：

  • 处理大量业务（种类尽量少一些，方便排查问题）[主要分组]

  • 处理少量业务[次要分组]

这样分组是因为：次要分组中需要使用最新项目中的方法，主要分组中不需要。这样可以保证不会对线上服务产生任何影响。

2、对主要分组进行回滚（怀疑有两个影响点）

  • 新增的服务方法

  • 调整了项目的JDK版本

观察现象

一、运行24小时

  • 次要分组，没有出现问题

  • 主要分组，重现问题

  • —发现多个大量消耗内存的线程

  • —每个线程中都是一个外部网络请求

  • —这些网络请求，统一是在会产生一个业务请求链的方法上（会根据配置增加串行请求的节点数量）

二、运行48小时

  • 主要分组，出现问题

  • —CPU、内存没有问题

  • —大量等待、抛弃的请求

得出结论

一、现象一结论

1、不是项目的问题

原项目已正常运行12天，并未出现问题。这次突然出现问题，不应该是原项目的问题。 新项目在只提供服务的12小时也没有出现问题

2、业务本身的逻辑对项目产生较大的压力

业务需要有一个外部网络的串行请求（每配置一个外部服务商，会在请求链上产生一个请求节点） 只有整个请求链完成，才会释放对应的异步线程

3、队列数设定较多

此次现象中，每一个队列会产生15M左右的空间占用 设定的内存无法满足满负荷的队列

二、现象二结论

无法及时处理任务，导致任务积压

每一个队列处理太慢，导致减少后的队列无法为所有的服务提供位置 分配的队列数被消耗完，其他任务等待时间过长，被抛弃

解决方案

一、现象一的解决方法

1、减少请求链中的配置项
2、减少队列的数量

二、现象二的解决办法

增加处理每个队列的线程池数量
根据每秒钟的请求，计算最差情况下会产生的任务等待
根据每一个任务的内存消耗，计算当下配置服务器什么情况下回宕机
根据每一个线程占用的内存，调整线程池的数量