当 Memory Cgroup 报告 OOM 时，节点进程被终止，当在具有高 RAM 和 CPU 内核的实例上运行时，但适用于小型实例

Question

在Gitlab Runner 的K8s pod 中将作业作为管道运行时，只有在像m5*.large这样提供 2 个vCPUs和8GB RAM 的小型实例上运行时，作业才能成功完成。 我们为下面提到的build 、 helper和services容器设置了限制。 尽管如此，该作业仍因Out Of Memory (OOM)错误而失败，当在更强大的实例上运行时进程node被cgroup杀死，例如提供 8 vCPUs和32GB RAM的m5d*.2xlarge 。

请注意，我们试图将大量资源分配给容器，尤其是节点进程是其子进程的build容器，并且在强大的实例上运行时没有任何变化； 由于OOM ，节点进程仍然被杀死，每次我们给它更多 memory，节点进程消耗更高的 memory 等等。

此外，关于 CPU 使用率，在强大的实例中，我们给它的 vCPU 越多，消耗的越多，我们注意到它的 CPU 节流几乎一直都在 ~100%，但是，在像m5*.large这样的小实例中, CPU 节流没有超过 3%。

请注意，我们指定了node进程使用的最大值 memory，但看起来它没有任何效果。 我们尝试将其设置为 1GB、1.5GB 和 3GB。

NODE_OPTIONS: "--max-old-space-size=1536"

节点版本

v16.19.0

平台

amzn2.x86_64

---

作业运行主机的日志

"message": "oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=....
....
"message": "Memory cgroup out of memory: Killed process 16828 (node) total-vm:1667604kB

---

资源请求/限制配置

memory_request = "1Gi"
memory_limit = "4Gi"
service_cpu_request = "100m"
service_cpu_limit = "500m"
service_memory_request = "250Mi"
service_memory_limit = "2Gi"
helper_cpu_request = "100m"
helper_cpu_limit = "250m"
helper_memory_request = "250Mi"
helper_memory_limit = "1Gi"

---

在 m5d.large 上成功运行的作业的资源消耗

---

在 m5d.2xlarge 上运行的失败作业的资源消耗

Answer 1

当容器中的进程尝试消耗超过 memory 的允许数量时，系统 kernel 终止尝试分配的进程，并出现 memory (OOM) 错误。

检查您是否在您的容器中启用了持久性日志记录？

一种方法： mkdir /var/log/journal && systemctl restart systemd-journald

其他方式： in ystemd/man/journald.conf.html

如果不是，并且您的容器使用 systemd，它将记录到 memory，其限制来自主机 RAM，这可能导致意外的 OOM 情况。

此外，如果可能，您可以增加 RAM 的数量（clamav 确实使用了很多）。

如果节点在 kubelet 能够回收 memory 之前遇到 out of memory (OOM) 事件，则该节点依赖于oom_killer来响应。

memory 行为中的节点在Kube.netes 最佳实践：资源请求和限制中有详细描述。 调整容器中的 memory 请求（最小阈值）和 memory 限制（最大阈值） 。

Pod 崩溃和 OS Syslog 显示 OOM 杀手杀死容器进程、 Pod memory 限制和 cgroup memory 设置。 Kube.netes 使用 cgroup 和 OOM killer 管理 Pod memory 限制。 我们需要小心区分 OS OOM 和 Pod OOM。

尝试使用--oom-score-adj选项来docker run甚至--oom-kill-disable 。 有关详细信息，请参阅资源的运行时约束。

另请参阅类似的SO以获取更多相关信息。