测验：内存与 OOM

容器终止，退出代码为 137。为什么我们不应该立即得出 OOM 的结论呢？

• 137 表示配置错误。
• 因为137正好意味着128+9，也就是用SIGKILL死了。
• 因为 OOM 总是留下退出代码 1。
• 因为容器无法信任退出代码

OOM Killer 在选择进程时以什么值作为标准？

• RSS（真实驻留内存）和 oom_score_adj 额外分数的总和
• 虚拟地址空间的大小被视为 VIRT
• 进程存活的总时间
• 进程的累积 CPU 利用率

free -m 的空闲列只有200MB。这是一个问题吗？

• 这是一个危险信号，您需要立即增加记忆力。
• 这意味着交换已关闭
• 这意味着正在进行内存泄漏。
• 这可能是正常的。使用可用列进行判断

为什么我需要检查 dmesg 的 oom-kill 行中的约束？

• 这是因为根据是全局 OOM 还是 cgroup OOM，响应完全不同。
• 您可以找出哪个进程死亡的名称。
• 可以看到已安装的内存总量
• 能够预测下次复发的时间

当我通过添加 RSS 来计算具有 20 个工作线程的 Web 服务器的内存使用量时，它比实际值要大得多。原因和替代方案是什么？

• RSS 包含 swap，因此必须省略 swap。
• 应排除 RSS，因为它包含内核内存。
• 这是由于测量时间不同而产生的误差。
• 这是因为每个进程的所有共享库页面都会被计数。使用PSS

在cgroup的memory.events中，只有max counter很大并且oom_kill为0。你的情况是什么？

• 该进程已经因达到限制而死亡数次。
• 没有设置限制
• 我不断地达到自己的极限并逐渐恢复，但我还没有死。
• 内存还够用