NOS直傳加速服務

最近團隊在對儲存系統做一些效能測試，期間遇到了不少問題，測試過程中得出的結果也沒有很好的資料支撐，所以嘗試了非常多的方法來對效能問題進行定位。

小王童鞋是挺厲害的，使用了非常多的工具進行效能問題定位，包括iosnoop對io請求進行跟蹤、iostat進行磁碟狀態記錄、go-pprof從runtime層面收集效能profile資料、使用go-torch對profile生成直觀的火焰圖、使用trace2heatmap對延遲資料生產熱力圖等等。

縱然是花了很多時間和精力去測試分析，但是諸多變數的系統中從外部整體去測試其實很難發現真正原因，走了一些彎路。

所以最後小夥伴通過一定手段對系統中的一些不確定性的環節進行簡化確定，真相才慢慢浮出水面。

以下整理分享。

儲存系統中採用多副本技術保障資料可靠性，leader併發將資料傳送到follower(三副本)，所有candidate(leader & follower)完成磁碟寫入之後，由leader回覆client寫入成功。

如下為兩個測試資料說明圖，第一張圖為從客戶端收集到的端到端的寫入響應時間分布，第二張圖為從乙個副本上測試得到的fdatasync刷磁碟的響應時間分布。

從兩測試圖可以看出:

疑問：leader接收到client寫傳送過來的資料是併發傳送到follower，在低壓力情況下，理論上網路上的開銷相比磁碟的fdatasync開銷基本可以忽略不計，是什麼原因導致三副本寫入結果達到了fdatasync的兩倍左右？

後來我們對fdatasync做了mock，響應時間就設定為固定50ms，測試結果發現三副本寫入結果基本就是50ms左右。非常符合預期的結果，結果說明了相比於fdatasync程式本身造成的開銷基本可以忽略不計，那麼真實情況下問題出在**？

從單節點fdatasync的響應時間分布看,是乙個典型的zipf分布,大部分請求響應時間較小，而小部分請求響應時間特別大。

所以使用程式擬合了類似的分布，並且通過模擬的方式驗證得到如下結果

擬合程式

package main    import (        "fmt"
"math/rand"
"sort"
"time"
)func main() 
sort.ints(data)
fmt.printf("%+v", data)
}

程式擬合出的曲線如下：

乳腺癌三副本提交和兩副本quorum情況下的平均提交時間及分布曲線。(ps:實線為總體平均值與百分比分布無關，圖例為展示方面，放在一塊兒)

相關擬合程式詳見： zipf.go、zipf.py

網易雲免費體驗館

，0成本體驗20+款雲產品！

。