近期在做一個項目的性能測試時，在打壓時發現壓力達到100hps後就一直打不上去，同時還會報讀redis服務器超時的錯誤。

查看了下打壓服務器的cpu和內存占用，沒有發現什麽異常。

通過nmon監控服務器資源信息

CPU占用：

內存占用：

1、由於會報redis鏈接超時錯誤，首先定位到的是redis服務器掛了，找到開發將log中添加具體連接超時的redis服務器ip信息後，重新跑了一遍。

依然會報連接redis服務器超時錯誤，開發立即查看了下對應ip的redis服務器。發現運行情況沒有出現任何問題，各項指標均正常。

2、查看壓力服務器的各項指標來定位問題。

用sar命令看了下磁盤性能，發現每秒寫扇區的次數達到300以上，懷疑是寫入次數過多導致的，於是查了下開發的腳本，發現開發每一步判斷邏輯中都加了寫errorlog操作。於是懷疑是寫log導致的。

將開發的寫log操作大部分都關閉（除了讀redis服務器錯誤）後，重新跑了一下，發現寫扇區的次數降到100左右，但是tps依然打不上去。排除了磁盤寫入的問題。

3、接下來安裝了nmon工具後，重新跑了一遍，看了下網絡傳輸，發現tps達到100左右時，網絡出口占用為120M/s！這是千兆網卡的滿載速率了。於是定位到網絡成為主要的瓶頸。

網絡I/O傳輸表：可以發現eth0-write的速率達到120千KB，也就是120M（註意這裏的單位是“千”）

4、查了下自己的打壓腳本，發現部分請求的返回數據大小為4M。果斷將請求的返回改為200K後重新打壓後，壓力可以成功達到2000hps以上。同時也沒有再出現讀redis超時的錯誤。

至此，此次問題排查圓滿結束。同時向大家著力推薦一下nmon工具。裏面記錄的參數很全，基本上定位性能的指標（比如cpu、內存、每個cpu、每個磁盤分區的讀寫、磁盤busy情況、網絡吞吐、網絡包數據等）都能夠統計到。

壓測過程中網絡帶寬瓶頸案例分析