執行grep -i commit /proc/meminfo
看到commitlimit和committed_as引數。
commitlimit是乙個記憶體分配上限,commitlimit = 物理記憶體 * overcommit_ratio(預設50,即50%) + swap大小
committed_as是已經分配的記憶體大小。
vm.overcommit_memory檔案指定了核心針對記憶體分配的策略,其值可以是0、1、2
0: (預設)表示核心將檢查是否有足夠的可用記憶體**用程序使用;如果有足夠的可用記憶體,記憶體申請允許;否則,記憶體申請失敗,並把錯誤返回給應用程序。0 即是啟發式的overcommitting handle,會儘量減少swap的使用,root可以分配比一般使用者略多的記憶體
1: 表示核心允許分配所有的物理記憶體,而不管當前的記憶體狀態如何,允許超過commitlimit,直至記憶體用完為止。在資料庫伺服器上不建議設定為1,從而盡量避免使用swap.
2: 表示不允許超過commitlimit值
預設值為:50 (即50%)
這個引數值只有在vm.overcommit_memory=2的情況下,這個引數才會生效。
vm.min_free_kbytes
cat /proc/sys/vm/min_free_kbytes centos6.4預設66m
該檔案表示強制linux vm最低保留多少空閒記憶體(kbytes)。
當可用記憶體低於這個引數時,系統開始**cache記憶體,以釋放記憶體,直到可用記憶體大於這個值。
vm.vfs_cache_pressure
該項表示核心**用於directory和inode cache記憶體的傾向:
預設值100表示核心將根據pagecache和swapcache,把directory和inode cache保持在乙個合理的百分比
降低該值低於100,將導致核心傾向於保留directory和inode cache
增加該值超過100,將導致核心傾向於**directory和inode cache。
網上文章建議 sysctl -w vm.vfs_cache_pressure=200
其實一般情況下不需要調整,只有在極端場景下才建議進行調整,只有此時,才有必要進行調優,這也是調優的意義所在。
vm.dirty_background_ratio 預設為10
所有全域性系統程序的髒頁數量達到系統總記憶體的多大比例後,就會觸發pdflush/flush/kdmflush等後台回寫程序執行。
將vm.dirty_background_ratio設定為5-10,將vm.dirty_ratio設定為它的兩倍左右,以確保能持續將髒資料重新整理到磁碟,避免瞬間i/o寫,產生嚴重等待(和mysql中的innodb_max_dirty_pages_pct類似)
vm.dirty_ratio 預設為20
單個程序的髒頁數量達到系統總記憶體的多大比例後,就會觸發pdflush/flush/kdmflush等後台回寫程序執行。
vm.panic_on_oom 預設為0開啟 為1時表示關閉此功能
等於0時,表示當記憶體耗盡時,核心會觸發oom killer殺掉最耗記憶體的程序。
當oom killer被啟動時,通過觀察程序自動計算得出各當前程序的得分 /proc//oom_score,分值越高越容易被kill掉。
而且計算分值時主要參照 /proc//oom_adj , oom_adj 取值範圍從-17到15,當等於-17時表示在任何時候此程序都不會被 oom killer kill掉(適用於mysql)。
/proc/[pid]/oom_adj ,該pid程序被oom killer殺掉的權重,介於 [-17,15]之間,越高的權重,意味著更可能被oom killer選中,-17表示禁止被kill掉。
/proc/[pid]/oom_score,當前該pid程序的被kill的分數,越高的分數意味著越可能被kill,這個數值是根據oom_adj運算後的結果,是oom_killer的主要參考。
sysctl 下有2個可配置選項:
vm.panic_on_oom = 0 #記憶體不夠時核心是否直接panic
vm.oom_kill_allocating_task = 1 #oom-killer是否選擇當前正在申請記憶體的程序進行kill
Nginx核心引數相關的優化設定
nginx核心引數乙個長時間困擾著網管員的問題,在實際的操作中各種小技巧還是需要我們引起注意。下面我們就詳細的看看如何進行。nginx核心引數在使用的時候有不少問題需要我們解決,其中在優化方面就需要我們格外的注意。在下面就是對nginx核心引數優化的詳細介紹,希望大家有所收穫。關於nginx核心引數...
核心引數優化
核心引數優化 vi sysctl.conf 增加以下配置 net.ipv4.netfilter.ip conntrack tcp timeout established 1800 net.ipv4.ip conntrack max 16777216 如果使用預設引數,容易出現網路丟包 net.ipv...
NGINX核心引數優化
核心引數的優化,主要是在linux系統中針對nginx應用而進行的系統核心引數的優化。下面給出的乙個優化例項以供參考。net.ipv4.tcp max tw buckets 6000 net.ipv4.ip local port range 1024 65000 net.ipv4.tcp tw re...