Linux低内存处理机制：解决内存不足问题的实例分析

想象一下，你的 Linux 系统就像是一个繁忙的工厂，内存是这个工厂里的仓库空间。当订单（运行的程序和进程）越来越多，仓库空间（内存）开始不够用了，这可怎么办呢？别担心，Linux 有着神奇的低内存处理机制，就像一套高效的库存管理策略。今天，我们就来深入解析一下 Linux 的三个低内存处理机制，看看它们是如何让系统在内存紧张的情况下依然稳定运行的。

一、概述

在 Linux 系统中，内存紧张是一个常见的挑战。当内存不足时，系统的性能可能会受到严重影响。应用程序可能会变得缓慢，甚至可能会崩溃。此外，内存不足还可能导致系统的稳定性下降，出现各种错误和异常情况。

为了应对内存紧张的挑战，Linux 内核采取了多种机制。其中，最重要的机制包括内存回收、内存规整和 OOM-kill。这些机制的目的是尽可能地释放内存，以满足系统的需求。

内存回收是 Linux 内核处理低内存情况的主要方式之一。当系统内存不足时，内核会尝试回收一些不再使用的内存页。这些内存页可能来自于缓存、缓冲区或者匿名页。内存回收的过程包括将脏页写回磁盘、释放缓存和缓冲区等。

内存规整是另一种处理低内存情况的机制。当内存碎片化严重时，内核会尝试将零散的内存页整理成连续的内存区域，以便更好地利用内存空间。

OOM-kill 是一种最后的手段。当内存紧张到无法通过内存回收和内存规整来解决时，内核会选择一个进程并将其杀死，以释放内存。这个被杀死的进程通常是不太重要的进程，以尽量减少对系统的影响。

二、三大核心处理机制详解

2.1内存回收机制

内存回收是 Linux 内核处理低内存情况的主要方式之一。当新进程申请内存，系统内存不足时，Linux 系统会尝试按照 LRU（Least Recently Used）算法回收缓存。后台进程 kswapd0 会在特定条件下回收缓存。

kswapd0 定义了三个内存阈值，分别是页最小阈值（pages_min）、页低阈值（pages_low）和页高阈值（pages_high），剩余内存用 pages_free 表示。当剩余内存小于页最小阈值时，说明进程可用内存都耗尽了，只有内核才可以分配内存。当剩余内存落在页最小阈值和页低阈值中间时，说明内存压力比较大，此时 kswapd0 会执行内存回收，直到剩余内存大于高阈值为止。当剩余内存落在页低阈值和页高阈值中间时，说明内存有一定压力，但还可以满足新内存请求。当剩余内存大于页高阈值时，说明剩余内存比较多，没有内存压力。

可以通过 /proc/sys/vm/min_free_kbytes 设置 pages_min 指标，pages_low 和 pages_high 则由 pages_min 计算而来；除了 Buffer Cache 之外，内存映射获取的文件映射页可以直接回收，应用程序动态分配的堆内存（匿名页）可以通过 swap 方式交换到硬盘。

Linux 可以通过将内存中的 swap 分区交换到硬盘上，从而减轻内存压力。Swap 把不常访问的内存先写到磁盘中，然后释放这些内存，给其他更需要的进程使用。再次访问这些内存时，重新从磁盘读入内存就可以了。Linux 提供了一个 /proc/sys/vm/swappiness 选项，用来调整使用 Swap 的积极程度，数值越大，越积极使用 Swap，也就是更倾向于回收匿名页；数值越小，越消极使用 Swap，也就是更倾向于回收文件页。

⑴基于 LRU 链表的页面回收

LRU（Least Recently Used）链表是 Linux 内存回收的重要依据。内核为每个内存区域（zone）维护了多个 LRU 链表，其中包括活跃匿名页面链表（active_anon）、非活跃匿名页面链表（inactive_anon）、活跃文件页面链表（active_file）和非活跃文件页面链表（inactive_file）等。内存页面根据其使用情况在这些链表中移动。当页面被访问时，其在链表中的位置会更新，最近使用过的页面会移到活跃链表前端，而长时间未使用的页面则会逐渐移到非活跃链表后端。

当需要回收内存时，系统首先会从非活跃链表中选择页面进行回收。对于文件页面，如果是干净页（未修改）可以直接释放；如果是脏页（已修改），则需要先将数据写回磁盘再释放。对于匿名页面，可能会将其交换到 Swap 分区。

案例一：桌面 Linux 系统内存不足

场景描述：在一个桌面 Linux 系统上，用户同时打开了多个大型应用程序，如视频编辑软件、浏览器（多个标签页且有大量缓存）和办公软件等，系统开始变得卡顿，提示内存不足。

内存回收分析

在这种情况下，LRU 链表机制发挥作用。由于浏览器有大量缓存页面，长时间未访问的缓存页面会从活跃文件页面链表移到非活跃文件页面链表。内核首先会尝试回收这些非活跃文件页面，释放内存。

对于视频编辑软件和办公软件等产生的匿名内存，随着内存紧张，kswapd 会将部分匿名页面交换到 Swap 分区。如果用户继续打开新的应用程序，触发直接内存回收，可能会导致正在运行的应用程序出现短暂的冻结，因为直接内存回收会阻塞内存申请，直到获取足够的内存。此时，系统可能会回收一些活跃页面（如果非活跃页面不足），影响应用程序的性能，但能避免系统崩溃。

⑵kswapd 内存回收线程

kswapd 是内核为每个内存节点创建的专门用于内存回收的后台线程。它会周期性地检查内存的使用情况，并根据内存水位（watermark）来决定是否启动回收操作。内存水位分为高水位（high watermark）、低水位（low watermark）和最低水位（min watermark）。当空闲内存低于低水位时，kswapd 被唤醒开始回收内存，目标是将空闲内存提升到高水位。

kswapd 首先尝试回收非活跃的文件页面和匿名页面。它会遍历内存区域，检查页面的状态和使用频率。对于文件页面，按照上述基于 LRU 的文件页面回收策略进行；对于匿名页面，考虑将其交换到 Swap 分区或直接回收（如果没有被修改且可以释放）。如果回收非活跃页面后仍未满足内存需求，可能会进一步回收活跃页面，但这会对系统性能产生一定影响，因为活跃页面可能很快又会被使用。

案例二：服务器内存压力与回收

场景描述：有一台运行 Linux 的服务器，主要用于处理大量的文件传输和数据存储任务。随着业务的增长，服务器开始出现内存压力，表现为响应速度变慢，新的文件传输任务出现延迟。

内存回收分析

首先，kswapd 线程开始工作。由于服务器处理大量文件，文件缓存占用了较多内存。kswapd 会先从非活跃文件页面链表中回收干净的文件页面，这些页面可以直接释放，释放的内存可用于新的文件传输任务的缓存。

如果内存压力持续增加，kswapd 可能会开始回收非活跃匿名页面，将一些长时间未使用的进程数据交换到 Swap 分区。例如，一些后台运行的监控进程的数据，如果长时间未被访问，可能会被交换出去。

若 kswapd 的回收速度跟不上内存需求，当有新的大型文件传输任务申请内存时，会触发直接内存回收。直接内存回收会强制回收文件缓存中的脏页，将其数据写回磁盘，这可能会导致磁盘 I/O 增加，但能迅速释放内存以满足新任务的需求。

⑶直接内存回收

当系统内存紧张且 kswapd 回收内存的速度无法满足新的内存申请需求时，会触发直接内存回收。例如，当一个大型应用程序突然申请大量内存，而当前空闲内存不足时，内核会在内存分配路径上直接进行内存回收。

直接内存回收的过程与 kswapd 类似，但它是同步操作，会阻塞当前的内存申请进程。它也会遍历内存区域，优先回收非活跃页面，包括文件缓存和匿名内存。对于脏页，会先将数据写回磁盘，对于匿名内存则交换到 Swap 分区或直接释放，直到获取足够的内存来满足申请需求。

⑷Swap 分区的使用

Swap 分区是 Linux 系统的虚拟内存区域。当物理内存不足时，内核可以将内存中的部分数据交换到 Swap 分区，从而释放物理内存供其他进程使用。

当内核决定将一个页面交换到 Swap 分区时，会在内存中标记该页面为已交换，并将其内容写入到 Swap 分区的对应位置。当进程再次访问该页面时，内核发现页面在 Swap 分区，会将其从 Swap 分区读回内存，并重新建立页面映射。

⑸Slab 缓存回收

Slab 分配器用于管理小块内存。它预先分配一定数量的内存块，并将这些内存块组织成不同的缓存池，供内核和进程使用。每个缓存池针对特定类型的对象进行内存分配。

当内存紧张时，内核会遍历所有注册到 shrinker_list 中的方法来回收 Slab 缓存。例如，对于文件系统相关的缓存，会回收不再使用的 dentry 和 inode 缓存。一些特定的机制（如 Android 的 lowmemorykiller）也会注册相应的方法来选择性地回收 Slab 缓存中的内存。

案例三：嵌入式 Linux 设备内存管理

场景描述：考虑一个嵌入式 Linux 设备，如智能路由器，它的内存资源有限。在设备运行过程中，需要同时处理网络连接、防火墙规则和一些后台服务等功能，当网络流量突然增大时，可能会出现内存紧张的情况。

内存回收分析

由于嵌入式设备对性能和资源的敏感性，内存回收更加关键。在这种情况下，Slab 缓存回收变得重要。例如，网络协议栈相关的缓存（如 sk_buff 缓存）可能会占用较多内存。当内存紧张时，内核会通过 shrinker_list 中的方法回收这些缓存。同时，对于文件系统相关的缓存（如用于存储路由表等信息的缓存），也会根据使用情况进行回收。如果内存仍然不足，可能会使用 Swap 分区（如果有），但由于嵌入式设备的存储性能可能有限，过度使用 Swap 分区可能会导致严重的性能下降，所以内存回收机制需要更加精细地平衡。

2.2内存规整机制

当内存回收无法满足需求时，内存规整机制就会发挥作用。在 Linux 系统中，伙伴系统作为内核最基础的物理页内存分配器，虽然具有高效、实现逻辑简介等优点，但依然无法杜绝碎片问题。外部碎片带来的最大影响就是内存足够，但是却无法满足内存分配需求。

内存规整（Memory Compaction）是 Linux 内核在内存回收不足以满足内存申请需求时采用的一种机制。其目的是将内存中的零散空闲页面整理成连续的大块空闲内存，以满足一些对连续内存有要求的内存分配请求，例如分配大页内存或者为某些特定的硬件设备分配连续的内存缓冲区。内核将不可移动内存和可移动内存归类，在内存碎片问题出现时，尝试进行内存规整，移动可移动的页面，腾出更多连续内存。内存规整的范围通常以 zone 为单位进行规整，并为此封装 compact_zone 接口，作为内存规整核心接口。

内存规整的触发条件

• 内存碎片化严重：当系统经过长时间运行，内存中出现大量小块的空闲页面，且这些空闲页面分散在各个位置，导致无法满足较大内存块的分配请求时，内存规整机制可能会被触发。这种碎片化可能是由于频繁的内存分配和释放操作，尤其是小块内存的操作所引起的。

• 特定内存分配请求无法满足：当有进程或内核模块请求分配一块较大的连续内存，而当前的空闲内存虽然总量足够，但都是零散分布时，内核会考虑启动内存规整来尝试满足这个分配请求。例如，当加载一个需要较大连续内存空间的驱动程序，或者创建一个大的共享内存段时，如果常规的内存分配算法无法找到足够的连续内存，就会触发内存规整。

内存规整的实现过程

页面迁移：内存规整主要通过页面迁移技术来实现。内核会扫描内存中的页面，确定哪些页面可以被移动。对于可移动的页面（通常是匿名页面或某些可重新定位的文件页面），内核会将它们从当前的物理内存位置迁移到其他合适的位置，从而腾出连续的空闲内存空间。

内存区域扫描与选择：内核会对内存区域（zone）进行扫描，重点关注那些空闲页面较多但碎片化严重的区域。在扫描过程中，会评估每个页面的可迁移性和迁移成本。例如，一些正在被频繁访问的页面可能会被暂时跳过，因为迁移它们可能会对系统性能产生较大影响。同时，内核会选择合适的目标位置来接收迁移的页面，这些目标位置通常是空闲页面相对较多且连续的区域。

数据同步与更新：在页面迁移过程中，需要对页面的映射关系进行更新。对于匿名页面，需要更新进程的页表，确保进程仍然能够正确访问到迁移后的页面。对于文件页面，还需要与文件系统进行适当的同步，以保证数据的一致性。此外，内核还需要更新与内存管理相关的各种数据结构，如内存映射表、空闲页面链表等，以反映内存状态的变化。

案例分析：服务器虚拟化环境中的内存规整

场景描述：在一个服务器虚拟化环境中，运行着多个虚拟机。随着虚拟机的创建、销毁和运行过程中的内存动态分配，物理主机的内存逐渐出现碎片化。某一时刻，管理员尝试启动一个新的虚拟机，该虚拟机需要较大的连续内存来加载其操作系统和运行初始的应用程序，但内存分配请求无法通过常规的内存分配机制得到满足。

内存规整过程与分析

内核检测到内存碎片化严重且新的内存分配请求无法满足，于是启动内存规整。首先，内核扫描物理内存中的各个页面，识别出那些属于虚拟机的匿名页面和可移动的文件页面。对于正在运行的虚拟机中的活跃页面，会根据其访问频率和重要性进行评估。一些相对不活跃的页面，例如虚拟机中暂时未使用的内存缓冲区页面，会被标记为可迁移对象。

然后，内核选择合适的目标区域来接收迁移的页面。在这个案例中，可能会选择那些空闲页面较多且相对连续的内存区域，这些区域可能是由于之前虚拟机销毁后留下的空闲空间。在页面迁移过程中，需要更新虚拟机的页表，确保虚拟机操作系统仍然能够正确访问到其内存数据。同时，与虚拟机磁盘镜像相关的文件页面迁移时，还需要与存储系统进行适当的同步。

经过内存规整后，腾出了足够的连续内存，新的虚拟机得以成功启动。然而，在内存规整过程中，由于涉及大量页面的迁移，可能会对正在运行的虚拟机性能产生一定的影响，表现为短暂的 CPU 使用率上升和磁盘 I/O 增加，因为需要更新页表和同步数据。

2.3OOM-kill 机制

当内存极度紧张时，触发 OOM（Out of Memory）主动 kill 掉不太重要进程以释放内存。Linux 内核里有一个 oom_badness () 函数，它会把系统中可以被杀掉的进程扫描一遍，并对每个进程打分，得分最高的进程就会被首先杀掉。进程的得分一般由其占用的物理内存页框数量决定。

OOM killer 机制是 linux 内核在内存不足情况下的一种管理机制，当内核检测到系统物理内存不足时，就会通过 OOM killer 机制 kill 掉一些进程，kill 进程的原则是通过使用一套启发式算法，选出那个分数最高的进程。内核选择 “bad” 进程是通过调用 oom_badness ()，挑选的算法和想法都很简单很朴实：最 bad 的那个进程就是那个最占用内存的进程。

root 权限的进程通常被认为很重要，不应该被轻易杀掉，所以打分的时候可以得到 3% 的优惠，而我们可以在用户空间通过操作每个进程的 oom_adj 内核参数来降低哪些进程被 OOM killer 选中 kill 掉的几率。我们也可以完全关闭 OOM killer，但不推荐用在生产环境下关闭。vm.overcommit_memory 有 0、1、2 三个可选值，分别代表不同的含义，可以通过设置这个参数来调整 OOM killer 的行为。

OOM - kill 的触发条件

内存耗尽且无法满足新的内存请求：当系统可用内存已经非常低，甚至连内核自身的关键内存操作都无法完成，同时又有新的进程请求内存或者当前运行的进程需要更多内存时，OOM - kill 机制就可能被触发。这种情况通常发生在系统长时间运行大量内存密集型应用程序，或者内存泄漏导致内存资源被过度占用的场景下。

内存压力超过特定阈值：内核为每个内存节点设置了 OOM 相关的阈值参数。当内存使用情况超过这些阈值，如系统的空闲内存低于某个危险水平，并且内存压力持续上升时，OOM - kill 机制就会启动。这些阈值的设定是为了在内存紧张到可能威胁系统稳定之前采取行动。

OOM - kill 选择要杀死进程的依据

OOM 评分（oom_score）：每个进程都有一个 OOM 评分，这个评分是内核根据进程的各种属性来计算的，包括进程的内存使用量、优先级、是否是系统关键进程等因素。一般来说，内存使用量越大、优先级越低的进程，其 OOM 评分越高，在 OOM - kill 机制启动时就越有可能被选中作为被杀掉的目标。例如，用户空间的普通应用程序通常比内核关键进程的 OOM 评分高。

进程的内存占用情况：内核会优先考虑杀死那些占用大量内存的非关键进程。对于共享内存的进程，会综合评估它们对共享内存的使用以及对整个系统内存压力的贡献。如果一个进程占用了大量的匿名内存（如堆内存），且对系统的重要性相对较低，那么它在 OOM - kill 过程中被选中的概率就会增加。

进程的优先级和重要性：系统关键进程（如 init 进程、内核线程等）通常具有较低的 OOM 评分，因为它们对系统的正常运行至关重要。而用户启动的普通应用程序，如文本编辑器、音乐播放器等，在系统内存紧张时相对更容易被 OOM - kill 机制选中，除非用户对这些进程设置了特殊的优先级或保护机制。

案例一：服务器上的内存泄漏与 OOM - kill

场景描述：在一台运行 Linux 的服务器上，部署了一个 Web 应用程序。随着时间的推移，服务器管理员发现系统变得越来越慢，最终某些服务出现了故障。经过检查，发现是 Web 应用程序存在内存泄漏问题，导致系统内存被不断占用。

OOM - kill 过程与分析

由于内存泄漏，Web 应用程序持续占用越来越多的内存，使得系统的空闲内存逐渐减少。当内存使用量超过了 OOM 阈值，内核启动了 OOM - kill 机制。

在选择要杀死的进程时，内核会评估各个进程的 OOM 评分。由于 Web 应用程序是用户空间的应用，且其内存占用量巨大且不断增长，它的 OOM 评分会变得很高。相比之下，服务器上的一些系统关键进程（如 SSH 守护进程、系统日志进程等）具有较低的 OOM 评分，因为它们对系统的持续运行至关重要。

最终，OOM - kill 机制可能会选择杀死 Web 应用程序的进程来释放内存。这会导致 Web 服务暂时中断，但同时也避免了整个服务器系统因内存耗尽而崩溃。对于这种情况，管理员需要修复 Web 应用程序的内存泄漏问题，并可能考虑增加服务器的内存资源。

三、机制间的协同与作用

3.1应对不同内存压力的策略组合

当内存压力较小时，系统主要依靠内存回收机制来处理。例如，当内存剩余量处于页低阈值和页高阈值之间时，后台进程 kswapd0 会根据情况回收一些缓存和不常访问的内存页，以满足新的内存请求。此时，内存规整和 OOM-kill 机制通常不会被触发。

当内存压力增大，内存回收机制无法满足需求时，内存规整机制开始发挥作用。比如，当内存碎片化严重，尽管进行了内存回收，但仍无法提供足够连续的内存空间时，系统会启动内存规整，将零散的页面整合起来。在这个阶段，OOM-kill 机制仍然处于待命状态。

当内存极度紧张，无论是内存回收还是内存规整都无法解决问题时，OOM-kill 机制被触发。系统会通过 oom_badness () 函数对可杀死的进程进行扫描打分，选择得分最高的不太重要的进程进行 kill，以释放内存。这种情况下，通常是内存压力已经达到了非常严重的程度，系统为了保持基本的运行不得不采取这种极端措施。

3.2对系统性能的综合影响

这三大机制对系统性能、稳定性及用户体验有着复杂的影响。内存回收机制在一定程度上可以保证系统在内存不足时仍能继续运行，但频繁的内存回收可能会导致系统性能下降，尤其是在回收文件页时可能会产生大量的磁盘 IO，影响系统的响应速度。例如，当内存回收倾向于回收文件页时，如果文件页中有大量脏页，就会导致磁盘 IO 被打满，系统性能受到严重影响。

内存规整机制虽然可以解决内存碎片化问题，提供连续的内存空间，但在进行规整的过程中也会消耗一定的系统资源，可能会导致系统在一段时间内性能下降。不过，一旦规整完成，系统可以更好地利用内存资源，提高整体性能。

OOM-kill 机制虽然是在极端情况下的最后手段，但它的触发也会对用户体验产生较大的影响。被 kill 的进程可能正在进行重要的任务，这会导致数据丢失和应用程序的异常退出。然而，从系统稳定性的角度来看，OOM-kill 机制可以避免整个系统的崩溃，为用户保留了一定的操作空间。

四、优化低内存处理

4.1内存回收优化

①调整内存回收参数

调整 vfs_cache_pressure 参数：这个参数控制内核回收目录项和 inode 缓存的倾向。增大该值（取值范围是 0 - 200，默认值为 100）会使内核更积极地回收文件系统缓存。例如，如果系统经常面临内存紧张且文件缓存占用大量内存，可以适当增大 vfs_cache_pressure 到 150，促使内核更快地回收文件系统相关缓存。

调整 swappiness 参数：swappiness 参数表示系统将内存数据交换到 Swap 分区的倾向程度，取值范围是 0 - 100。增大该值会使系统更倾向于使用 Swap。对于内存较小且有较多不常使用数据的系统，可以将 swappiness 设置为较高值（如 60 - 80），让系统更积极地把内存数据交换出去，释放物理内存。但如果是对性能要求较高的系统，可能需要将其设置为较低值（如 10 - 20），减少因交换数据到 Swap 导致的性能损失。

②优化 kswapd 行为

调整 kswapd 唤醒参数：通过修改内核参数，可以调整 kswapd 被唤醒的时机。例如，可以根据系统的内存总量和使用模式，微调内存水位标记（watermark）参数，使 kswapd 在更合适的内存紧张程度下启动回收。这样可以避免 kswapd 过早或过晚启动，提高内存回收的效率。

设置 kswapd 优先级：对于一些对内存回收及时性要求较高的系统，可以适当提高 kswapd 的优先级。在多任务环境中，这可以确保 kswapd 有足够的 CPU 资源来及时回收内存，减少因内存紧张导致的性能问题。但需要注意不要设置过高，以免影响其他关键进程的运行。

⑶减少不必要的内存占用

优化应用程序缓存策略：对于运行在系统上的应用程序，可以检查和优化其缓存策略。例如，一些数据库应用可以根据系统内存情况动态调整查询缓存的大小。如果系统内存紧张，可以适当减少缓存大小，释放内存。同样，浏览器应用可以设置合适的缓存过期时间，避免缓存过多数据占用大量内存。

关闭不必要的后台服务和守护进程：分析系统中运行的后台服务和守护进程，关闭那些当前不需要的。这些进程可能会占用一定的内存资源，尤其是在低内存情况下，减少它们的运行可以为系统节省宝贵的内存。例如，如果系统不需要打印服务，可以关闭相关的打印守护进程。

4.2内存规整优化

①优化页面迁移策略

设置页面迁移成本阈值：内核在进行内存规整时，会考虑页面迁移的成本。可以通过调整相关参数来设置页面迁移成本的阈值。对于那些迁移成本较高（如涉及大量磁盘 I/O 或复杂数据同步）的页面，可以适当提高阈值，避免不必要的迁移，减少对系统性能的影响。同时，对于迁移成本较低且对内存规整有较大帮助的页面，可以降低阈值，促进其迁移。

确定页面迁移顺序：根据页面的类型和使用频率来确定迁移顺序。例如，对于长时间未使用的匿名页面，可以优先迁移。而对于正在频繁访问的文件页面，可以延迟迁移或者在内存压力更大时再考虑迁移。这样可以在最小化对系统性能影响的同时，提高内存规整的效果。

②合理规划内存分配

使用大页内存（Huge Pages）：对于一些对内存连续需求较大的应用（如数据库系统），可以考虑使用大页内存。大页内存可以减少内存碎片化的可能性，因为它以较大的内存块为单位进行分配。通过配置内核参数启用大页内存，并在应用程序中合理使用，可以提高内存分配的效率，减少内存规整的需求。

避免过度碎片化的内存分配模式：在编写应用程序或配置系统服务时，尽量避免频繁地进行小块内存的分配和释放。这种操作容易导致内存碎片化。可以采用内存池等技术，一次性分配较大的内存块，然后在应用程序内部进行管理和分配，减少内存碎片的产生。

4.3OOM - kill 优化

①调整 OOM 评分参数

自定义进程 OOM 评分调整：对于一些重要的用户进程，可以通过修改内核参数或使用 cgroups 等机制来降低其 OOM 评分。例如，对于一个企业关键应用的进程，可以设置较低的 OOM 评分，使其在内存紧张时更不容易被 OOM - kill 机制选中。相反，对于一些不太重要的后台进程，可以适当提高其 OOM 评分，让它们在必要时优先被牺牲以释放内存。

设置 OOM 评分调整规则：根据系统的运行特点和业务需求，制定 OOM 评分调整规则。例如，可以根据进程的内存使用上限、运行时间、是否有用户交互等因素来动态调整 OOM 评分。这样可以更加灵活地控制 OOM - kill 机制选择要杀死的进程，提高系统在低内存情况下的稳定性和可用性。

②增加内存监控和预警机制

安装内存监控工具：使用工具如 top、free、vmstat 等定期监控系统内存的使用情况。此外，还可以使用更专业的监控工具，如 Nagios、Zabbix 等，设置内存阈值报警。当内存使用接近危险水平时，及时收到通知，以便管理员可以采取措施，如手动释放内存、调整内存相关参数或优化应用程序，避免触发 OOM - kill。

实现内存使用趋势分析：通过分析内存使用的历史数据和趋势，可以预测内存紧张的情况。例如，如果发现内存使用量在一段时间内呈线性增长，且接近 OOM 触发阈值，可以提前采取优化措施，如增加系统内存、优化应用程序内存使用等，防止 OOM - kill 对系统造成不必要的影响。