如何防止 ES 被 Linux OOM Killer 杀掉

当 Linux 系统内存不足时，内核会找出一个进程 kill 掉它释放内存，旨在保障整个系统不至于崩溃。如果 ES 按照最佳实践去实施部署，会保留一半的内存，不至于发生此类事情。但事情总有例外，有的朋友可能 ES 和其他的程序部署在一起，当主机内存不足时，那么 ES 很有可能会被内核 Kill 掉。

关于 OOM Killer

Linux 内核根据系统上运行的应用程序需求分配内存。由于许多应用程序预先分配内存，并且通常不使用分配的内存，因此内核设计为能够超额使用内存以提高内存使用效率。这种超额提交模型允许内核分配的内存多于其实际可用的内存。如果进程实际使用了分配给它的内存，则内核会将这些资源提供给应用程序。当太多应用程序开始使用它们分配的内存时，超额提交模型有时会出现问题，内核必须开始终止进程才能保持系统运行。内核用于恢复系统内存的机制称为内存不足终止程序或简称 OOM Killer。

找出进程被 Kill 的原因

在对应用程序被 OOM Killer 终止的问题进行故障排除时，有几条线索可能会表明进程被终止的方式和原因。在以下示例中，我们将查看操作系统的日志，看看是否可以找到问题的根源。由于内存不足的情况，Elasticsearch 进程被 OOM Killer 程序终止。Killed 中的大写 K 表示该进程被 -9 信号终止，这通常是一个兆头，表明 OOM Killer 可能是罪魁祸首。

grep -i kill /var/log/messages*
host kernel: Out of Memory: Killed process 2592 (elasticsearch).

OOM Killer 选择机制

OOM Killer 是 Linux 系统中用于内存管理的一个重要机制。当系统内存不足时，OOM Killer 会遍历所有进程，综合考虑进程占用的内存和配置的 oom_score_adj 值来计算每个进程的 oom_score，最终选择得分最高的进程进行终止。如果多个进程得分相同，则优先终止最先被扫描到的进程。
你可以通过查看 /proc/[pid]/oom_score 文件来获取每个进程的 oom_score 值，该值会根据进程内存使用情况的变化而实时更新。当前得分最高的进程将在下一次 OOM 事件中被优先终止。

如果你希望某个进程在内存不足时避免被优先终止，可以通过调整该进程的 oom_score_adj 值来降低其 oom_score。

oom_adj 是一个旧的接口参数，其功能类似 oom_score_adj ，为了兼容，目前仍然保留这个参数，当操作这个参数的时候，kernel 实际上是会换算成 oom_score_adj 。

配置进程 oom_score_adj

通过上面的讲解可知，我们可以通过配置进程的 oom_score_adj 或 oom_adj 来避免其在系统内存不足时被终止的风险。

如果我们想降低 PID 为 2592 进程被 OOM Killer 终止的可能性，我们可以执行以下操作：

# 新接口
echo -500 > /proc/2592/oom_score_adj# 老接口
echo -15 > /proc/2592/oom_adj 

如果我们想提高 PID 为 2592 进程被 OOM Killer 终止的可能性，我们可以执行以下操作：

# 新接口
echo 500 > /proc/2592/oom_score_adj# 老接口
echo 10 > /proc/2592/oom_adj

如果你希望某个关键进程绝对不能被终止，可以执行以下操作：

# 新接口
echo -1000 > /proc/2592/oom_score_adj# 老接口
echo -17 > /proc/2592/oom_adj

希望对多程序混合部署的小伙伴有所帮助。