性能分析之公有云网络带宽导致 TPS 低 RT 高

背景介绍

分析过程

背景介绍

分析过程

背景介绍

今天在压力过程中，一兄弟说压力上不去了，TPS 随着用户数的增加居然没有一点上升的趋势，响应时间倒是乐呵呵的上去了。结果如下（大概的数据，当时我只是随手记在了本子上，主要看趋势）：

两个同事为了这个瓶颈在哪里找了大半天时间，因为之前我说过，系统瓶颈的分析要找到具体的原因才能跟其他团队沟通，不然别人问起来为什么回答不上来，显得团队能力不够强似的。

后来他们实在没招了，过来问我。描述大概如下：

他们查了数据库的资源，觉得没什么问题，SQL 执行时间还是挺快的，每秒近 2 万的 sql。

查了被测主机的情况，只有 us CPU 用的高，50%左右；

查了应用的进程的状态，也打了 java thread dump 来看，看到有大量的 connection 等待。如下图所示：

上面是全是 object.wait 状态的，还有一些 running 的是这样的：

- locked <0x000000066885da80> (a java.io.BufferedInputStream)

分析过程

看到这些数据，我想既然数据库有这么多连接都在等待，那就查查数据库的连接和 session 的状态。

居然只有几个 threads running，多刷了几遍，最多的也是只有10个左右。然后又回到应用里去查看应用主机和数据库主机之间的 TCP 连接

netstat -naop|grep 4001|wc -l 314

多刷了几次，也是说有 300 多是建立连接的，当然有些已经是 keepalive 状态了。但是 ESTABLISHED 的状态也是很多的连接。

看来这个 JDBC 有点多呀。但是这边多，数据库里在忙的却没那么多。如果

到这里为止，和连接有关的东西，还有一个没有查，就是网络状态。于是 iftop 一下。

网络流量 200 M左右应该算是比较正常。

但是为什么几个线程梯度都是这么多网络流量？如果是JDBC太多导致系统切换过多而 TPS 上不去，那为什么中断不多呢？或者是带宽就这样多？

带宽就这么多吗？有这个意识之后，我就让人把压力停了，先测一下网络带宽。然后就 iperf 了一下，结果带宽只有 300 多M。嗯？怎么只有 300 多M？又被公有云给公有了吗？

于是就把数据中心的人叫过来问了一下，他们说这个共享的带宽，可能 300M 已经不算小了。

为了验证这一点，做了如下测试：

看来公有云的网络吞吐量确实只能这样了。

后续还是到准生产上玩吧。

数据库 网络

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。