1. 程式人生 > >高效能MySQL.讀書筆記(二)作業系統和硬體優化

高效能MySQL.讀書筆記(二)作業系統和硬體優化

使用Flashcache
雖然有很多因素需要在快閃記憶體、硬碟和RAM之間權衡,在儲存層次結構中,這些裝置沒有被當作一個整體處理。有時可以使用磁碟和記憶體技術的結合,這就是Flashcache。

Flashcache是一個Linux核心模組,使用Linux的裝置對映器(Device Mapper)。它在記憶體和磁碟之間建立了一箇中間層。這是Facebook開源和使用的技術之一,可以幫助其優化資料庫負載。
Flashcache建立了一個塊裝置,並且可以被分割槽,也可以像其他塊裝置一樣建立檔案系統,特點是這個塊裝置是由快閃記憶體和磁碟共同支撐的。快閃記憶體裝置用作讀取和寫入的智慧快取記憶體。

儘管Flashcace理論上可能更高效,但最終的效能表現並不如底層的快閃記憶體儲存那麼好,不過它仍然比磁碟快很多,所以還是值得考慮的方案。
應用使用Flashcache嗎?如果你覺得不確定,最好得到專家的意見。歸根到底,Flashcache是否合適是一個複雜的決定,涉及的因素很多。一般情況下,它似乎最適合以讀為主的I/O密集型負載,並且工作集太大,用記憶體優化並不經濟的情況。

優化SSD儲存上的MySQL
增加InnoDB的I/O容量
調整innodb_io_capacity選項到更大的值。
讓InnoDB日誌檔案更大
因為如果日誌在磁碟上調的太大,崩潰恢復時需要隨機I/O訪問,會恢復很長時間。快閃記憶體讓這個過程快很多,所以可以設定更大的日誌檔案。
把一些檔案從快閃記憶體移到RAID
因為InnoDB日誌是以512位元組為單位的順序I/O寫下去,用快閃記憶體並不比RAID磁碟快。
禁用預讀
配置InnoDB重新整理演算法
為快閃記憶體裝置設定innodb_flush_neighbor_pages = 0。
禁用雙寫緩衝
限制插入緩衝大小

提醒一點,針對SSD上的很多功能和優化在標準版本的InnodDB中是無效的,只在Percona Server和XtraDB中適用。

RAID快取

儘量關閉RAID的讀或預讀快取,因為作業系統和資料庫都有自己更大的快取,RAID上的快取是很小的,也是很珍惜的,儘量留給寫快取用。
寫入快取對同步寫非常有用,例如事務日誌和二進位制日誌,但是除非控制器有電池備份單元(BBU)或其他非易失性儲存,否則不應該啟用RAID快取。

為了測試是否真的可以依賴RAID控制器的BBU,必須像實際情況一樣切斷電源一段時間,因為某些單元斷電超過一段時間後就可能丟失資料。這裡再次重申,任何一個環節出現問題都會使整個儲存元件失效。

使用多磁碟券
MySQL建立了多種型別的檔案:
資料和索引檔案
事務日誌檔案
二進位制日誌檔案
常規日誌檔案(例如,錯誤日誌,查詢日誌和慢查詢日誌)
臨時檔案和臨時表

InnoDB預設配置是將這些檔案到放到一個目錄的。然而,有時把這些檔案分開放到多個卷可以幫助解決I/O負載高的問題。

建議針對一些大表或特殊功能表,將表文件放到單獨的捲上,也可以使用分割槽表。

有的標準建議,就是把事務日誌檔案和資料檔案放在不同捲上,這樣日誌的順序I/O和資料的隨機I/O不會相互影響。但是除非有很多硬碟(20或更多)或者快閃記憶體儲存。
如果RAID控制器有BBU,分離事務日誌與資料檔案就沒有必要了。因為即使有大量的事務日誌寫入,RAID快取通常會合並I/O請求,通常只會得到每秒的物理順序寫請求。這通常不會干預資料檔案的隨機I/O,除非RAID控制器真的整體上飽和了。