在工作過程中，你可能會遇到過這種情況，程式在執行一段時間之後突然掛掉，在你保證程式在正常情況下不會掛掉的情況下，程式掛掉的原因可能是在你的程式執行過程中，有一段時間你的程式執行記憶體過大，而此時系統物理記憶體不足，導致系統觸發oom killer機制，將該程序kill。oom killer是out-of-memory killer的縮寫，它是機liux核心的一種記憶體管理機制。在linux系統記憶體將要用完的情況下，oom-killer程序會遍歷當前機器上的所有程序，按照**程序所佔記憶體的大小和使用者打分(oom_score_adj)**對程序進行打分（占用記憶體越大，分數越高），然後挑選出分數最高的程序將其kill掉。
乙個程序的oom-killer打分分別由系統得分和使用者打分綜合評判，它的具體策略是系統打分+使用者打分為當前程序的最後分數。對於linux中執行的每乙個程序，都會有兩個檔案分別為/proc//oom_score和/proc//oom_score_adj來儲存系統打分和使用者打分。
所以我們可以通過linux中程序執行過程中儲存的oom_score和oom_score_adj檔案，來找到最先被系統oom-kill的程序。可使用下面指令碼來搜尋優先被oom_kill的程序
dir=`ls
-l /proc |awk '/^d/ '`
result_process=0
result_score=0
for i in $dir
do oom_score=0
oom_score_adj=0
if[-f "/proc/$i/oom_score"
] then
oom_score=`cat
/proc/
$i/oom_score`
fi if
[-f "/proc/$i/oom_score_adj"
] then
oom_score_adj=`cat
/proc/
$i/oom_score_adj`
fi process_score=`expr $oom_score
+$oom_score_adj`
if[$i!= "1"
] && [
$process_score
-gt$result_score
] then
result_score=$process_score
result_process=$i
fidone
echo
$result_process
,$result_score
1、手從修改程序oom_score_adj的值為-1000避免該程序被kill。
2、禁止的oom kill機制，當系統發生 oom 的時候開啟 kernel panic，此時系統會發生重啟。
# 修改sysctl.conf檔案
echo "vm.panic_on_oom=1" >> /etc/sysctl.conf
# 使配置生效
systcl -p
sphinx rotate機制詳解
今日，發現sphinx出現 sphinx.new.sp 諸多檔案。出現這樣的情況是因為 searchd沒有載入新索引檔案。遂google之，到sphinx官網論壇後得知rotate的機制後方解決！sphinx的searchd在啟動時會建立乙個 spl 鎖檔案，並在關閉時會刪除它。在indexer建立...
Cookie Session機制詳解
cookie通過在客戶端記錄資訊確定使用者身份，session通過在伺服器端記錄資訊確定使用者身份。cookie機制 理論上，乙個使用者的所有請求操作都應該屬於同乙個會話，而另乙個使用者的請求操作則應該屬於另乙個會話。而web應用程式是使用http協議傳輸資料的。http協議是無狀態的協議，一旦資料...
android binder機制詳解
1.直觀來說，binder是android中的乙個類，它繼承了ibinder介面 2.從ipc角度來說，binder是android中的一種跨程序通訊方式，binder還可以理解為一種虛擬的物理裝置，它的裝置驅動是 dev binder，該通訊方式在linux中沒有 3.從android frame...