伺服器壓力上不去原因分析

標籤：

百兆的頻寬在理論上1秒鐘可以傳輸12.5MB的資料，但是考慮到幹擾因素每秒傳輸只要超過10MB就比較正常啦。千兆頻寬每秒傳輸是100M。

http://www.cnblogs.com/candle806/archive/2011/04/02/2003828.html

通過分析，處於峰值只有網路頻寬，為90%以上，而對比此處的吞吐率值恰為95MB/s左右，1Gbps的網路頻寬傳輸速率為128MB/s，從而表明由於輸送量過大，佔用了大量的頻寬資源，導致後續的虛擬使用者無法得到伺服器的資源，而致使請求被拒絕。從最後的頁面回應時間來看，系統的壓力並沒有被承接到頁面上，而是由於過大的輸送量吞噬了網路頻寬，導致最終無法有效地完成測試工作。

http://www.xinfengit.com/200907/1848581.html

在效能測試過程中，經常會遇到資料庫CPU資源使用率上不去

1、網路頻寬問題

1.1被測試環境和lr用機都在百兆頻寬中

 

1.2被測試環境和lr用機不在同一頻寬中，被測試環境在千兆頻寬環境中，lr用機在百兆頻寬環境中

 

2.Controller機器在百兆頻寬中，被測試環境和lr壓力發生器在千兆或以上頻寬中

可以查看被測試環境中的交換器的傳輸速率是100Mbps還是1000Mbps。

TP-LINK TL-SF1016，傳輸速率：10/100Mbps

3、資料量問題

3.1網路沒有問題，輸送量甚至超過100M，但是後台伺服器資源還是比較低。

資料庫中基礎資料量比較少，幾乎是空的資料庫，這樣資料庫CPU利用率也上不去

3.2資料庫中的資料量雖然比較多（100萬筆以上），但是在效能測試時真正用到的使用者所關聯的流水比較少，或者根本沒有關聯上流水。比如：150多萬的交易流水，目前使用者表有500個使用者號，其中有200個使用者號關聯到了流水表中的資料，而測試時用到了50個使用者。資料庫CPU沒有上去，先要排除網路和資料量的限制，然後要查看這50個並發使用者是否都關聯到了流水表上？每個客戶號關聯了多少流水（大於2000，小於10萬，太大的會不現實）？

 

4、JDBC串連池限制

以上網路和資料量都沒有問題，則會考慮交易到資料庫的串連數是否有限制，和資料庫操作的那些交易的SQL請求根本沒有到達資料庫伺服器。我們可以通過中介軟體的控制台查看JDBC的最大容量（此串連緩衝池可容納的最大物理串連數）

4.1資料庫JDBC串連池限制，設定的本來就小，weblogic預設最大容量為50。

 

4.2如果一台應用伺服器上是多路進行部署的話，查看各路JDBC串連是否均衡

 

5、應用程式問題

處理能力真的達到了極限==

 

6、效能測試指令碼和資料問題

伺服器壓力上不去原因分析