我们在K8s的pod上遇到了OOMKilled事件。我们希望在这种情况下,在pod被驱逐之前运行本地内存分析命令。是否可以添加这样的钩子?更具体地说:我们使用-XX:NativeMemoryTracking=summary JVM标志运行。我们想在pod逐出之前运行jcmd <pid> VM.native_memory summary.diff,看看是什么导致了OOM。
-XX:NativeMemoryTracking=summary
jcmd <pid> VM.native_memory summary.diff
ssgvzors1#
看起来几乎不可能处理。基于answer on Github关于OMM Kill上的优雅停止:当前无法更改OOM行为。每当容器接近其内存限制时,Kubernetes(或运行时)可以向您的容器提供信号。这将是尽最大努力的基础,因为内存峰值可能无法及时处理。以下是官方文档:如果节点在kubelet能够回收内存之前发生了系统OOM(内存不足)事件,则节点依赖于oom_killer来响应。kubelet根据Pod的服务质量为每个容器设置一个oom_score_adj值。所以,正如你所理解的,你没有太多的机会来处理它。这里是关于OOM处理的大article,我将在这里只取一小部分,关于内存控制器的内存处理:不幸的是,这个进程可能没有太多其他的方法来响应OOM情况。如果它已经用mlock()或mlockall()将其文本锁定到内存中,或者它已经驻留在内存中,那么它现在就知道内存控制器内存不足了。但是,它不能做任何其他事情,因为大多数感兴趣的操作都需要分配更多的内存。我唯一能提供的是从cAdvisor(这里你可以得到一个OOM Killer事件)或从Kubernetes API获取数据,当你看到指标非常接近内存不足时运行你的命令。我不确定你会有时间在你得到OOM Killer事件后做些什么。
4nkexdtk2#
以下是我们用来分析K8S中的Pod OOMKilled的一些步骤。
container_memory_working_set_bytes
container_memory_max_usage_bytes
journalctl
sudo journalctl --utc -ke
-ke
memory: usage 4194304kB, limit 4194304kB, failcnt 1239 memory+swap: usage 4194304kB, limit 9007199254740988kB, failcnt 0 kmem: usage 13608kB, limit 9007199254740988kB, failcnt 0 Memory cgroup stats for /kubepods.slice/kubepods-burstable.slice/kubepods-burst...
/sys/fs/cgroup/memory/kubepods.slice/kubepods-burstable.slice
preStop
lifecycle: preStop: exec: command: - sh - -c - "jmap -dump:live,format=b,file=/folder/dump_file 1"
2条答案
按热度按时间ssgvzors1#
看起来几乎不可能处理。
基于answer on Github关于OMM Kill上的优雅停止:
当前无法更改OOM行为。每当容器接近其内存限制时,Kubernetes(或运行时)可以向您的容器提供信号。这将是尽最大努力的基础,因为内存峰值可能无法及时处理。
以下是官方文档:
如果节点在kubelet能够回收内存之前发生了系统OOM(内存不足)事件,则节点依赖于oom_killer来响应。kubelet根据Pod的服务质量为每个容器设置一个oom_score_adj值。
所以,正如你所理解的,你没有太多的机会来处理它。这里是关于OOM处理的大article,我将在这里只取一小部分,关于内存控制器的内存处理:
不幸的是,这个进程可能没有太多其他的方法来响应OOM情况。如果它已经用mlock()或mlockall()将其文本锁定到内存中,或者它已经驻留在内存中,那么它现在就知道内存控制器内存不足了。但是,它不能做任何其他事情,因为大多数感兴趣的操作都需要分配更多的内存。
我唯一能提供的是从cAdvisor(这里你可以得到一个OOM Killer事件)或从Kubernetes API获取数据,当你看到指标非常接近内存不足时运行你的命令。我不确定你会有时间在你得到OOM Killer事件后做些什么。
4nkexdtk2#
以下是我们用来分析K8S中的Pod OOMKilled的一些步骤。
container_memory_working_set_bytes
指标来监控内存使用情况,还使用container_memory_max_usage_bytes
指标。journalctl
。-ke
只显示内核消息并跳转到日志的末尾。/sys/fs/cgroup/memory/kubepods.slice/kubepods-burstable.slice
下的文件以查找内存分配信息。preStop
中添加一个钩子来转储pod的内存,可以根据转储文件进行进一步的调查。