cgroup內存限制
memory.failcnt
memory.limit_in_bytes
memory.usage_in_bytes
memory.max_usage_in_bytes
memory.memsw.failcnt
memory.memsw.limit_in_bytes
memory.memsw.max_usage_in_bytes
memory.memsw.usage_in_bytes
memory.soft_limit_in_bytes
memory.oom_control
memory.use_hierarchy
memory.swappiness
memory.stat
帶 memsw 的表示虛擬內存，不帶 memsw 的僅包括物理內存。其中，limit_in_bytes 是用來限制內存使用的，其他的則是統計報告。
memory.memsw.limit_in_bytes：內存＋swap空間使用的總量限制。
memory.limit_in_bytes：內存使用量限制。
memory.memsw.limit_in_bytes 必須大於或等於 memory.limit_in_byte。
要解除內存限制，把對應的值設為 -1 即可。
這種方式限制進程內存占用會有個風險。當進程試圖占用的內存超過限制時，會觸發 oom ，導致進程直接被殺，從而造成可用性問題。即使關閉控制組的 oom killer，在內存不足時，進程雖然不會被殺，但是會長時間進入 D 狀態（等待系統調用的不可中斷休眠），並被放到 OOM-waitqueue 等待隊列中， 仍然導致服務不可用。因此，用 memory.limit_in_bytes 或 memory.memsw.limit_in_bytes 限制進程內存占用僅應當作為一個保險，避免在進程異常時耗盡系統資源。如，預期一組進程最多會消耗 1G 內存，那么可以設置為 1.5G 。這樣在發生內存泄露等異常情況時，可以避免造成更嚴重問題。
memory.oom_control：內存超限之后的 oom 行為控制。
關閉oom killer：
設置 oom_kill_disable 為 1。（0 為開啟）
oom-killer機制分析
這里我們說一下一個常見的誤區，就是有人會認為觸發了oom-killer的進程就是問題的罪魁禍首，比如我們這個例子中的這個nginx進程。其實日志中invoke oom-killer的這個進程有時候可能只是一個受害者，因為其他應用／進程已將系統內存用盡，而這個invoke oomkiller的進程恰好在此時發起了一個分配內存的請求而已。在系統內存已經不足的情況下，任何一個內存請求都可能觸發oom killer的啟動。