LINUX系統編程 SWAP原理以及和數據庫(MYSQL ORACLE)關系

作為一位DBA長期以來一直受到一些關于SWAP使用的問題，比如如下問題：
1、為了我 free 中buffer/cache明明還有空間為什么SWAP使用了？
2、哪個(些)進程使用了最多的SWAP？
3、如果在ORACLE或者MYSQL避免使用SWAP？
4、為什么要使用直接路徑繞過操作系統緩沖(O_DIRECT)？
5、ORACLE 11G使用tmpfs虛擬文件系統，內存可能被SWAP出嗎？
6、設置/proc/sys/vm/swappiness為0后有什么風險？


本文參考<<深入理解liunx內核>><<LINUX系統編程手冊>>結合數據庫希望給出
比較明了的答案，但是由于涉及內容較深特別是系統知識，而作者也沒有詳細
研究過LINUX內核和實現，只是從API調用者和DBA的角度來看，難免有概念不準
或者有誤的地方，望指出共同討論。如果特別有興趣請自行參考<<深入理解liunx內核>>
類似書籍。

1、LINUX 高速頁面緩沖與數據庫BUFFER的關系
為了闡明這些問題，不得不從LINUX頁高速緩沖說起，在數據庫中我們都知道有
一塊非常大的緩沖區用于存放最近訪問的數據，如ORACLE的BUFFER_CACHE、INNODB
的innodb_buffer_pool_size，這片區域至關重要，直接影響到數據庫物理讀取的可能性。
所以一般數據庫指導意見都為系統物理內存的60%以上(當然ORACLE 還有share_pool
一般ORACLE建議memory_target包含SGA+PGA為系統內存60%以上),而在LINUX OS看來
數據軟件只是用戶態的匿名頁空間，既然如此重要LINUX OS當然也是如此，他也
有這樣一部分內存為內核態頁高速緩存,LINUX 采用一種比較粗狂的分配方式，只要
數據讀取(還有預讀-局部性原理)它就會進行緩存，它只受限于2個方面
--物理內存大小
--用戶態空間占用內存大小
(LINUX系統編程13章)
這樣做是因為這樣能夠大大加快READ(),WIRTE()調用的速度，如果用戶態程序沒有自己的
緩存的時候，那么熱數據緩存在LINUX頁高速緩沖中，那么下次讀取的時候速度大大加快
那么就數據庫而言數據塊可能存在于：
DISK DATA PAGE-->KERNAL BUFFER/CACHE PAGE--->USER(DATABASE) BUFFER PAGE
這樣一個順序,這里是我自己的理解，因為我編程的時候也時常自己分配一塊內存區域
(malloc族函數)
如果這個時候稍加思考，我們可以看到數據頁可能存在于2個地方一個是KERNEL一個是
USER(DATABASE) BUFFER，前者是LINUX OS級別的，后者是DATABASE級別的。在LINUX中
我們通過FREE可以查看到
[root@testmy ~]# free
             total       used       free     shared    buffers     cached
Mem:       4052856    2009000    2043856          0     146404    1327484
-/+ buffers/cache:     535112    3517744
Swap:      8388600          0    8388600

第一行：從OS的角度看內存使用
TOTAL:總的內存大小
USED :LINUX來看使用的空間，用戶態內存(比如數據庫內存)+內核態高速緩沖區
FREE :剩余的內存大小 4052856-2009000
BUFFERS和CACHED：一起說明了內核占用的大小
SHRED:共享內存大小，應該存在于用戶態
第二行：從用戶態的角度來看內存使用
used：用戶態內存(比如數據庫內存)
free：應用程序可能可以使用的大小，第一行的 UESD - (buffers+cached)

--其實如果要看內存剩余空間，這兩個FREE都是只有部分參考價值。
另外如果要說buffers和cache的區別,這一點在深入LINUX內核 P607頁有相關
的說明，實際上在內核2.4.10后就沒有區別了，所以進行描述。
關于內核態、用戶態可以參考：
http://blog.itpub.net/7728585/viewspace-2129073/
的部分觀點和配圖

2、為什么數據庫可以采用O_DIRECT打開文件模式(linux open() api flag)
--數據庫軟件有自己的內存塊的管理方法，不需要內核態高速緩沖區，這樣有浪費內存
  空間的風險。如上：
DISK DATA PAGE-->KERNAL BUFFER/CACHE PAGE--->USER(DATABASE) BUFFER PAGE
我們去掉了>KERNAL BUFFER/CACHE PAGE，直接從DIS DATA PAGE--> USER BUFFER PAGE
--數據庫軟件有自己的內存塊的管理方法，不需要內核態高速緩沖區，這樣讓READ()，
  WRITE()操作有KERNAL BUFFER/CACHE PAGE這一層額外的開銷
  關于這一點可以參考
  http://blog.itpub.net/7728585/viewspace-2129558/
  的部分觀點和配圖加以理解

3、內存不足頁回收
   我們知道LINUX內存分配使用伙伴算法，在LINUX這種粗狂的內存分配方式下，一般來說
這種情況下物理內存遲早會全部映射完。這個時候就需要一種制度或者說是算法來進行頁
回收，這就是LINUX的PFRA算法
  關于那些頁可以回收，還是看一下深入LINUX內核第17章：
  Swappable  Anonymous pages in User Mode address spaces
             Mapped pages of tmpfs filesystem (e.g.,pages of IPC sharedmemory)
             
  Syncable   Mapped pages in User Mode address spaces Pages included in the 
             page cache and containing data of disk files Block device buffer 
             pages Pages of some disk caches(e.g., the inode cache)
             
  Discardable  Unused pages included in memory caches (e.g., slab allocator caches)
             Unused pages of the dentry cache
  
  實際上這里我們明顯看到一個重點用戶態的匿名頁，匿名頁包含了進程了堆和棧空間，
那么數據庫的自己分配的內存明顯是堆內存，這些空間是可以被交換(swap)的，而內核
太高速緩存的頁一般為可同步和可丟棄頁。
  接下來釋放內存的原則：
  1、首先釋放沒有任何進程使用的內核態高速緩存頁
  2、用戶態進程的所有頁是可以回收和交換的
  3、回收共享頁
  4、根據LRU算法回收內核態高速緩存中的頁，優先換出干凈頁，因為不需要
     寫磁盤。
  這里還透露一個ORACLE 11G中使用tmpfs虛擬文件系統也是會被SWAP到交換分區的。
4、交換(swap)和交換傾向
   交換分區用于擴充實際內存的大小，但是他是存在于物理磁盤，它速度可想而知，
也成了DBA非常關注的一個部分，因為一旦使用SWAP那么數據庫的性能可想而知。
   前面我們已經描述了用戶態內存空間都是可以交換的包括tmpfs虛擬文件系統，
相反內核態高速緩存頁反而是不會進入SWAP空間的，他只是在內存不足的情況下
進行同步和回收。
   那么接下來要說一下交換傾向(深入LINUX內核 P688):
   交換傾向=映射比率/2+負荷值+交換值
--映射比率：用戶態內存實際物理內存占用總物理內存大小的比重 
很明顯是：
-/+ buffers/cache:     535112    3517744 這里的535112/4052856
如果比重大則說明用戶態內存占用物理內存更大，如果比較小則說明內核態高速緩沖頁
占用更大。
  顯然這里 /2,即使最多也就是50%，也就是50 當然不可能。
-- 負荷值：詳細參考深入LINUX內核，一般不可能為50，知道這一點已經足夠做出推論
           了。
-- 交換值(SWAPPINESS):用戶可以設置的,默認為60,sysctl -a|grep swappiness可以看到

  如果交換傾向大于等于100時，內存緊張的時候，頁才從用戶態內存進行交換出去，
然后釋放，如果設置交換值(SWAPPINESS)=0，那么映射比率/2+負荷值不可能大于等于
100，這就不可能讓用戶態內存交換出去，對于數據庫當然是各種buffer_cache,這是
對數據庫有利的。
如何修改：
--永久修改
修改 /etc/sysctl.conf 加上:
　　vm.swappiness=0
sysctl -p生效
--臨時修改
echo 0 > /proc/sys/vm/swappiness

這里我們也不得不在看下
[root@testmy ~]# free
             total       used       free     shared    buffers     cached
Mem:       4052856    2009000    2043856          0     146404    1327484
-/+ buffers/cache:     535112    3517744

這里的兩個free值，前文說過第一個free是OS來看的，第二個是app應用來看的，實際上
他們只有參考價值而沒有絕對的含義，因為實際的內存空閑應該是2043856，但是這個值
在一般的安裝數據庫應用的LINUX操作系統中為0，第二列3517744，包含了buffer+cached
的內核態高速緩沖頁，雖然內核態高速緩沖頁可以回收和同步，但是由于交換傾向的存在
而且并不是有的內核態高速緩沖區頁都能回收和同步，在安裝有數據庫應用的LINUX操作
系統中，一般來說這一列值非常大，但是偶爾也有使用SWAP的情況。其實使用SWAP如果不
存在SWAP的換出換入，數據庫也不會慢。


5、OOM(out of memory)
    如果交換區已經滿了，并且沒有內核態高速緩存可以回收和同步，那么就會啟用OOM
來刪除進程，輸入LINUX內核一書用外科醫生為病人截肢來比喻，非常恰當，雖然不
情況但是已經沒有退路。
    那么如果我們設置了swappiness=0，那么用不了交換區滿，因為用戶態內存比如數據
占用內存不能使用交換區，感覺這個時候交換已經沒用了。這就是一個潛在的風險，但是
對于數據庫軟件來說，頻繁大量的使用SWAP換入換出和DOWN機沒什么區別，我就遇到過
大量使用SWAP交換區換出換入頁的ORACLE(10GR2)數據庫基本動不了的，等待事件為
shared pool、libarycache，最后使用巨頁進行解決。
   我在ORACLE METALINK上也找到這樣一個文章
The confusion about vm.swappiness comes from the fact that in older Red Hat kernels, 
a value of 0 for vm.swappiness resulted in the minimal amount of swapping to avoid 
an out of memory condition. In newer kernels (as of RHEL kernel 2.6.32-303), a value 
of 0 will completely disable swap, but a value of 1 will provide the minimal amount 
of swapping to avoid an out of memory condition.

My general recommendation is to set vm.swappiness to a value of 1 for a dedicated 
MySQL server.  There is not much practical difference between a value of 0 and a 
value of 1 on older kernels, but 1 is the safe setting to avoid an OOM condition 
on newer kernels (assuming that some swap space is available, of course).

   我們可以看到設置為swappiness=0確實加大了OOM的風險，它建議為1最小化swap

6、數據庫服務器的交換設置


--設置O_DIRECT，依賴數據庫自身內存，減少內存中數據的冗余浪費內存，減少SWAP使用的可能


  MYSQL適用 innodb_flush_method = O_DIRECT
  
  ORACLE謹慎使用 filesystemio_options=SETALL，DIRECTIO 可能有存在BUG，使用前務必查看
  metalink，看看版本是否有bug
  實際ORACLE 11G很多大表的全表掃描都是使用
  Direct Path Read的方式減少了對數據庫本身和內核高速緩沖頁的沖擊
  
--設置vm.swappiness=0(或者1)，根據交換傾向讓用戶態內存不交換，如果如此作者認為如果未設置
  O_DIRECT那么應該保證有足夠的內存，那么數據庫內存最好不要超過物理內存的50%(請各位指點)，
  避免出現OOM問題。
  
  MYSQL適用 
  ORACLE查詢METALINK沒有相關說明，原理上可以使用


--設置巨頁
  ORACLE 適用，注意11gMEMORY_TARGET使用tmpfs和巨頁有沖突我在ORACLE10G中設置過
 
  MYSQL  可以使用，但是沒用過


--除了buffer以外其他和內存相關的參數是否過大
 mysql：sort_buffer tmp_table_size join_buffer_size等
 oracle：分開SGA和PGA，PGA是否得當

--最簡單的各位同仁多買點物理內存吧，物理內存也不貴了

最后來回答開始的問題
1、為了我 free 中buffer/cache明明還有空間為什么SWAP使用了？
   參考部分4   
2、哪個(些)進程使用了最多的SWAP？
   top后按F選擇p然后回車會出現SWAP供查詢 
   /proc/pid/stats 包含了swap使用量，可以使用程序遍歷排序
   
3、如果在ORACLE或者MYSQL避免使用SWAP？
   參考部分6
4、為什么要使用直接路徑繞過操作系統緩沖(O_DIRECT)？
   參考部分2
5、ORACLE 11G使用tmpfs虛擬文件系統，內存可能被SWAP出嗎？
   參考部分3
6、設置/proc/sys/vm/swappiness為0后有什么風險？
   參考部分5
   
參考：
<<深入理解liunx內核>> 15 16 17
<LINUX系統編程手冊> 13
ORACLE METALINK