MySQL如何避免使用swap(ZT)

Linux有很多很好的記憶體、IO排程機制，但是並不會適用於所有場景。對於DBA來說Linux比較讓人頭疼的一個地方是，它不會因為MySQL很重要就避免將分配給MySQL的地址空間對映到swap上。對於頻繁進行讀寫操作的系統而言，資料看似在記憶體而實際上在磁碟是非常糟糕的，響應時間的增長很可能直接拖垮整個系統。這篇blog主要講講我們作為DBA，怎樣儘量避免MySQL慘遭swap的毒手。

首先我們要了解點基礎的東西，比如說為什麼會產生swap。假設我們的實體記憶體是16G，swap是4G。如果MySQL本身已經佔用了12G實體記憶體，而同時其他程式或者系統模組又需要6G記憶體，這時候作業系統就可能把MySQL所擁有的一部分地址空間對映到swap上去。

cp一個大檔案，或用mysqldump匯出一個很大的資料庫的時候，檔案系統往往會向Linux申請大量的記憶體作為cache，一不小心就會導致L使用swap。這個情景比較常見，以下是最簡單的三個調整方法：
1、/proc/sys/vm/swappiness的內容改成0（臨時），/etc/sysctl.conf上新增vm.swappiness=0（永久）
這個引數決定了Linux是傾向於使用swap，還是傾向於釋放檔案系統cache。在記憶體緊張的情況下，數值越低越傾向於釋放檔案系統cache。
當然，這個引數只能減少使用swap的概率，並不能避免Linux使用swap。
2、修改MySQL的配置引數innodb_flush_method，開啟O_DIRECT模式。
這種情況下，InnoDB的buffer pool會直接繞過檔案系統cache來訪問磁碟，但是redo log依舊會使用檔案系統cache。值得注意的是，Redo log是覆寫模式的，即使使用了檔案系統的cache，也不會佔用太多。
3、新增MySQL的配置引數memlock
這個引數會強迫mysqld程式的地址空間一直被鎖定在實體記憶體上，對於os來說是非常霸道的一個要求。必須要用root帳號來啟動MySQL才能生效。

還有一個比較複雜的方法，指定MySQL使用大頁記憶體（Large Page）。Linux上的大頁記憶體是不會被換出實體記憶體的，和memlock有異曲同工之妙。具體的配置方法可以參考：http://harrison-fisk.blogspot.com/2009/01/enabling-innodb-large-pages-on-linux.html

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