性能分析之公有云網絡帶寬導致 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小時內刪除侵權內容。