今天在压力过程中，一兄弟说压力上不去了，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一下。
网络流量200M左右应该算是比较正常。
但是为什么几个线程梯度都是这么多网络流量？如果是JDBC太多导致系统切换过多而TPS上不去，那为什么中断不多呢？或者是带宽就这样多？
带宽就这么多吗？有这个意识之后，我就让人把压力停了，先测一下网络带宽。然后就iperf了一下，结果带宽只有300多M。嗯？怎么只有300多M？又被公有云给公有了吗？
于是就把数据中心的人叫过来问了一下，他们说这个共享的带宽，可能300M已经不算小了。
为了验证这一点，做了如下测试：
看来公有云的网络吞吐量确实只能这样了。
后续还是到准生产上玩吧。
