使用符號連接分布IO

利用作業系統的符號連接，將不同的資料庫、表、索引指向不同的物理磁盤，從而達到分布磁盤IO的目的，

禁止作業系統更新檔案的atime屬性

對于讀寫頻繁的資料庫檔案來說，記錄檔案的訪問時間一般沒有用處，卻會增加磁盤的負擔，影響IO性能，

因InnoDB使用快取機制來快取索引和資料，作業系統的磁盤IO快取對其性能不僅沒有幫助，甚至還有反作用，在InnoDB快取充足的情況下，可以考慮使用裸設備來存放共享表空間，

Linux實作了4中IO調度演算法：

NOOP演算法（No Operation）：不對IO請求排序，除了合并請求也不會進行其他任何優化，用最簡單的先進先出FIFO佇列順序提交IO請求，NOOP演算法主要面向隨機訪問設備，如SSD，
最后期限演算法（Deadline）：除了維護一個擁有合并和排序功能的請求佇列外，額外維護兩個帶有超時的FIFO佇列，分別是讀請求佇列和寫請求佇列，當調度器發現讀/寫請求佇列中的請求超時，會優先處理這些請求，
預期演算法（Anticipatory）：是基于預測的IO演算法，和Deadline類似，也維護了三個請求佇列，區別在于，Anticipatory處理完一個IO請求后并不會直接回傳處理下一個請求，而是等待片刻（默認6ms），等待期間如果有新來的相鄰扇區的請求，會直接處理新來的請求，Anticipatory適合寫入較多的環境，不適合資料庫等隨機讀較多的環境，
完全公平佇列（Complete Fair Queuing/CFQ）：把IO請求按照行程分別放入行程對應的佇列中，其公平是針對行程而言的，CFQ以時間片演算法為前提，輪轉調動佇列，

建議MySQL資料庫環境設定為Deadline演算法，

RAID（Redundant Array of Inexpensive Disks），即廉價磁盤冗余陣列，通常叫做磁盤陣列，

RAID級別：

RAID卡都有寫快取（Battery Backed Write Cache），寫快取對IO性能的提升非常明顯，為了避免掉電丟失寫快取中的資料，RAID卡都有電池（Battery Backup Unit，簡稱BBU），

RAID快取策略包括4部分：

寫策略
- WriteBack：將資料寫入快取后直接回傳，
- WriteThrough：不使用寫快取，直接寫入磁盤才回傳，
預讀策略
- ReadAheadNone：不開啟預讀，
- ReadAhead：開啟預讀，預先把后面的資料加載入快取，
- ReadAdaptive：自適應預讀，在快取和I/O空閑的時候進行預讀，
讀策略
- Direct：讀操作不進行快取，
- Cached：讀操作進行快取，
故障策略
- Write Cache OK if Bad BBU：如果BBU出問題，不使用寫快取，從WriteBack自動切換到WriteThrough，
- No Write Cache if Bad BBU：如果BBU出問題，仍然使用寫快取，

RAID卡電池會定期啟動自動校準模式，即定期充放電，期間，RAID卡控制器不會啟動BBU，同時（除非修改快取策略），也會禁用WriteBack寫快取策略，以保證資料完整性，造成系統IO性能會出現較大波動，

解決方案：

目前的商用服務器系統架構大體分為三類（一般SMP或NUMA較多）：

對稱多處理器架構（SMP/Symmetric Multi-Processor）：一臺計算機上匯集了一組CPU，各CPU平等地共享記憶體、IO等資源，SMP也被稱為一致存盤訪問架構（UMA/Uniform Memory Access），由于共享，導致SMP服務器的擴展能力非常有限，最受限制的是記憶體，因每個CPU必需通過相同的總線訪問相同的記憶體資源，
非一致存盤訪問架構（NUMA/Non-Uniform Memory Access）：一臺計算機分為多個節點，每個節點內部擁有多個CPU，節點內部使用共有的記憶體控制器，節點之間通過互聯模塊進行連接和資訊互動，節點的所有記憶體對于本節點的所有CPU都是等同的，對于其他節點的所有CPU都是不同的，每個CPU都可以訪問整個系統的記憶體，但訪問本地節點的較快，訪問非本地節點的較慢，因此，隨著CPU數量的增加，系統性能并不能線性增加，
海量并行處理架構（MPP/Massive Parallel Processing）：由多個SMP服務器通過一定的節點互聯網路進行連接，每個節點只訪問本地資源，不訪問其他節點的資源，因而，理論上可以無限擴展，

NUMA的記憶體分配策略有4種：

MySQL對NUMA特性支持不好，

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/4582.html

標籤：MySQL

上一篇：MySQL