ip_soft_rings_cnt引數與Server的壓力測試

【好久沒寫文章了，都有點覺得自己太懶了。遂記錄一則最近做的事情，分享給更多朋友。以後要多寫多記錄，決定了】

問題：
最近在做關於SUN SPARC平臺和X86平臺的機器的壓力測試，實現方法是先抓取生產資料庫在peak time的Top SQL，然後用自己寫的java多執行緒指令碼進行給機器施壓。
發現，無論開多少個Client，都無法將SPARC T系的一款機器壓到100% CPU使用率，只能壓到30%。而X86平臺就沒這個問題。
這帶來了一個問題是：如果這臺機器只能被壓到30%，那麼我們就不應該設定它的threshold就為它100% CPU了。

分析：
那麼究竟是什麼造成了CPU無法完全被使用？原因肯定是有其他資源率先成為了瓶頸。
那麼IO和NETWORK就成了最先考慮的目標。
首先檢查IO，平均響應時間並沒有增長到無法接受的地步。
NETWOK呢?在上壓力時，大部分等待事件是“SQL*Net message from client”。

我們首先分別在兩塊網路卡的不同ip上，啟動兩個listener，將壓力均攤到兩個網路卡上，這時，我們就可以將壓力壓到50% CPU以上了。
這更加說明了瓶頸是出在了網路上。

由於在這個環境中的SQL都是非常輕量級的PK查詢，package非常小，會不會是因為package太小太多導致網路堵塞？

結論：
我們根據

的建議，對solaris的一些相關網路引數進行的調整，其中就包括：
“
CMT specific
T5440/T5240/T5140/T5220/T5120/T2000/T1000
For S10U7 or earlier /etc/system
set ip:ip_soft_rings_cnt=16
”

驚奇的發現，經過網路調整之後，可以很輕鬆地將機器壓力調整到100% CPU。
然後我們採用單一變數法，隔離開無關引數，最終定位到了ip_soft_rings_cnt。

知識：
那麼為什麼設定ip_soft_rings_cnt=16(以前是預設是2)之後，就解決問題了呢？
於是查詢相關文件，搜到一篇不錯的文章，建議大家精讀：
http://blogs.sun.com/krgopi/entry/crossbow_soft_rings


於是整個故事是這樣的：
簡而言之，ip_soft_rings_cnt控制了有多少個work threads來處理我們incoming package。
由於我們大量的SQL命令傳送到網路卡上，造成了incoming package的堵塞。
當我們設定ip_soft_rings_cnt=16之後，將有16個CPU threads來處理他們。

在資源守恆定理的想象下，這其實是拿CPU使用率換來了更高的網路進口的吞吐量。
由於機器是有128個CPU threads，原先有2/128的CPU在處理，現在有16/128的CPU在處理。

所以，雖然以前我們壓不上機器的CPU使用率，但是由CPU/TPS線性估算出來的peak TPS是更高的。
現在，估算出來的peak TPS稍低一點。
這很顯然，因為現在有差不多10%+的CPU在做處理incoming package的事情了。所以，Oracle能使用的peak CPU也下降了10%。

結尾：
當你看到你的機器CPU負載常年在20%浮動的時候，是否會感到十分輕鬆，覺得機器瓶頸還早著呢？
建議你用當前的Top SQL壓力測試一把，或許某個資源在CPU之前率先達到瓶頸，例如網路。