oom killer（Out of memory: Kill process 解决）

本文目录

• Out of memory: Kill process 解决
• 如何查看进程OOM killer
• 如何分析linux的oom-killer信息
• oom killer
• 如何优雅地使用Linux系统OOM ( Out Of Memory Killer)
• Linux进程突然被杀掉（OOM killer），查看系统日志
• linux oom 内存超过多少会被kill
• linux出现out of memory是什么问题

Out of memory: Kill process 解决

环境：Centos7 现象：Linux测试服务器上部署了很多程序mysql、mongodb、java等等。程序操作mongodb经常进程被杀死的情况，导致业务中断，mongodb 的logs无提示信息。查看系统日志message后，发现对应时间点，系统自动kill掉了mongodb进程，如下 Out of memory: Kill process 5372 (mongod) score 130 or sacrifice child Killed process 5372 (mongod), UID 0, total-vm:2539052kB, anon-rss:2117096kB, file-rss:0kB, shmem-rss:0kB Linux 分配内存策略 Linux内核根据应用程序的要求来分配内存，由于进程实际上并不会将分配的内存全部使用，所以，为了提高性能，内核采用了一种过度分配内存（over-commit-memory）的策略，来间接利用进程的空闲内存，提高内存的使用效率。一般来说，这没问题。但如果大多数进程都耗光自己的内存，就有麻烦了。因此此时，所有应用程序的内存之和大于物理内存。所以，必须杀掉一部分进程，一般来说，是选内存占用最大的进程杀掉。 挑选原理 挑选的过程由linux/mm/oom_kill.c里的 oom_badness() 函数决定，挑选的算法很直接：是那个最占用内存的进程。 /** test 2334 1.6 2.1 623800 4876 ? Ssl 09:52 0:00 /usr/sbin/test 0 当然，也可以完全关闭 OOM killer，但线上生产环境最好不要这么做。 OOM_killer是Linux自我保护的方式，当内存不足时不至于出现太严重问题，有点壮士断腕的意味 在kernel 2.6，内存不足将唤醒oom_killer，挑出/proc/《pid》/oom_score最大者并将之kill掉 为了保护重要进程不被oom-killer掉，我们可以：echo -17 》 /proc/《pid》/oom_adj,-17表示禁用OOM 我们也可以对把整个 系统 的OOM给禁用掉： sysctl -w vm.panic_on_oom=1 （默认为0，表示开启） sysctl -p 值得注意的是，有些时候 free -m 时还有剩余内存，但还是会触发OOM-killer，可能是因为进程占用了特殊内存地址 平时我们应该留意下新进来的进程内存使用量，免得系统重要的业务进程被无辜牵连 可用 top M 查看最消耗内存的进程，但也不是进程一超过就会触发oom_killer 参数/proc/sys/vm/overcommit_memory可以控制进程对内存过量使用的应对策略 当overcommit_memory=0 允许进程轻微过量使用内存，但对于大量过载请求则不允许(默认） 当overcommit_memory=1 永远允许进程overcommit 当overcommit_memory=2 永远禁止overcommit 参考： https://www.cnblogs.com/yanqingxu/p/8316359.html

如何查看进程OOM killer

OOM Killer(Out of Memory Killer) 是当系统内存严重不足时 linux 内核采用的杀掉进程，释放内存的机制。

OOM Killer 通过检查所有正在运行的进程，然后根据自己的算法给每个进程一个 badness 分数，拥有最高 badness 分数的进程将会在内存不足时被杀掉。

它打分的算法如下:

• 某一个进程和它所有的子进程都占用了很多内存的将会打一个高分。

• 为了释放足够的内存来解决这种情况，将杀死最少数量的进程（最好是一个进程）。

• 内核进程和其他较重要的进程会被打成相对较低的分。

上面打分的标准意味着，当 OOM killer 选择杀死的进程时，将选择一个使用大量内存，有很多子进程且不是系统进程的进程。

简单来讲，oom-killer 的原则就是损失最小、收益最大，因此它会让杀死的进程数尽可能小、释放的内存尽可能大。在数据库服务器上，MySQL 被分配的内存一般不会小，因此容易成为 oom-killer 选择的对象。

“既然发生了 OOM，那必然是内存不足，内存不足这个问题产生原因很多。

首先第一个就是 MySQL 自身内存的规划有问题，这就涉及到 mysql 相应的配置参数。

另一个可以想到的原因就是一般部署 MySQL 的服务器，都会部署很多的监控和定时任务脚本，而这些脚本往往缺少必要的内存限制，导致在高峰期的时候占用大量的内存，导致触发 Linux 的 oom-killer 机制，最终 MySQL 无辜躺枪牺牲。”

如何分析linux的oom-killer信息

-HUP是发送HUP信号给进程1234，然后标准输出重定向到killout.txt,标准错误重定向到killerr.txt，2是标准错误的file handler，1是标准输出

oom killer

Linux内核为了提高内存的使用效率采用过度分配内存(over-commit memory)的办法，造成物理内存过度紧张进而触发OOM机制来杀死一些进程回收内存。 该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽会把该进程杀掉。 Linux在内存分配路径上会对内存余量做检查，（1）如果检查到内存不足，则触发OOM机制。（2）OOM首先会对系统所有进程(出init和内核线程等特殊进程)进行打分，并选出最bad的进程；然后杀死该进程。（3）同时会触发内核oom_reaper进行内存收割。（4）同时内核还提供了sysfs接口系统OOM行为，以及进程OOM行为。然后借用一个示例来分析OOM时内存状态。 1. 关于OOM 内核检测到系统内存不足，在内存分配路径上触发 out_of_memory() ，然后调用 select_bad_process() 选择一个’bad’进程 oom_kill_process() 杀掉，判断和选择一个‘bad’进程的过程由 oom_badness() 决定。 Linux下每个进程都有自己的OOM权重，在/proc/《pid》/oom_adj里面，范围是-17到+15，取值越高，越容易被杀掉。 2. OOM触发路径 在内存分配路径上，当内存不足的时候会触发kswapd、或者内存规整，极端情况会触发OOM，来获取更多内存。 在内存回收失败之后，__alloc_pages_may_oom是OOM的入口，但是主要工作在out_of_memory中进行处理。 由于Linux内存都是以页为单位，所以__alloc_pages_nodemask是必经之处。 static inline struct page * __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order,     const struct alloc_context *ac, unsigned long *did_some_progress) {     struct oom_control oc = {---------------------------------------------------------OOM控制参数。         .zonelist = ac-》zonelist,         .nodemask = ac-》nodemask,         .memcg = NULL,         .gfp_mask = gfp_mask,         .order = order,     };     struct page *page;     *did_some_progress = 0;     /*     * Acquire the oom lock.  If that fails, somebody else is     * making progress for us.     */     if (!mutex_trylock(&oom_lock)) {         *did_some_progress = 1;         schedule_timeout_uninterruptible(1);         return NULL;     }     page = get_page_from_freelist(gfp_mask | __GFP_HARDWALL, order,                     ALLOC_WMARK_HIGH|ALLOC_CPUSET, ac);-----------------------------再次使用高水位检查一次，是否需要启动OOM流程。     if (page)         goto out;     if (!(gfp_mask & __GFP_NOFAIL)) {----------------------------------------------__GFP_NOFAIL是不允许内存申请失败的情况，下面都是允许失败的处理。         /* Coredumps can quickly deplete all memory reserves */         if (current-》flags & PF_DUMPCORE)             goto out;         /* The OOM killer will not help higher order allocs */         if (order 》 PAGE_ALLOC_COSTLY_ORDER)---------------------------------------order超过3的申请失败，不会启动OOM回收。             goto out;         /* The OOM killer does not needlessly kill tasks for lowmem */         if (ac-》high_zoneidx 《 ZONE_NORMAL)             goto out;         if (pm_suspended_storage())             goto out;         /* The OOM killer may not free memory on a specific node */         if (gfp_mask & __GFP_THISNODE)             goto out;     }     /* Exhausted what can be done so it’s blamo time */     if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) {-------------经过上面各种情况，任然需要进行OOM处理。调用out_of_memory()。         *did_some_progress = 1;         if (gfp_mask & __GFP_NOFAIL) {             page = get_page_from_freelist(gfp_mask, order,                     ALLOC_NO_WATERMARKS|ALLOC_CPUSET, ac);-------------------------对于__GFP_NOFAIL的分配情况，降低分配条件从ALLOC_WMARK_HIGH|ALLOC_CPUSET降低到ALLOC_NO_WATERMARKS|ALLOC_CPUSET。             /*             * fallback to ignore cpuset restriction if our nodes             * are depleted             */             if (!page)                 page = get_page_from_freelist(gfp_mask, order,                     ALLOC_NO_WATERMARKS, ac);--------------------------------------如果还是分配失败，再次降低分配标准，从ALLOC_NO_WATERMARKS|ALLOC_CPUSET降低到ALLOC_NO_WATERMARKS。真的是为了成功，节操越来越低啊。         }     } out:     mutex_unlock(&oom_lock);     return page; } 4.3 OOM处理：对进程打分以及杀死最高评分进程 out_of_memory函数是OOM机制的核心，他可以分为两部分。一是调挑选最’bad‘的进程，二是杀死它。 bool out_of_memory(struct oom_control *oc) {     unsigned long freed = 0;     enum oom_constraint constraint = CONSTRAINT_NONE;     if (oom_killer_disabled)----------------------------------------------------在freeze_processes会将其置位，即禁止OOM；在thaw_processes会将其清零，即打开OOM。所以，如果在冻结过程，不允许OOM。         return false;     if (!is_memcg_oom(oc)) {         blocking_notifier_call_chain(&oom_notify_list, 0, &freed);         if (freed 》 0)             /* Got some memory back in the last second. */             return true;     }     if (task_will_free_mem(current)) {----------------------------------------如果当前进程正因为各种原因将要退出，或者释放内存，将当前进程作为OOM候选者，然后唤醒OOM reaper去收割进而释放内存。         mark_oom_victim(current);         wake_oom_reaper(current);         return true;---------------------当前进程由于自身原因将要推出，OOM则将其标注为TIF_MEMDIE状态；然后唤醒OOM Reaper去处理。不需要经过下面的打分和杀死流程。     }     if (oc-》gfp_mask && !(oc-》gfp_mask & (__GFP_FS|__GFP_NOFAIL)))-----------如果内存申请掩码包括__GFP_DS或__GFP_NOFAIL，则不进行OOM收割。         return true;     constraint = constrained_alloc(oc);--------------------------------------未定义CONFIG_NUMA返回CONSTRAINT_NONE。     if (constraint != CONSTRAINT_MEMORY_POLICY)         oc-》nodemask = NULL;     check_panic_on_oom(oc, constraint);--------------------------------------检查sysctl_panic_on_oom设置，以及是否由sysrq触发，来决定是否触发panic。     if (!is_memcg_oom(oc) && sysctl_oom_kill_allocating_task &&--------------如果设置了sysctl_oom_kill_allocating_task，那么当内存耗尽时，会把当前申请内存分配的进程杀掉。         current-》mm && !oom_unkillable_task(current, NULL, oc-》nodemask) &&         current-》signal-》oom_score_adj != OOM_SCORE_ADJ_MIN) {         get_task_struct(current);         oc-》chosen = current;         oom_kill_process(oc, "Out of memory (oom_kill_allocating_task)");         return true;     }     select_bad_process(oc);-------------------------------------------------遍历所有进程，进程下的线程，查找合适的候选进程。即得分最高的候选进程。     /* Found nothing?!?! Either we hang forever, or we panic. */     if (!oc-》chosen && !is_sysrq_oom(oc) && !is_memcg_oom(oc)) {------------如果没有合适候选进程，并且OOM不是由sysrq触发的，进入panic。         dump_header(oc, NULL);         panic("Out of memory and no killable processes...\n");     }     if (oc-》chosen && oc-》chosen != (void *)-1UL) {         oom_kill_process(oc, !is_memcg_oom(oc) ? "Out of memory" :                 "Memory cgroup out of memory");----------------------------杀死选中的进程。         schedule_timeout_killable(1);     }     return !!oc-》chosen; }select_bad_process()通过oom_evaluate_task()来评估每个进程的得分，对于进程1、内核线程、得分低的进程直接跳过。 static void select_bad_process(struct oom_control *oc) {     if (is_memcg_oom(oc))         mem_cgroup_scan_tasks(oc-》memcg, oom_evaluate_task, oc);     else {         struct task_struct *p;         rcu_read_lock();         for_each_process(p)----------------------------------------------遍历系统范围内所有进程线程。             if (oom_evaluate_task(p, oc))                 break;         rcu_read_unlock();     }     oc-》chosen_points = oc-》chosen_points * 1000 / oc-》totalpages; } static int oom_evaluate_task(struct task_struct *task, void *arg) {     struct oom_control *oc = arg;     unsigned long points;     if (oom_unkillable_task(task, NULL, oc-》nodemask))-------------------进程1以及内核线程等等不能被kill的线程跳过。         goto next;     if (!is_sysrq_oom(oc) && tsk_is_oom_victim(task)) {         if (test_bit(MMF_OOM_SKIP, &task-》signal-》oom_mm-》flags))             goto next;         goto abort;     }     if (oom_task_origin(task)) {         points = ULONG_MAX;         goto select;     }     points = oom_badness(task, NULL, oc-》nodemask, oc-》totalpages);------对进程task进行打分。     if (!points || points 《 oc-》chosen_points)---------------------------这里保证只取最高分的进程，所以分数最高者被选中。其他情况则直接跳过。         goto next;     /* Prefer thread group leaders for display purposes */     if (points == oc-》chosen_points && thread_group_leader(oc-》chosen))         goto next; select:     if (oc-》chosen)         put_task_struct(oc-》chosen);     get_task_struct(task);     oc-》chosen = task;--------------------------------------------------更新OOM选中的进程和当前最高分。     oc-》chosen_points = points; next:     return 0; abort:     if (oc-》chosen)         put_task_struct(oc-》chosen);     oc-》chosen = (void *)-1UL;     return 1; } 在oom_badness()中计算当前进程的得分，返回选中进程的结构体，以及进程得分ppoints。 oom_badness()是给进程打分的函数，可以说是核心中的核心。最终结果受oom_score_adj和当前进程内存使用量综合影响。 oom_score_adj为OOM_SCORE_ADJ_MIN的进程不参加评选。进程的oom_score_adj值在/proc/xxx/oom_score_adj中。 mm-》flags为MMF_OOM_SKIP的进程不参加评选。 处于vfork()中的进程不参加评选。 进程的得分取决于其消耗的RSS部分内存(文件映射内存MM_FILEPAGES、匿名映射内存MM_ANONPAGES、shmem内存MM_SHMEMPAGES)、匿名交换内存MM_SWAPENTS、PTE页表所占内存、PMD页表所占内存。 具有root权限的进程只取其97%的得分参加评选。 所以进程得分points=process_pages + oom_score_adj*totalpages/1000；如果是root权限的进程points=process_pages*0.97 + oom_score_adj*totalpages/1000。 在oom_score_adj都为0(默认值)的情况下，最终得分跟进程自身消耗的内存有关；消耗的内存越大越容易被Kill。 oom_score_adj每降低1，可以多获得系统内存资源的1/1000使用量。反之，每增加1，则少获得系统内存资源1/1000使用量。 unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg,               const nodemask_t *nodemask, unsigned long totalpages) {     long points;     long adj;     if (oom_unkillable_task(p, memcg, nodemask))-------------------------------如果进程不可被杀，直接跳过。         return 0;     p = find_lock_task_mm(p);------------找到进程p，并使用task_lock()锁上。     if (!p)         return 0;     /*     * Do not even consider tasks which are explicitly marked oom     * unkillable or have been already oom reaped or the are in     * the middle of vfork     */     adj = (long)p-》signal-》oom_score_adj;--------------------------------------获取当前进程的oom_score_adj参数。     if (adj == OOM_SCORE_ADJ_MIN ||             test_bit(MMF_OOM_SKIP, &p-》mm-》flags) ||             in_vfork(p)) {         task_unlock(p);         return 0;--------------------------------------------------------------如果当前进程oom_score_adj为OOM_SCORE_ADJ_MIN的话，就返回0.等于告诉OOM，此进程不参数’bad’评比。     }     /*     * The baseline for the badness score is the proportion of RAM that each     * task’s rss, pagetable and swap space use.     */     points = get_mm_rss(p-》mm) + get_mm_counter(p-》mm, MM_SWAPENTS) +         atomic_long_read(&p-》mm-》nr_ptes) + mm_nr_pmds(p-》mm);-----------------可以看出points综合了内存占用情况，包括RSS部分、swap file或者swap device占用内存、以及页表占用内存。     task_unlock(p);     /*     * Root processes get 3% bonus, just like the __vm_enough_memory()     * implementation used by LSMs.     */     if (has_capability_noaudit(p, CAP_SYS_ADMIN))------------------------------如果是root用户，增加3%的使用特权。         points -= (points * 3) / 100;     /* Normalize to oom_score_adj units */     adj *= totalpages / 1000;--------------------------------------------------这里可以看出oom_score_adj对最终分数的影响，如果oom_score_adj小于0，则最终points就会变小，进程更加不会被选中。     points += adj;-------------------------------------------------------------将归一化后的adj和points求和，作为当前进程的分数。     /*     * Never return 0 for an eligible task regardless of the root bonus and     * oom_score_adj (oom_score_adj can’t be OOM_SCORE_ADJ_MIN here).     */     return points 》 0 ? points : 1; }https://www.cnblogs.com/arnoldlu/p/8567559.html#oom_badness

如何优雅地使用Linux系统OOM ( Out Of Memory Killer)

Linux内核根据服务器上当前运行应用的需要来分配内存。因为这通常是预先发生的，所以应用并不会使用所有分配的内存。这将会导致资源浪费，Linux内核允许超分内存以提高内存使用效率。Linux内核允许超分内存，比如总共8G内存，可以分给10个进程各1G，这通常没问题。但问题发生在太多应用一起占用内存，有8个进程各占了1G，剩下两个进程要喝西北风了。 由于内存不足，服务器有崩溃的风险。The  server runs the risk of crashing because it  ran out of memory。为了防止服务器到达这个临近状态，内核中有一个OOM Killer杀手进程。To prevent the server from reaching  that critical state, the kernel also contains a process known as the OOM Killer。内核利用这个杀手进程开始屠杀那些非必要进程，以便服务器正常运行。The kernel uses this  process to start killing non-essential  processes so the server can remain  operational. 当你认为这一切都不是问题时，因为OOM Killer只杀掉那些非必要的，不是用户需要的进程。举例，两个应用(Apache和MySQL)通常先被杀掉，因为占用大量的内存。但这将导致一个web网站立马瘫痪了。 当尝试找到为什么一个应用程序或进程被OOM killer杀掉时，有很多地方可以找到一个进程如何被杀掉以及被杀掉的原因。 $ grep -i kill /var/log/messages* host kernel: Out of Memory: Killed process 5123 (exampleprocess) The capital K in Killed tells you that the process was killed with a -9 signal, and this typically is a good indicator that the OOM Killer is to blame. $ free -lhThe -l switch shows high and low memory  statistics, and the -h switch puts the output  into gigabytes for easier human readability. You can change this to the -m switch if you  prefer the output in megabytes. 同时该命令会给出Swap内存使用信息。注意：free命令给出某个时刻得数据，需要多执行几次才能知道内存动态的占用情况。$ vmstat -SM 10 20 20次，每次间隔10秒给出内存使用情况。 top 默认输出CPU的使用情况，不过你可以在top后再按下shift + M，你将得到内存的使用情况。配置文件/etc/sysctl.conf： sysctl vm.panic_on_oom=1 sysctl kernel.panic=X echo “vm.panic_on_oom=1” 》》 /etc/sysctl.conf echo “kernel.panic=X” 》》 /etc/sysctl.conf 大多数情况下，内存不足时每次都重启是不合适的。 既可以保护一些重要进程不被OMM killer杀掉，又可以让不重要的进程更容易杀掉: echo -15 》 /proc/(PID)/oom_adj (不被杀) echo 10 》 /proc/(PID)/oom_adj (更易杀) pstree -p | grep "process" | head -1 在某些情况下，豁免进程可能导致意外的行为变化，取决于系统和资源配置。假如内核无法杀死一个占用大量内存的进程，将杀死其他进程，包括那些重要的操作系统进程。 由于OOM killer可调节的有效范围在-16到+15之间，设置为-17将豁免一个进程，因为在OOM killer调节范围之外。通常的规则是这个参数越大越容易被杀死豁免一个进程的命令是 echo -17 》 /proc/(PID)/oom_adj 警告：不建议用于生产环境。 假如重启，修改进程优先级，豁免一个进程不足够好，有个风险的选项：将oom killer 功能关闭。 这一选项参数将有如下影响： 4.1) 严重的内核恐慌kernel panic 4.2) 系统挂住system hang-up 4.3) 一个完整的系统崩溃system crash 为什么关闭有风险呢呢？该功能避免自己因资源而跑飞了。如果你关闭此功能，将不能避免内存耗尽。考虑此项时请极度慎重。 sysctl vm.overcommit_memory=2 echo “vm.overcommit_memory=2” 》》 /etc/sysctl.conf

Linux进程突然被杀掉（OOM killer），查看系统日志

一个命令： 这个命令需要用户处于root权限才能看，执行之后可以看到： 简单说一下： total-vm就是进程使用的虚拟内存大小，其中部分内容映射到RAM本身，也就是主存，被分配和使用也就成了RSS。 部分RSS在实际内存块里面分配，成了anon-rss，叫做匿名内存。还有映射到设备和文件的RSS内存卡，叫做file-rss。 比如说： 你用vim指令打开一个巨大的文件，那么file-rss将会很高。 如果你用malloc()动态分配很大部分的内存，并且真的使用了它，那么anon-rss也会很高。 但是！！如果你使用malloc()分配了大量的内存，但是不去用它！那么total-vm将会变得更高，但是因为内存过量使用，不会使用真正的内存，那么rss值会很低。 可以看到上述信息，发现进程被杀掉了。 那么杀掉它的原因是什么呢？ 首先确定，当报出OOM的时候，系统的内存已经不足了，于是linux会决定杀掉进程，但是linux采用的策略并非是杀掉最占用内存的进程(Android是这样)。 linux会给每个进程评分：oom_score 根据这个评分去kill，决定这个分数的因素除了内存占用大小之外，还有内存增加的速率，比如说kylin，当执行Task构建Cube的时候，内存的占用会突然爆发式增长！发现这时候的分数老高了！然后就把它kill了。 https://stackoverflow.com/questions/18845857/what-does-anon-rss-and-total-vm-mean

linux oom 内存超过多少会被kill

OOM_killer是Linux自我保护的方式，当内存不足时不至于出现太严重问题，有点壮士断腕的意味在kernel 2.6，内存不足将唤醒oom_killer，挑出/proc/《pid》/oom_score最大者并将之kill掉 为了保护重要进程不被oom-killer掉，我们可以：echo -17 》 /proc/《pid》/oom_adj,-17表示禁用OOM我们也可以对把整个系统的OOM给禁用掉：sysctl -w vm.panic_on_oom=1 （默认为0，表示开启）sysctl -p 值得注意的是，有些时候 free -m 时还有剩余内存，但还是会触发OOM-killer，可能是因为进程占用了特殊内存地址 平时我们应该留意下新进来的进程内存使用量，免得系统重要的业务进程被无辜牵连可用 top M 查看最消耗内存的进程，但也不是进程一超过就会触发oom_killer参数/proc/sys/vm/overcommit_memory可以控制进程对内存过量使用的应对策略当overcommit_memory=0 允许进程轻微过量使用内存，但对于大量过载请求则不允许(默认）当overcommit_memory=1 永远允许进程overcommit当overcommit_memory=2 永远禁止overcommitref:http://www.2cto.com/os/201309/247081.html

linux出现out of memory是什么问题

有两种方法可以解决这个问题1、如果可能，请升级到64位系统。这是最好的解决办法，因为所有的内存都将成为low memory。如果你在这种情况下耗尽了low memory，那就真的是out of memory了。2、如果受限于必须使用32位系统，最好的解决办法是使用hugemem内核。这种内核以不同的方式分割low/high memory，而且在大多数情况下会提供足够多的low memory到high memory的映射。在大多数案例中，这是一个很简单的修复方法：安装hugemem kernel RPM包，然后重启即可。如果运行hugemem内核也不可能，你可以尝试将/proc/sys/vm/lower_zone_protection 的值设置为250甚至更多。这将让内核愿意保护low memory，从而在分配内存时多考虑从high memory分配。据我所知，此选项从2.6.x内核才开始可用。必要的是，您可能需要通过一些实验来找到您系统环境中最适合的值。可以使用下面方法快速的设置和检查改值： # cat /proc/sys/vm/lower_zone_protection # echo "250" 》 /proc/sys/vm/lower_zone_protection 在 /etc/sysctl.conf 中加入设置，以便启动就生效：vm.lower_zone_protection = 250作为最后的努力，你可以关闭oom-killer。这个选项可以导致系统挂起，所以请小心使用（风险自负）！查看当前oom-killer的状态： # cat /proc/sys/vm/oom-kill 关闭/打开oom-killer： # echo "0" 》 /proc/sys/vm/oom-kill # echo "1" 》 /proc/sys/vm/oom-kill 当进程该被oom-killer杀死却没有被杀死时，相关信息会记录到 /var/log/messages:"Would have oom-killed but /proc/sys/vm/oom-kill is disabled"