本文章轉載于搜狗測試

近期在一個性能測試項目中遇到了一個調優的過程。分享一下給大家。

1、?第一次打壓時，發現A請求壓力80tps后，cpu占用就非常高了（24核的機器，每個cpu占用率全面飆到80%以上），且設置的檢查點沒有任何報錯。

2、?了解了一下后臺實現邏輯：大體是這樣的：服務器接到請求后，會再到另一臺kv服務器請求數據，拿回來數據后，根據用戶的機器碼做個性化運算，最后將結果返回給客戶端，期間會輸出一些調試log。

查了下，kv服務器正常，說明是本機服務服務器的問題。具體用vmstat命令看一下異常的地方。

3、?從圖中可以直觀的看出，bi、bo、in、cs這四項的值都很高，根據經驗，bi和bo代表磁盤io相關、in和cs代表系統進程相關。一個一個解決吧，先看io。

4、?用iostat –x命令看了下磁盤讀寫，果然，磁盤慢慢給堵死了。

5、?看了下過程，只有寫log操作才能導致頻繁讀寫磁盤。果斷關閉log。重新打壓試下。

6、?Bi和bo降到正常值了，說明磁盤的問題解決了。但是上下文切換數竟然達到了每秒40萬次！好可怕~

7、?只知道上下文切換數很大，怎么知道是在哪些進程間切換呢？

到網上搜了一個腳本，這個腳本用來統計特定時間內進程切換的top20并打印出來。

保存成cs.stp后，用stap cswmon.stp 5命令執行下。

8、發現是discover進程在反復和系統進程進行切換。因此消耗了大量資源。

9、從網上查了下減少切換進程的一些方法：

開發隨后改了下：將線程數開大了一倍，控制在一個進程中。

重新打壓了一下。發現上下文切換數降低到25萬次左右。

此時的性能數據可以達到每秒260次左右，遠遠高于之前的80次。已經達到可以上線的需求。

但是由于頁面中斷數和上下文切換數還是很高，后續還是需要優化~