☰

ubuntu 能否因为内存不足而终止进程以及如何知道

tag-icon • tag-icon process memory-usage kill
ubuntu 能否因为内存不足而终止进程以及如何知道

一切都在标题中。我正在运行一个play framework和一个redis进程ubuntu 2GB RAM VPS，但昨晚这两个进程突然崩溃，没有任何日志（这很奇怪，因为他们总是因为崩溃而写入日志）。

因此，我想知道Ubuntu这些崩溃是否可能是由什么原因造成的？内存非常低。可以Ubuntu终止这些进程以释放内存吗？

如果是，是否有任何日志可供我阅读，以检查具体Ubuntu发生了什么、为什么以及何时发生？此外，有没有办法禁用这些“自动终止”或指示ubuntu终止其他进程但不终止这两个进程？

答案1

这不是 Ubuntu 所做的，而是 Linux 内核所做的。维基百科有一个关于此的主题：

内存不足 (OOM) 是计算机运行中经常出现的一种不良状态，即无法为程序或操作系统分配额外内存。这种情况下，系统将无法加载任何额外程序，而且由于许多程序在执行过程中可能会将额外数据加载到内存中，因此这些程序将无法正常运行。出现这种情况的原因是所有可用内存（包括磁盘交换空间）都已分配。

一般来说，/var/log/syslog（基于 debian 的系统）或 中应该会有通知/var/log/messages。grep "Killed process" /var/log/syslog应该显示系统是否终止了某个进程。

有趣的话题：“如何发现是什么终止了一个进程？”在堆栈上和这篇文章lwn.net。

项目页面对象对象模型有很多小贴士：

什么原因导致了这些 OOM 事件？

  • 内核确实内存不足。工作负载使用的内存比系统的 RAM 和交换空间多。/proc/meminfo 中的 SwapFree 和 MemFree 是什么？如果两者都很低（不到其总量的 1%），则可能是工作负载出了问题。（除非涉及 mlock() 或 HugeTLB，见下文...）

  • 在 32 位架构上，内核内存不足。/proc/meminfo 中的 LowFree 是什么？如果它非常低，但 HighFree 高得多，则说明存在这种情况。此工作负载可能适合在 64 位平台或内核上运行。

  • 存在内核数据结构或内存泄漏。/proc/meminfo 中的 SwapFree 和 MemFree 是什么？slabinfo 中的 task_struct 对象数量是多少？系统是否分叉了太多进程，导致内存不足？/proc/slabinfo 中的哪些对象占用了最多的空间？如果一种对象占用了系统总内存的很大一部分，则该对象可能是罪魁祸首。请咨询子系统专家，了解该对象的来源区域。要查看对象使用情况，请在命令行上运行以下命令：

    awk '{printf "%5d MB %s\n", $3*$4/(1024*1024), $1}' < /proc/slabinfo | sort -n

  • 内核未正确使用其交换空间。如果应用程序使用 mlock() 或 HugeTLBfs 页面，则可能无法将其交换空间用于该应用程序。如果发生这种情况，当发生 OOM 时，SwapFree 可能仍会具有非常大的值。但是，这两个功能不允许系统交换受影响的内存，因此过度使用它们可能会耗尽系统内存，使系统别无选择。系统还可能陷入某种死锁。将数据写入磁盘本身可能需要为各种 I/O 数据结构分配内存。如果系统甚至找不到该内存，则用于创建可用内存的功能将受到限制，并且系统可能会耗尽内存。可以进行一些细微调整以更早地开始分页，但如果系统无法足够快地写出脏页以释放内存，则只能得出这样的结论：工作负载与已安装的内存不匹配，并且几乎无能为力。提高 /proc/sys/vm/min_free_kbytes 中的值将导致系统比以前更早开始回收内存。这使得陷入此类死锁变得更加困难。如果您遇到这些死锁，这是一个值得调整的值。如果您遇到调整此值有帮助的情况，请报告。我们可能需要更改默认值。

  • 内核做出了错误的决定，误读了统计数据。内核在仍有大量可用 RAM 的情况下发生了 OOM。

  • 发生了一些非常不正常的事 内核在花费“大量”时间扫描内存以释放某些内容后，实际上决定进入 OOM。从 2.6.19 开始，此“大量”时间发生在 VM 扫描了等于区域内所有（当前）活动+非活动页面六次之后。如果内核正在快速扫描页面，但 I/O 设备（交换、文件系统或网络 fs）太慢，内核可能会判断没有进展并触发 OOM，即使有空闲的交换。

跑步这个脚本在测试期间，以及 OOM。运行脚本，将输出发送给 VM 专家。让他们解析它。然后回来更新此页面。;)

相关内容