效能課堂-TPS 瓶頸精準定位

問題反饋

這是一個效能培訓學員反饋的TPS問題
100併發使用者下的負載測試，TPS最大升到570左右，然後跌到400，並且長期保持。加執行緒也不能讓tps再有所增加。

從監聽到的伺服器指標來看，cpu利用率一直處於低迷的狀態，大約只有40%左右。

問題定位

執行 vmstat 1 10

可以觀察到，執行佇列不是很長，iowait不高，沒有swap切換，但是上下文切換和中斷似乎有點偏高

執行mpstat -P ALL 1

可以很明顯的觀察到軟中斷有點偏高，使用者空間的cpu利用率大約是系統空間的兩倍。

接下來 執行 watch -d cat /proc/interrupts
分析一下是什麼導致的軟中斷過高

可以發現中斷頻率最高的兩個網路卡和vmw服務。有可能是網路出現了故障，但是vmw是什麼暫時未知

執行*netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' *，檢視一下timewait有多少

4900多timewait，但是這似乎也不能說明什麼問題。

接下來重頭戲，需要攔截一下系統程式，看一下系統內部到底在做什麼導致的切換和中斷過高
執行** strace -o strace.log -tt -p 29779**
這條命令生成了一個程式日誌，從日誌裡面可以看出一些問題
1：系統內部寫日誌的時候沒有許可權，出現了反覆讀寫的死迴圈

2：tcp連線超時了

現在問題大致明白了。因為系統反覆寫日誌不成功，導致核心頻繁的上下文切換；因為tcp連線故障導致的系統頻繁中斷

解決問題

1：調整了tcp的keepalive時間，從1200加到了3000
2：增加了tcp緩衝和記憶體共享
3：日誌問題開發暫時不想解決

結果

tcp調整之後，最大tps增加到了650左右，但是還是會掉到420。因為那個上下文切換過快導致了cpu無法正常工作，所以tps無法從根本上提升