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從響應時間上正常

感謝各位的閱讀！關于“MySQL服務器中SSD性能問題的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！