MySQL效能調優之Memory or SSD?

當一個傳統的向外擴充的方式對於MySQL來講變得流行，看看我們不得不擴充哪一方面（便宜的記憶體？快速儲存？更好的電源效率？）將會變得非常有趣。這裡確實有很多種選擇——我每周大概會遇到一個客戶使用Fushion-IO 卡。然而，我卻看到了他們一個有趣的選擇——他們選擇購買一個SSD，當他們每秒仍然能讀取很多頁的時候（這時，我寧願選擇購買記憶體來取代），而使用儲存磁碟機做“寫操作”使用。

 

在這裡，我提出幾個參考標準來供你確認是否是以上我說的這種情況：

• Percona-XtraDB-9.1 release
• Sysbench(開源效能測試工具)的OLTP有8千萬行的“工作量”（大概等同於18GB的資料+索引）
• XFS 檔案系統選擇nobarrier選項安裝
• 測試回合具有：

1.        帶有BBU的RAID 10硬碟超過8塊（所謂BBU，社區的解釋是在掉電的情況下，能夠cache資料72h，當機器供電正常，再從cache中將資料寫入磁碟）

2.        Inter SSD X25-E 32GB

3.        FushionIO 320GB MLC【1】

• 對於每一次測試，在啟動並執行時候將緩衝池設定在2G到22G之間（為了和合適的記憶體比較效能）
• 硬體設定：

Dell PowerEdgeR900

4 QuadCoreIntel(R) Xeon(R) CPU E7320 @ 2.13GHz (16 cores in total)

32GB of RAM

RAID10 on 8disks 2.5” 15K RPMS

FusionIO 160GBSLC

FusionIO 320GBMLC

OS:

CentOS 5.5

XFS filesystem

開始，我們對RAID 10的儲存做一個測試以建立一個基準。Y軸是每秒傳輸的資料（傳輸速率，它越大越好）。X軸是innodb_buffer_pool_size的大小。

我特地挑選了關於該測試中的三個有趣的點

• A點，當資料完全符合緩衝池大小（最佳效能）。一旦你達到該點，簡直就像記憶體的進一步增加，瞭解該資訊很重要。
• B座標出現在當資料剛開始超過緩衝池的大小。這對於許多使用者來講是最讓人頭疼的一點了。因為當記憶體下降僅10%，而效能卻比原來降低了2.6倍。在產品中，這通常應對著這樣的說辭——“上個星期一切看起來都還OK，但它卻正在變得越來越慢！”。我想建議你，增加記憶體是迄今為止最好的做法，在這種情況下。
• C點展示資料大約是緩衝池三倍的地方。它是一個有趣的點，既然你不能夠計算出記憶體的花費（可能不瞭解未來遇到瓶頸需要耗費多少購買記憶體的成本），這是購買一個SSD可能更為合適。

1 2 下一頁