今天安裝greenplus數據庫，需要調試一個核心文件/etc/sysctl.conf文件，結果導致系統異常宕機，出現的問題就是使用任何命令都不能輸出正確的結果，只有這個顯示：
不知道是什么原因，ls命令都不能使用。后來就去網上找一些答案：
而messages日志中，也沒有OOM相關的記錄。最后確認原因為：/proc/sys/vm/overcommit_memory參數導致。 該環境中該參數設置為2，表示“No overcommit”，即系統中所有進程占用的虛擬內存空間不能超過上限： cat /proc/meminfo CommitLimit: 12061860 kB //虛擬地址空間的上限 Committed_AS: 8625360 kB //當前的使用量 而該參數應該默認是0，這種情況下，只有還有空閑的物理內存，就可以繼續分配，不受虛擬地址空間的限制。 echo 0 > /proc/sys/vm/overcommit_memory 如此修正后解決。
2、關於overcommit_memory說明： 取值為0，系統在為應用進程分配虛擬地址空間時，會判斷當前申請的虛擬地址空間大小是否超過剩余內存大小，如果超過，則虛擬地址空間分配失敗。因此，也就是如果進程本身占用的虛擬地址空間比較大或者剩余內存比較小時，fork、malloc等調用可能會失敗。 取值為1，系統在為應用進程分配虛擬地址空間時，完全不進行限制，這種情況下，避免了fork可能產生的失敗，但由於malloc是先分配虛擬地址空間，而后通過異常陷入內核分配真正的物理內存，在內存不足的情況下，這相當於完全屏蔽了應用進程對系統內存狀態的感知，即malloc總是能成功，一旦內存不足，會引起系統OOM殺進程，應用程序對於這種后果是無法預測的 取值為2，則是根據系統內存狀態確定了虛擬地址空間的上限，由於很多情況下，進程的虛擬地址空間占用遠大小其實際占用的物理內存，這樣一旦內存使用量上去以后，對於一些動態產生的進程(需要復制父進程地址空間)則很容易創建失敗，如果業務過程沒有過多的這種動態申請內存或者創建子進程，則影響不大，否則會產生比較大的影響
最后終於解決了