MySQL服務器SSD性能問題分析與測試

【問題】

咱們有臺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性能的指標。

【測試1、比較HP SSD Smart Path開啓先後SSD的寫入性能】

一、HP SSD Smart Path開啓，SSD控制器Caching關閉，Cache Ratio: 100% Read / 0% Write

測試結果以下，主要關注D2C（IO請求在SSD上消耗的時間）的AVG值，約爲0.217ms

二、HP SSD Smart Path關閉，SSD控制器Caching開啓，Cache Ratio: 10% Read / 90% Write

測試結果以下，主要關注D2C（IO請求在SSD上消耗的時間）的AVG值，約爲0.0906ms

【結論】

前者在硬件上的消耗時間是後者的約2.4倍，對於寫入爲主的系統，建議HP SSD Smart Path關閉，SSD控制器Caching開啓

 

【測試2、比較noop和deadline兩種I/O調度算法的性能】

目前磁盤的調度算法有以下四種，咱們系統中的配置值爲deadline，不少資料上建議SSD配置爲noop

一、Anticipatory，適用於我的PC，單磁盤系統；

二、CFQ(Complete Fair Queuing)，默認的IO調度算法，徹底公平的排隊調度算法

三、Deadline，按照截止期限來循環在各個IO隊列中進行調度

四、noop，簡單的FIFO隊列進行調度

下面都在HP SSD Smart Path關閉的狀況下測試，

一、deadline, 主要關注G2I和I2D

二、修改成noop

 

【結論】

noop的IO Scheduler在等待和消耗的時間比deadline稍好，但差別不是很大。若是須要評估，還須要進一步詳細的在各個場景下的測試。

下圖是網上資料對不一樣調度算法的測試比較：

 

【測試3、比較這臺服務器SSD與相同配置SSD的消耗時間】

AVG D2C爲0.0906ms，0.0934ms，差別不大，說明這臺服務器的SSD從響應時間上正常