MySQL大量使用swap檔案

壹頁書發表於2016-09-02
MySql
現象:
    一臺高配的MySQL資料庫伺服器,雙CPU48執行緒.
    CentOS 7
    本機磁碟是一萬五千轉的Raid 0.系統檔案,Swap都分配在了本機磁碟.
    伺服器掛載了一個SSD的磁碟陣列.資料庫檔案都存放在磁碟陣列中.
    
    系統執行之後,發現系統Swap大量使用,並且本機磁碟的IO使用率持續100%.

權宜之計:
    我把Swap挪到了盤陣中

原因:
    swap insanity
    NUMA架構

引用:
    對於單CPU，多核心的情況，每個核心訪問記憶體的速度是一樣的，這種架構稱為SMP（Symmetric multiprocessing， 對稱多處理器），又叫UMA(Uniform Memory Architecture，與NUMA相對，一致性記憶體訪問架構)。
可以看到，每個CPU都有一組配套的記憶體槽。每個CPU訪問自身的記憶體插槽，速度都很快，但對於主機板上的其他記憶體插槽，訪問速度就會下降。這種架構被稱為NUMA。

    對於Linux來說，載入的時候就會檢測記憶體，計算CPU到記憶體的訪問開銷，將CPU和記憶體分成一組組的。每個程式和執行緒，都會繼承父程式的NUMA策略，這種策略包括這個程式/執行緒會在哪個CPU上執行，分配的記憶體應該用哪組插槽的。

    面對記憶體分配，只要一經分配到指定的CPU—記憶體槽，就不會再挪動了。對於資料庫這類應用，理想情況下是一個單一的多執行緒程式，吃掉了幾乎所有的系統記憶體，並儘可能多的消耗其餘的系統資源例如IO。

    對於兩個CPU的NUMA架構來說，如果一個核心分配的記憶體超過系統記憶體的一半，就會出現問題。而Linux的分配策略是，首先使用CPU 0，然後再使用CPU 1。這時候就會出現一種情況，CPU 0的記憶體組已經率先使用完了，但系統還有很多空閒記憶體，都在CPU 1上。這時候，Linux會選擇將CPU 0的記憶體刷到磁碟上，以換取可用記憶體。但是，swap過程遠比跨CPU訪問記憶體要慢啊。這就會造成記憶體還沒用光，但資料庫瘋狂刷盤的現象了。



參考:
http://www.cnblogs.com/Lifehacker/p/database_swap_insanity_on_Linux.html
https://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29254281/viewspace-2124410/，如需轉載，請註明出處，否則將追究法律責任。

相關文章