性能测试工具 单接口压力测试时,增加线程数,却无法再提高 CPU 利用率

Aiden · 2021年03月12日 · 最后由 槽神 回复于 2021年03月16日 · 3456 次阅读

我在使用 Jmeter 进行单接口压力测试时,提升并发路数后,服务器整机的 CPU 占用率一直维持在 40%,调用该接口的峰值 TPS 在 1900 左右。提升不上去了。
想问下,随着并发路数的提升,服务器 cpu 无法提高,业务的 TPS 也无法提高了。一般有什么指标,会导致服务达到瓶颈。可有什么监控工具能让我找到瓶颈项。

接口是比较简单的接口,员工上下线。输入参数为员工编号和上线还是下线操作。服务器中,数据是存储在 H2 数据库中的。

我在打压机器是 8 核 32G,打压的时候,该机器 cpu、网络负载均不高。服务器是 12 核,8G 的服务器。我监控了服务器的内存,磁盘 IO,Swap,网络带宽,也没发现有什么异常数据。

打压机器上,Jmeter 聚合报告:

打压机器上,使用 Jmeter 监控服务器的 CPU:

打压机器上,使用 Jmeter 监控服务器的内存:

打压机器上,使用 Jmeter 监控服务器的 Swap:

打压机器上,使用 Jmeter 监控服务器的网络:

服务器上,Jconsole 监控数据:




共收到 13 条回复 时间 点赞

接着压呗,你这个数据表现没感觉到了什么瓶颈

你用的是单机施压还是使用了 master-slave 模式进行施压?

如果是用了 master-slave 模式施压的,那可能是你 master 的网络带宽被打满了,导致施压上不去。
然后你增加线程数的时候,CPU 没有上去,tps 有增长吗?根据你的描述看,并没有看到有 CPU 密集型的操作,CUP 不高也正常。

有个问题,你是增加线程数后,提升不了 cpu 利用率,还是性能(TPS)也提升不了?

非 cpu 密集型的逻辑,cpu 提升不上去不是挺正常的么?

PS:建议也看看被测系统的环境配置,比如最大线程数、最大网络连接数之类的,是不是这些限制住了系统的发挥。

黑色月牙 回复

单机压测的,打压力机器的负载并不重。想查到有哪些因素导致 TPS 提高不上去了。不知道如何下手。

陈恒捷 回复

请问下,在哪里看最大线程数、最大网络连接数这些指标。

Aiden 回复

不知道你后端是什么程序,如果是 Java 的话可以看 jvm 启动参数以及应用内的 properties 配置。

然后操作系统本身也有最大网络连接数这类配置的,可以百度看下,windows server 的我不大了解具体在哪里配置。

另外,从你这个图看,瓶颈应该不是资源消耗,有可能是应用内部机制引起的耗时,比如并发时等待锁释放之类的。推荐用 jconsole 抓取下整个 api 处理内部各函数的耗时情况以及看下会不会有锁之类的机制。

这个是我经常问的问题咧,问题点在于流量没有打进服务器,所以 CPU 上不去。至于原因的话,要一层层往上排查。几种常见的原因:1、加压机负载到瓶颈,说白了就是请求没发出去;2、网络传输有限流,具体得根据现况查一下;3、web service 线程数没有配置过低需要调整,如 tomcat 需要配置一下最大线程数。
另外不要单机压,多搞几台机器一起压。

一般这种情况是 io 瓶颈
比如说接口依赖 db,db 线程查询满载。

建议看下你施压机的网络是不是被打满了

Aiden #11 · 2021年03月16日 Author
黑色月牙 回复

不是的,我看了下施压机器的 cpu、内存、网络都挺充裕的

Aiden #12 · 2021年03月16日 Author
william 回复

一般用什么工具,监控 db 资源占用情况。还想问下一般监控 db 的哪些指标。

看请求响应时间是不是在变大,如果是,很可能是应用服务 DB 连接池在排队或者 DB IO 瓶颈已初步显现,应用服务本身 CPU 上不去太正常了,对 DB 服务器的监控数据也许能帮到你继续分析。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册