【BUG解决】服务器没报警但是应用接口崩了....

最近遇到一个突发问题:服务器没报警但是应用接口崩了...

为其他业务系统提供一个接口,平时好好的,突然就嚷嚷反馈说访问不了了,吓得我赶紧跳起来!

正常情况下在系统崩溃前,我会收到很多系统报警,但是这次它悄无声息的出问题,还是挺恐怖的

然后我立马看了下服务器的情况,服务器没有报警,也可以ping通 ,就是服务接口确实访问不了了

然后,还给我竖了个中指。。。。

好好好,现在都是这么折磨打工人的是吧。

随后我又看了下数据库的使用率,也没打满

然后随即查看对外提供接口的性能监控情况:除了9点15那会有点慢,其他一切正常,而且这个接口本身调用量不高的,系统完全可以hold住,为什么还是有问题?

于是怀疑是不是9点15那会接口慢了导致的。询问调用方之后,说超时连接时间设置的是5s。那这个接口完全可以在5s内返回。

随后我又找调用方拿到了这个日志信息:

RPC框架抛出异常cause: java.util.concurrent.RejectedExecutionException: Biz thread pool of provider has bean exhausted

它的意思是说线程池已经耗尽了,所以导致系统异常了。

目前系统最大设置的线程数量是300,我将配置提升到400,

随后对日志中这个关键词:Biz thread pool of provider has bean exhausted 做监控,之前都是系统CPU、TCP连接、内存、磁盘、以及方法调用时长以及可用率的报警,但是这些报警配置,没办法监控到此情况的发生。于是当系统报线程池满了之后,就需要赶紧调整下配置。

当然线程池的最大线程数也不是能无限增加的,这取决于系统负载能力。最大线程数越大,系统负载也会增大,数据库压力也会越大,如果慢sql较多,很可能数据库马上cpu就打满了,所以关键还是要从代码层面,解决一些长链接的慢sql,长事物。

具体可以参考下这篇:线程池队列已满时会发生什么?如何解决这个问题?

希望我的悲惨经历能给其他人排查问题带来一点思路吧...

相关推荐
心灵彼岸-诗和远方42 分钟前
DevOps业务价值流:架构设计最佳实践
运维·产品经理·devops
一只哒布刘1 小时前
NFS服务器
运维·服务器
苹果醋31 小时前
Java8->Java19的初步探索
java·运维·spring boot·mysql·nginx
二十雨辰2 小时前
[linux]docker基础
linux·运维·docker
Jason-河山2 小时前
【自动化更新,让商品信息跳舞】——利用API返回值的幽默编程之旅
运维·自动化
lihuhelihu2 小时前
第3章 CentOS系统管理
linux·运维·服务器·计算机网络·ubuntu·centos·云计算
哲讯智能科技3 小时前
SAP Business One市场价格解析
运维·sap·erp
山东布谷科技官方3 小时前
布谷直播源码部署服务器关于数据库配置的详细说明
运维·服务器·数据库·直播系统源码·直播源码·直播系统搭建·直播软件开发
One_Blanks3 小时前
渗透测试-Linux基础(1)
linux·运维·安全
爱吃喵的鲤鱼3 小时前
linux进程的状态之环境变量
linux·运维·服务器·开发语言·c++