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

2024-07-24 12:31:39

字體：大中小

來源：轉載

供稿：網友

作為一位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內核>>類似書籍。

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

--其實如果要看內存剩余空間，這兩個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)

  實際上這里我們明顯看到一個重點用戶態的匿名頁，匿名頁包含了進程了堆和棧空間，
那么數據庫的自己分配的內存明顯是堆內存，這些空間是可以被交換(swap)的，而內核
太高速緩存的頁一般為可同步和可丟棄頁。
  接下來釋放內存的原則：
  1、首先釋放沒有任何進程使用的內核態高速緩存頁
  2、用戶態進程的所有頁是可以回收和交換的
  3、回收共享頁
  4、根據LRU算法回收內核態高速緩存中的頁，優先換出干凈頁，因為不需要
     寫磁盤。
  這里還透露一個ORACLE 11G中使用tmpfs虛擬文件系統也是會被SWAP到交換分區的。
4、交換(swap)和交換傾向
   交換分區用于擴充實際內存的大小，但是他是存在于物理磁盤，它速度可想而知，
也成了DBA非常關注的一個部分，因為一旦使用SWAP那么數據庫的性能可想而知。
   前面我們已經描述了用戶態內存空間都是可以交換的包括tmpfs虛擬文件系統，
相反內核態高速緩存頁反而是不會進入SWAP空間的，他只是在內存不足的情況下
進行同步和回收。

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

5、OOM(out of memory)
    如果交換區已經滿了，并且沒有內核態高速緩存可以回收和同步，那么就會啟用OOM
來刪除進程，輸入LINUX內核一書用外科醫生為病人截肢來比喻，非常恰當，雖然不
情況但是已經沒有退路。
    那么如果我們設置了swappiness=0，那么用不了交換區滿，因為用戶態內存比如數據
占用內存不能使用交換區，感覺這個時候交換已經沒用了。這就是一個潛在的風險，但是
對于數據庫軟件來說，頻繁大量的使用SWAP換入換出和DOWN機沒什么區別，我就遇到過
大量使用SWAP交換區換出換入頁的ORACLE(10GR2)數據庫基本動不了的，等待事件為
shared pool、libarycache，最后使用巨頁進行解決。

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

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

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

--設置vm.swappiness=0(或者1)，根據交換傾向讓用戶態內存不交換，如果如此作者認為如果未設置
  O_DIRECT那么應該保證有足夠的內存，那么數據庫內存最好不要超過物理內存的50%(請各位指點)，
  避免出現OOM問題。

（編輯：武林網）

上一篇：percona MYSQL 5.7.13 5.7.14 MYSQLDUMP 輸入報錯delimiter

下一篇：MySQL 5.7.22 rpm 安置方式