我在使用 Jmeter 进行单接口压力测试时，提升并发路数后，服务器整机的 CPU 占用率一直维持在 40%，调用该接口的峰值 TPS 在 1900 左右。提升不上去了。
想问下，随着并发路数的提升，服务器 cpu 无法提高，业务的 TPS 也无法提高了。一般有什么指标，会导致服务达到瓶颈。可有什么监控工具能让我找到瓶颈项。
接口是比较简单的接口，员工上下线。输入参数为员工编号和上线还是下线操作。服务器中，数据是存储在 H2 数据库中的。
我在打压机器是 8 核 32G，打压的时候，该机器 cpu、网络负载均不高。服务器是 12 核，8G 的服务器。我监控了服务器的内存，磁盘 IO，Swap，网络带宽，也没发现有什么异常数据。
打压机器上，Jmeter 聚合报告：
打压机器上，使用 Jmeter 监控服务器的 CPU：
打压机器上，使用 Jmeter 监控服务器的内存：
打压机器上，使用 Jmeter 监控服务器的 Swap：
打压机器上，使用 Jmeter 监控服务器的网络：
服务器上，Jconsole 监控数据:
接着压呗，你这个数据表现没感觉到了什么瓶颈
你用的是单机施压还是使用了 master-slave 模式进行施压？
如果是用了 master-slave 模式施压的，那可能是你 master 的网络带宽被打满了，导致施压上不去。
然后你增加线程数的时候，CPU 没有上去，tps 有增长吗？根据你的描述看，并没有看到有 CPU 密集型的操作，CUP 不高也正常。
有个问题，你是增加线程数后，提升不了 cpu 利用率，还是性能（TPS）也提升不了？
非 cpu 密集型的逻辑，cpu 提升不上去不是挺正常的么？
PS：建议也看看被测系统的环境配置，比如最大线程数、最大网络连接数之类的，是不是这些限制住了系统的发挥。
Aiden
回复
不知道你后端是什么程序，如果是 Java 的话可以看 jvm 启动参数以及应用内的 properties 配置。
然后操作系统本身也有最大网络连接数这类配置的，可以百度看下，windows server 的我不大了解具体在哪里配置。
另外，从你这个图看，瓶颈应该不是资源消耗，有可能是应用内部机制引起的耗时，比如并发时等待锁释放之类的。推荐用 jconsole 抓取下整个 api 处理内部各函数的耗时情况以及看下会不会有锁之类的机制。
这个是我经常问的问题咧，问题点在于流量没有打进服务器，所以 CPU 上不去。至于原因的话，要一层层往上排查。几种常见的原因：1、加压机负载到瓶颈，说白了就是请求没发出去；2、网络传输有限流，具体得根据现况查一下；3、web service 线程数没有配置过低需要调整，如 tomcat 需要配置一下最大线程数。
另外不要单机压，多搞几台机器一起压。
一般这种情况是 io 瓶颈
比如说接口依赖 db,db 线程查询满载。
建议看下你施压机的网络是不是被打满了
看请求响应时间是不是在变大，如果是，很可能是应用服务 DB 连接池在排队或者 DB IO 瓶颈已初步显现，应用服务本身 CPU 上不去太正常了，对 DB 服务器的监控数据也许能帮到你继续分析。