高效能MySQL.讀書筆記（二）作業系統和硬體優化
阿新 • • 發佈：2019-01-31
使用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控制器真的整體上飽和了。
雖然有很多因素需要在快閃記憶體、硬碟和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控制器真的整體上飽和了。