case-记一次业务高峰期接口超时问题

最新推荐文章于 2024-01-02 16:12:49 发布
最新推荐文章于 2024-01-02 16:12:49 发布
阅读量435 收藏
点赞数
分类专栏： 新的开始 JVM
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/han_dada/article/details/103082674
版权
本文记录了一次业务高峰期接口出现超时问题的处理过程。服务器CPU打满，TP99飙升，经过查看服务器指标、紧急扩容及问题分析，发现CPU打满的罪魁祸首在于String的replaceAll方法使用不当。优化后，性能显著提升，QPS达到预期，GC情况改善，提示开发者在编写代码时需考虑高并发场景下的性能问题。
摘要由CSDN通过智能技术生成

一、背景

服务器出现CPU打满报警，并且服务TP99飙升至1.3s+，依赖方反馈大量超时。

二、处理过程

1.查看服务器指标

首先查服务器的各种指标，根据指标值和趋势大概确认问题。可以看到CPU已经很耗尽了，load彪高比较严重
在这里插入图片描述
在这里插入图片描述
而且此时ygc的次数和耗时都有明显增加，这些指标都会严重影响TP99.
在这里插入图片描述
在这里插入图片描述
上边这些趋势图和业务QPS趋势吻合，初步推断是由于超过单机处理QPS阈值。

2.紧急处理

  1. 根据初步推断采集CPU数据保留现场
  2. 根据初步推断结果采用扩容方案进行止损。果然扩容后服务趋于稳定。

三、问题分析

1.TP99为什么升高？

因为CPU打满，

最低0.47元/天 解锁文章
扫雪去
关注
专栏目录
如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，如何解决？
悟已往之不谏，知来者之可追
04-19 800
问题 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？ 分析 你看这问法，其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了；或者消费的速度极其慢。接着就坑爹了，可能你的消息队列集群的磁盘都快写满了，都没人消费，这个时候怎么办？或者是这整个就积压了几个小时，你这个时候怎么办？或者是你积压的时间太长了，导致比如 RabbitMQ 设置了消息过期时间后就没了怎么办？ 所以就这事儿，其实线上挺常见的，一般不出，一出就是大 case。一般常见于
Flink大数据量调优思路总结（一）
击水三千里的专栏
09-15 480
flink 性能优化，大家可以先实践后,发现瓶颈后再来阅读此文。根据实际情况调优，没有万能的法则
某个接口超时如何解决
最新发布
SisinRyu的博客
01-02 2099
如果接口涉及大量的数据库查询操作，且查询条件未建立合适的索引，可能导致查询效率极低，应针对性地优化数据库表结构和索引。：如果是非实时性要求很高的任务，可以考虑将部分耗时操作改为异步处理，返回一个处理任务ID，然后通过另一个接口查询结果。：对于确实需要较长时间处理的复杂请求，可以适当延长接口的超时时间限制，但更推荐优化处理速度而不是一味延长超时。：在接口中添加详细的日志记录，通过监控工具分析接口调用过程中的问题点，找出导致超时的具体原因。
关于 Redis 性能细节
xingduan5153的博客
09-27 104
聊聊内存存储，redis作为分布式内存缓存，性能极高，但是在高并发读、高并发、大存储量写的场景下很多东西要注意，不然可能达不到预想性能效果。不能用透明方式去使用，而应该多去了解架构以及具体实现。不去了解细节，在高压力应用下，可能会对线上服务造成很大影响，达不到高可用。 关于数据结构，数据结构redis支持很多种，现在要探讨一件事不是这么多种数据结...
TP99 TP999
Mar.三月
03-11 6803
带你理解下啥是tp99 我们现在已有认知：一次请求从前端到后端的请求时间，这个接口的总时间=在网络耗时+服务端处理的耗时。这个通常是一个普通人可以关注到的点，也是最外漏的点。 但是刨去网络耗时外部原因，有没有对服务端处理真正的耗时进行过研究。 服务端耗时=请求到达服务端，服务端开始处理，到最后响应的时间。 接口tp99耗时：就是衡量接口性能的指标，tp99越低，接口性能越好。根据对一个 接口反复测试耗时时间，接口的平均耗时其实就约等于tp99耗时，拿着个值就可以去监控上配置，当接口的tp99耗时超过
压测过程中，大面积出现接口超时，应该从哪几个方面分析
qq727923587的博客
08-29 899
接口超时的可能性范围
技术分享 | 接口测试中，请求超时该怎么办？
软件测试小迷糊
08-22 688
A 发送请求，然后等待 B 的响应，同时开始超时计时，如果在超时时间内成功接收到响应，则结束等待和计时。如果到了超时时间还没有接收到响应，则结束等待同时此次通讯失败，这个过程叫做请求超时。在接口自动化测试过程中，也常常会碰到请求超时的场景。通过 setParam() 设置超时时间，第一个参数为连接的类型，第二个参数为超时的最大时长，单位是 3000 毫秒。编写三条测试用例，在 test_two 测试用例中设置超时时间为 3 秒，超过 3s 还没有得到响应的话则抛出异常，然后正常执行后面的测试用例。
Mongodb特定场景性能数十倍提升优化实践(记一次mongodb核心集群雪崩故障)
github_39037504的博客
10-04 493
问题背景 某核心JAVA长连接服务使用mongodb作为主要存储，客户端数百台机器连接同一mongodb集群，短期内出现多次性能抖动问题，此外，还出现一次“雪崩”故障，同时流量瞬间跌零，无法自动恢复。本文分析这两次故障的根本原因，包括客户端配置使用不合理、mongodb内核链接认证不合理、代理配置不全等一系列问题，最终经过多方努力确定问题根源。 该集群有十来个业务接口访问，每个接口部署在数十台业务服务器上面，访问该mongodb机器的客户端总数超过数百台，部分请求一次拉取数十行甚至百余行数据。 该集群为2.
数据库---MySQL读写分离的方案以及坑
小诚信驿站
04-12 348
强制走主库方案； sleep 方案； 判断主备无延迟方案； 配合 semi-sync 方案； 等主库位点方案； 等 GTID 方案。 一、强制走主库方案 强制走主库方案其实就是，将查询请求做分类。通常情况下，我们可以将查询请求分为这么 两类： 对于必须要拿到最新结果的请求，强制将其发到主库上。比如，在一个交易平台上，卖 家发布商品以后，马上要返回主页面，看商品是否发布成功。那么，这个请求需要拿到 最新的结果，就必须走主库。 对于可以读到旧数据的请求，才将其发到从库上。在这个交易平台上，买家来逛商铺页.
调用接口超时处理方案
热门推荐
windy博客
01-16 4万+
调用接口超时 处理方案大型项目存在多个子系统。如库存，订单系统。1.增加超时时间假设A系统有个方法methodA，会调用B系统的methodB这个http接口，如果mehodA不追求超快的响应速度，那么你在调用methodB这个http接口时，可以增长超时时间，例如10秒超时。因为经常在某些时刻，由于网络原因或者系统原因，调用method会超时的。2.尝试多调用一次如果第一次调用methodB超时了
记一次接口请求超时的问题解决过程
nelson的博客
10-09 9537
我有一个项目，部署在两个不同的服务器A和B，然后调用同一个接口，其中服务器A在毫秒级内返回，服务器B大概10秒左右才返回。 由此我认为响应时间久与代码逻辑没有关系，可能是跟网络传输有关系，所以我在宿主机服务器使用curl去访问看看响应需要多少时间 结果耗时还是需要十秒左右 于是我一开始认为与代码无关的想法又有点动摇了，我决定开启mysql的慢查询看看是不是某个查询耗时比较久导致的 SHOW VA...
[性能调整] 关于Oracle连接超时的问题（WARNING: inbound connection timed out (ORA-3136)连接超时问题）
一片叶子飞舞
02-19 1万+
/* *时间：2009-03-010 *环境：AIX5.3   Oracle10g *WARNING: inbound connection timed out (ORA-3136)连接超时问题 */ 1、alter_SID.log日志：aaa Mon Mar  9 02:18:40 2009 ksvcreate: Process(q002) creation failed Mon
记一次接口超时问题排查
zpsimon的博客
12-24 1491
今天生产环境突然出现一个老接口的p95响应耗时超1秒的告警。由于没有任何变更，有点奇怪，于是开始了探索之旅…… 首先常规排错思路，看直接告警信息。告警是ng上的接口响应耗时，由于ng一般只做转发或者负载均衡，没有什么逻辑，除非资源瓶颈和很高并发一般不会有什么压力。而ng的资源消耗都很低，基本排除ng的性能瓶颈导致。接着看nginx.conf 的配置，upstream是一组jetty服务。结合ng上的日志登录jetty服务器查看日志。由于没有记录有效的request 请求日志。至此通过日志链路报错线索中断了…
Java面试突击系列（一）：消息队列的面试连环炮
Viper的程序员修炼手册
11-18 1万+
消息队列的面试连环炮 前言 你用过消息队列么？ 说说你们项目里是怎么用消息队列的？ 我们有一个订单系统，订单系统会每次下一个新订单的时候，就会发送一条消息到ActiveMQ里面去，后台有一个库存系统，负责获取消息，然后更新库存。 为什么使用消息队列？ 你的订单系统不发送消息到MQ，而是直接调用库存系统的一个接口，然后直接调用成功了，库存也更新了，那就不需要使用消息队列了呀 使用消息队列的主要作用是：异步、解耦、削峰 消息队列都有什么优缺点？ Kafka、activeMQ、RibbitMQ、Ro
问题总结 接口响应超时
走在命运的左岸
07-07 1万+
生产问题 接口响应超时 可能原因 网络运营服务商导致网络延迟或数据丢包 接口服务的系统延时 多线程代码执行延迟1 代码本身问题2 RestTemplate 使用时未设置超时时间，默认不超时 影响超时时间的因素 tcp 连接本身的超时时间 nginx 默认读取后端服务的超时时间是 60s 上线代码未经审查3 现象描述 A 应用日志中打印 B 应用 HTTP 接口响应超时 排...
T-SQL编程：理解CASE-END示例与变量操作
CASE-END语句在SQL中是一种条件表达式，用于根据给定的条件执行不同的操作。在这个场景中，它能够有效地根据学员的笔试分数，判断并返回相应的等级。 首先，讲解了变量在T-SQL中的使用，区分了局部变量（如@name和@...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值