记一次压测问题排查过程

最新推荐文章于 2023-12-07 14:10:18 发布
最新推荐文章于 2023-12-07 14:10:18 发布
阅读量355 收藏
点赞数
分类专栏： 工作杂记 文章标签： java mysql linux
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Pa_Java/article/details/108806594
版权

今天进行服务压测的时候，A服务的接口会根据传参调用下游的B服务或C服务，压测发现调用B服务的时候吞吐量在4K TPS，但是调用C服务的时候TPS却只有几十。
1、排查业务代码调用C服务的逻辑发现并不复杂
2、排查C服务的服务器的负载，数据库的负载发现都处于极低的水平，没有慢SQL
3、排查打印C服务的堆栈，发现大量的线程处于TIMED_WAITING的状态，怀疑线程池的配置问题
堆栈线程
4、排查数据库线程池的配置，发现没有问题。打开Druid的监控，发现池中连接数、池中连接数峰值 、活跃连接数峰值正常，与预期一致。但是等待次数 、事务启动数远超预期，并且压测的是GET请求，不应该有事务，断定是事务引起的线程等待
Druid监控
5、排查项目配置的事务，确实查询请求加上事务，去掉对应的事务，重复压测，发现一切正常
事务代码

aubergines
关注
专栏目录
性能压测总结（下）-测试结果分析和问题排查
hi_bigbai的博客
06-02 2789
明确问题 首先我们要确认是哪些性能指标不达到要求，或者需要改进​ 常见的性能指标： 用户体验层面 用户响应时间 就是用户感受软件系统为其服务所消耗的时间。对于web系统，请求的相应时间指的是从客户端发起的一个请求时间，到客户端接收到从服务器返回的相应结束。在互联网上对于用户响应时间，有一个普遍的标准：2/5/10秒原则。也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没.
破案现场：记一次压测异常排查--Redisson锁失效的场景
q1472750149的博客
02-07 4388
异常现场回顾 7月7日对小驴班级推送视频任务功能进行压测。 压测过程中发现有一部分接口请求失败。 小驴端上报推送失败异常如下： 这个异常日志是小驴端收到的。 异常内容是网校网关返回的异常页面， 如何看出来是网校网关的呢？ 看回到首页前面有一个url，这个跳转到的url正是网校的主页 班级任务推送主要是to B的，老师们使用， 并发量并不大，10并发，25次， 一共250个任务。 并发量并不大，到底为什么异常，怎么出的异常呢？ 首先，我们来看ELK日志监控。 先来查询网关日志，搜索对内网关，查询
记一次备战压测问题排查
J 博客
04-27 280
1、制定压测计划 2、压测过程中出现问题大致排查方向 3、本次压测备战出现的问题 预定单接口压测TPS为20W，在压力机施压到10W左右时，增加压力机并发数，应用系统的TPS一直维持在10W左右，且TP99 也无明显上升 猜测：a、公司网络专线是否出现网络瓶颈，导致压力机并发数据无法提升，压力机新增并发数是否有请求到服务器上 ？ b、系统压测接口内部是否出现排队逻辑？ 验证： 找网络处同事排查，压力机为千兆机，不存在网络带宽问题 压力机并发数请求数无明显增加,...
排查压测问题引发的系统性能调优过程
木子雷的博客
12-14 821
前言： 今天测试部门的小梦找到我，委屈巴巴的说我写的接口有问题，因为她对这个接口进行压力测试时，发现系统的吞吐量一直上不去，并且 应用服务器 （部署接口项目的服务器） 的CPU、内存等资源的使用率也一直很低，导致一直无法测试出这个接口的压力峰值。 听小梦说完后，自己心想接口都测试了好几遍了，接口代码 绝对不可能有问题的，再说了，有问题也不能承认呀，看来得往别的地方上扯扯呀；然后我说道，接口应该是没问题的，可能是项目环境部署时有些参数没进行调优吧，例如：连接数大小设置、JVM参数设置、数据库参数优化.
压测场景异常流量问题排查总结
chiyin1087的博客
10-04 640
九月份的工作内容主要是一个接口服务的开发，业务功能实现且功能测试没有问题之后，联系了压测的同事对该服务的性能进行了一系列的测试。在测试的过程中，遇到了一些奇怪的问题，经过笔者自己搜索资料并向老司机们请教，一一解决掉，在此做个总结，并与大家分享。 技术架构介绍：分布式服务...
一次实战压测流程及问题梳理！
m0_75277660的博客
11-13 199
这次压测的背景，主要是为了应对旺季到来，避免旺季的大量流量和高并发造成服务不可用，提升稳定性。而在稳定性建设中，也会从事前、事中及事后来看，包含的维度包含风险识别、监控告警、应急流程及故障复盘等不同的维度。
一次压测遇到的问题和排查过程记录
技术交流
03-31 666
其次，推测是获取令牌失败导致的超时，但在此场景下，项目中会返回“当前并发数量过高，请稍后重试”的提示语。目前网关超时统一设置6s，当获取令牌超时后，项目构造的响应体提示语“当前并发数量过高，请稍后重试”只在日志中正常打印，但网关已经返回了Gateway Time-out。首先排除存储过程导致的超时，因为该压测接口的测试数据是统一mock的，网络稳定的情况下，不会出现超时的情况。首先，从压测参数来看，并发数并不高，持续时间也不高，排除并发过高导致服务承载不住的可能。断言的设置会影响最终异常率。
记一次压测环境OOM问题排查与解决
bazhuayu_1203的博客
01-02 547
测试同学在管理后台上传一张3M的图片时，发现界面停留在卡死的状态，就喊我排查下。听到这个后首先要做的就是看这个管理后台服务的日志。 从日志里清楚的看到，居然是可恶的堆内存溢出。 排查堆内存溢出过程 还好我们jvm的启动参数里有配置在发生OOM时dump内存快照 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/app/sc-manage/logs 我登录到OOM的这台机器把内存快照文件下载到本地，准备用MAT来分析下。 MAT是什么 MAT是一款强大的
记一次 JVM CPU 使用率飙高问题的排查过程
m0_71777195的博客
10-05 653
如上图所示，显示了PID为20567的 Java 进程每秒的 GC 情况，其中1000表示 GC 状态的更新频率，单位为毫秒。如上图所示，在 下午3:45 分之前，CPU 的使用率明显飙高，最高飙到近 100%，为什么会出现这样的现象呢？在这里，我们之所以需要将PID转为十六进制是因为在堆栈信息中，PID是以十六进制形式存在的。如上图所示，显示了服务器当前的资源占用情况，其中PID为5456的进程占用的资源最多。至于为何在 下午3:45 分之后，CPU 的使用率降下来了，则是因为停止了压测。
6到飞起Arthas——记一次线上问题排查及调优
qiubboy的博客
05-21 708
Arthas是Alibaba开源的Java诊断工具，通过Java agent机制 attach到ava进程上，使用ASM技术对需要诊断的类进行字节码修改。（详细原理及用法参照官方文档https://arthas.aliyun.com/doc/en/） 线上诊断神器Arthas，强烈安利一波。好嘞，切回本次重点，记一次线上调优： 背景： 公司自研的服务治理框架，sdk客户端在向控制中心寻址时，经常会出现寻址超时的情况（sdk客户端设置超时时间为3s）。虽然客户端会每5S会发送一次寻址请求，且请求到..
记一次演练压测 TPS 上不去排查及优化
测试萌萌
06-05 787
其实对于一个性能瓶颈问题的分析排查定位，犹如医生看病，需要望闻问切，通过表面现象逐层的去排除一种种的可能性，最终找到其根本原因，对症下药解决问题。本文介绍的也只是性能瓶颈问题中的一个小小的部分，其实在压测过程中还会遇到各种各样的问题，但是我们掌握了方法论，其实都可以按照相同的思路去排查，最终找到根源。
记一次性能压测的问题排查过程
weixin_33840661的博客
07-23 598
2019独角兽企业重金招聘Python工程师标准>>> ...
13年测试老鸟总结，性能测试常遇问题+解决方案+分析...
最新发布
大佬云集技术答疑交流群：743262921(进群暗号:222)
12-07 195
1、内存溢出1）堆内存溢出现象：压测执行一段时间后，系统处理能力下降。这时用JConsole、JVisualVM等工具连上服务器查看GC情况，每次GC回收都不彻底并且可用堆内存越来越少。排查手段：使用jmap -histo pid > test.txt命令将堆内存使用情况保存到test.txt文件中，打开文件查看排在前50的类中有没有熟悉的或者是公司标注的类名，如果有则高度怀疑内存泄漏是这个类导致的。
压测导致mysql数据库CPU很高_排查压测问题引发的系统性能调优过程
weixin_35213963的博客
02-05 1289
前言：今天测试部门的小梦找到我，委屈巴巴的说我写的接口有问题，因为她对这个接口进行压力测试时，发现系统的吞吐量一直上不去，并且 应用服务器 (部署接口项目的服务器) 的CPU、内存等资源的使用率也一直很低，导致一直无法测试出这个接口的压力峰值。听小梦说完后，自己心想接口都测试了好几遍了，接口代码 绝对不可能有问题的，再说了，有问题也不能承认呀，看来得往别的地方上扯扯呀；然后我说道，接口应该是没问题...
jmeter压力测试指标解释
DrMaker的博客
07-20 1302
什么是RT?RT就是指系统在接收到请求和做出相应这段时间跨度但是值得一提的是RT的值越高,并不真的就能说明我们的系统的吞吐量就很高,比如说,如果存在数据在网络中传输时出现了丢包的现象,传输的数据少了,速度就会增加,但是这是事故,不是说我们的系统吞吐量高。...
记一次性能压测瓶颈排查
乐天派
01-07 6273
昨天测试同学过来反应有一台机器做性能压测的时候，无论开多少个线程，QPS一直压不上去，而服务器和数据库的性能指标（主要是CPU和内存）一直维持在很低的水平。 希望帮忙排查一下原因。 过去看了下进行压测的接口代码，逻辑很简单，就是一个数据库查询，所以不存在耗时操作的问题。 首先观察服务器（4c32g）和数据库的详细性能指标：服务器CPU和内存都很低，数据库的监控显示只有一条活跃连接。这就很奇怪
jmeter压测 优化排查流程
北巷东东的专栏
03-18 1018
jmeter压测 项目优化 优化排查
记一次生产环境tomcat线程数打满情况分析
07-07 4110
欢迎使用Markdown编辑器 现象重现 使用grafana监控发现服务某个节点的cur线程数会暴涨直至打满且一直无法回收 原因分析 解决方案与建议
Java OOM问题排查：从异常到解决方案
本篇实战记录讲述了如何排查一次由Java堆内存溢出（Java Heap Space）引发的OOM问题。问题起始于运维人员反馈的线上程序异常，日志显示多个HTTP-NIO工作线程在处理请求时遇到Java堆空间不足的情况。 首先，利用JVM...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值