min_free_kbytes 設定過大案例問題解析

賀子_DBA時代發表於2021-05-06
現象：
1.zabbix提示連線不上mysql機器上的agent，無法獲取伺服器訊息；
2.嘗試ssh到這臺機器，報錯：
[root@dba-salt-manager ~]#  ssh  ops@10.12.32.93 -o StrictHostKeyChecking=no
kex_exchange_identification: Connection closed by remote host
Connection closed by 10.128.32.93 port 22
3. /var/log/messages報錯如下：
May  5 09:25:11 mysql-account_weili-db01 kernel: Core dump to |/usr/libexec/abrt-hook-ccpp 11 0 17637 996 994 1620177911 e 17637 17637 mysql-account_weili-db01 pipe failed
May  5 09:25:11 mysql-account_weili-db01 systemd: Failed to fork: Cannot allocate memory
May  5 09:25:11 mysql-account_weili-db01 systemd: zabbix-agent.service failed to run 'stop' task: Cannot allocate memory
May  5 09:25:11 mysql-account_weili-db01 systemd: Unit zabbix-agent.service entered failed state.
May  5 09:25:11 mysql-account_weili-db01 systemd: zabbix-agent.service failed.

問題分析：
由於vm.min_free_kbytes設定的為2G太大，該引數控制系統所保留空閒記憶體的最低限！
設定的2G, free還有2G,但是available沒有了，也就是程式已經無可用的記憶體了，但是由於vm.min_free_kbytes設定的過大， linux觸發回收記憶體的閾值高（watermark [low]閾值和vm.min_free_kbytes成正比！），儘管已經沒有可用的記憶體，但是也linux沒有回收記憶體，所以程式就再不能分配記憶體了！就報前面的錯了！

關於vm.min_free_kbytes在系統初始化時會根據記憶體大小計算一個預設值，計算規則是：
min_free_kbytes = sqrt(lowmem_kbytes * 16) = 4 * sqrt(lowmem_kbytes)(注：lowmem_kbytes即可認為是系統記憶體大小）
如果沒有在/etc/sysctl.conf設定，那麼預設計算出來的值有最小最大限制，最小為128K，最大為64M
一：設定過大會引發記憶體浪費，並且頻繁觸發oom，（前提是vm.panic_on_oom =0）
另外根據核心引數vm.panic_on_oom 設定值的不同而有不同的行為
vm.panic_on_oom=0 系統會提示oom ，並啟動oom-killer殺掉佔用最高記憶體的程式
vm.panic_on_oom =1. 系統關閉oom,不會啟動oom-killer,而是會自動重啟
二：如果設定過小就會 頻繁導致核心進行direct reclaim（直接回收），即直接在應用程式的程式上下文中進行回收，再用回收上來的空閒頁滿足記憶體申請，因為是需要先回收然後再分配，所以會阻塞應用程式，帶來一定的響應延遲；  設定過小會相對更頻繁的觸發direct reclaim，更頻繁 原因在於：如果vm.min_free_kbytes設定的過小，就會導致watermark [low] 和 watermark[min]這倆值之間的差值比較小，這樣的話當觸發watermark [low] 的閾值後，還沒有來得及回收夠記憶體，就觸發watermark[min]了，也就是更頻繁觸發了direct reclaim（直接回收），就可能更頻繁的去導致mysql的瞬間抖動！
min_free_kbytes的主要用途是計算影響記憶體回收的三個引數 watermark[min/low/high]
1) watermark[high] > watermark [low] > watermark[min]，各個zone各一套（每個結點的記憶體被分為多個塊，稱為zones，它表示記憶體中一段區域）
2)在系統空閒記憶體低於 watermark[low]時，開始啟動核心執行緒kswapd進行記憶體回收（每個zone一個），直到該zone的空閒記憶體數量達到watermark[high]後停止回收。如果上層申請記憶體的速度太快，導致空閒記憶體降至watermark[min]後，核心就會進行direct reclaim（直接回收），即直接在應用程式的程式上下文中進行回收，再用回收上來的空閒頁滿足記憶體申請，因此實際會阻塞應用程式，帶來一定的響應延遲，而且可能會觸發系統OOM。這是因為watermark[min]以下的記憶體屬於系統的自留記憶體，用以滿足特殊使用，所以不會給使用者態的普通申請來用；

三：最近有業務線在調大min值得時候導致物理機hang引發故障，得出一些經驗和建議：
  1. 對於線上128G的記憶體的機器，可以考慮將min設定為512M左右。因為，太大了，可能會導致記憶體的浪費；當然如果只有40G的物理機，更不要考慮把min設定超過1G了，這樣會導致頻繁的觸發記憶體回收；具體最佳化也要根據業務來看。
  2. 關鍵是在於調整記憶體的核心引數的時候！ 調大的風險遠大於調小的風險！ 如果有人想將 vm.min_free_kbytes 調大，千萬要注意當前的水位， 如果一旦調大 vm.min_free_kbytes 立刻觸發direct reclaim，可能會導致機器hang住，ping的通，ssh不上，影響業務！hang住的原因是當 vm.min_free_kbytes 是512M的時候，此時 free只有1G，此時正常執行，此時如果調大vm.min_free_kbytes 到5G，將會direct reclaim失敗。
解決問題：
把引數調成64M,需要注意如果你已經調大了vm.min_free_kbytes=2G了，那麼你需要先把檔案/etc/sysctl.conf中的值修改成vm.min_free_kbytes = 67584，然後再sysctl -p ,最後再把引數去掉！不能直接去掉vm.min_free_kbytes ,因為只有在伺服器初始化的時候才會自己去計算出個值！
順帶介紹下如下三個引數：針對linux的最佳化，可以緩解瞬間的刷髒導致資料庫的抖動！
vm.min_free_kbytes=409600;
vm.vfs_cache_pressure=200;  #預設是100，值越大，越傾向於回收cache!
vm.swappiness=40    #越低越不使用交換分割槽，效能越好，我們vm.swappiness = 10
註釋：
vm.vfs_cache_pressure調整清理inode/dentry caches的優先順序（預設為100）
降低vm.vfs_cache_pressure會導致核心傾向於保留dentry和inode快取。將vm.vfs_cache_pressure增加到100以上會導致核心更喜歡回收dentries和inode！
vm.swappiness Linux核心引數，控制換出執行時記憶體的相對權重。swappiness引數值可設定範圍在0到100之間。 低引數值會讓核心儘量少用交換，更高引數值會使核心更多的去使用交換空間。預設值為60（參考網路資料：當剩餘實體記憶體低於40%（40=100-60）時，開始使用交換空間）。對於大多數作業系統，設定為100可能會影響整體效能，而設定為更低值（甚至為0）則可能減少響應延遲



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

相關文章