【問題】
我們有臺HP的服務器，SSD在寫IOPS約5000時，%util達到80%以上，那么這塊SSD的性能究竟有沒有問題，為解決這個問題做了下面測試。
【工具】
blktrace是linux下用來排查IO性能的工具。它可以記錄IO經歷的各個步驟，并計算出IO請求在各個階段的消耗，下面是關鍵的一些步驟：
Q2G – 生成IO請求所消耗的時間，包括remap和split的時間；
G2I – IO請求進入IO Scheduler所消耗的時間，包括merge的時間；
I2D – IO請求在IO Scheduler中等待的時間；
D2C – IO請求在driver和硬件上所消耗的時間；
Q2C – 整個IO請求所消耗的時間(G2I + I2D + D2C = Q2C)，相當于iostat的await。
其中D2C可以作為硬件性能的指標，I2D可以作為IO Scheduler性能的指標。
【測試一、比較HP SSD Smart Path開啟前后SSD的寫入性能】
1、HP SSD Smart Path開啟，SSD控制器Caching關閉，Cache Ratio: 100% Read / 0% Write
測試結果如下，主要關注D2C（IO請求在SSD上消耗的時間）的AVG值，約為0.217ms
2、HP SSD Smart Path關閉，SSD控制器Caching開啟，Cache Ratio: 10% Read / 90% Write
測試結果如下，主要關注D2C（IO請求在SSD上消耗的時間）的AVG值，約為0.0906ms
【結論】
前者在硬件上的消耗時間是后者的約2.4倍，對于寫入為主的系統(tǒng)，建議HP SSD Smart Path關閉，SSD控制器Caching開啟
【測試二、比較noop和deadline兩種I/O調度算法的性能】
目前磁盤的調度算法有如下四種，我們系統(tǒng)中的配置值為deadline，很多資料上建議SSD配置為noop
1、Anticipatory，適用于個人PC，單磁盤系統(tǒng)；
2、CFQ(Complete Fair Queuing)，默認的IO調度算法，完全公平的排隊調度算法
3、Deadline，按照截止期限來循環(huán)在各個IO隊列中進行調度
4、noop，簡單的FIFO隊列進行調度
下面都在HP SSD Smart Path關閉的情況下測試，
1、deadline, 主要關注G2I和I2D
2、修改為noop
【結論】
noop的IO Scheduler在等待和消耗的時間比deadline稍好，但差異不是很大。如果需要評估，還需要進一步詳細的在各個場景下的測試。
下圖是網(wǎng)上資料對不同調度算法的測試比較：
【測試三、比較這臺服務器SSD與相同配置SSD的消耗時間】
AVG D2C為0.0906ms，0.0934ms，差異不大，說明這臺服務器的SSD從響應時間上正常
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。
您可能感興趣的文章:- MySQL啟用SSD存儲的實例詳解
- MySQL 性能優(yōu)化的最佳20多條經驗分享
- MySQL數(shù)據(jù)庫引擎介紹、區(qū)別、創(chuàng)建和性能測試的深入分析
- MYSQL性能優(yōu)化分享(分庫分表)
- MySQL性能優(yōu)化之路---修改配置文件my.cnf
- MySQL性能設置
- 大幅優(yōu)化MySQL查詢性能的奇技淫巧
- mysql性能優(yōu)化之索引優(yōu)化
