一、业务背景#
二、服务架构#
服务使用线程池对请求进行业务处理,corePoolSize=32,maximumPoolSize=128。
三、问题描述#
服务部署到测试环境,将线上流量通过tcp-copy打到服务上后,测试反馈出现丢失消息的情况。查看服务日志,发现了
service overload discard msg
即业务线程处理缓慢造成消息堆积队列超限,后续消息被ExecutorService的Reject策略主动丢弃。
查询服务请求QPS为500/s,不算高。理论上业务处理流程没有很重很慢的操作,监控外部依赖接口的响应速度也在ms级别,所以很奇怪为什么服务的性能瓶颈这么低。
四、问题查解#
1、系统监控####
查询系统监控指标,包括CPU使用率(18%)、网卡流量、内存使用率和IO时间等,未发现异常。
查询jvm 内存使用及GC情况,未发现异常。
2、jvm 线程堆栈####
jstack pid >pid.txt打印服务进程线程栈信息:
线程堆栈信息
发现异常:
128个业务线程中有126个线程状态为java.lang.Thread.State: WAITING (on object monitor),只有2个线程状态为正常RUNNABLE。