1. 程式人生 > >MySQL伺服器SSD效能問題分析與測試

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效能的指標。

【測試一、比較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倍,對於寫入為主的系統,建議HP SSD Smart Path關閉,SSD控制器Caching開啟

【測試二、比較noop和deadline兩種I/O排程演算法的效能】

目前磁碟的排程演算法有如下四種,我們系統中的配置值為deadline,很多資料上建議SSD配置為noop

1、Anticipatory,適用於個人PC,單磁碟系統;

2、CFQ(Complete Fair Queuing),預設的IO排程演算法,完全公平的排隊排程演算法

3、Deadline,按照截止期限來迴圈在各個IO佇列中進行排程

4、noop,簡單的FIFO佇列進行排程

下面都在HP SSD Smart Path關閉的情況下測試,

1、deadline, 主要關注G2I和I2D

2、修改為noop

 

【結論】

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

下圖是網上資料對不同調度演算法的測試比較:

 

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

AVG D2C為0.0906ms,0.0934ms,差異不大,說明這臺伺服器的SSD從響應時間上正常