Linux 重启后内存不足

Linux 重启后内存不足

我有一台配备 Intel(R) Atom(TM) CPU D525 和 1 GB 内存的服务器。我注意到服务器大约每 7 天就会自动关闭并重新启动。

我检查了内存使用情况,发现当内存使用达到90%时,内核会重启。当我检查内核日志/var/log/messages文件时,我没有找到任何有关内核关闭的信息,只有一条有关内核启动的消息。我检查了该文件/proc/sys/vm/min_free_kbytes,值为“3765”。


我猜想当可用内存非常低,但没有达到系统开始回收内存的数量时。然后内核就无法执行任何操作,因此它会重新启动。

你能给我一些见解吗?

答案1

在某些请求分页虚拟内存系统上,操作系统拒绝分配匿名页面(即包含没有文件系统源的数据的页面,例如运行时数据、程序堆栈等),除非有足够的交换空间来交换这些页面以便释放物理内存。这种严格计算的优点是保证每个进程都能访问它们分配的尽可能多的虚拟内存,但这也意味着可用的虚拟内存量本质上受到交换空间大小的限制。

实际上,程序分配的内存往往多于其使用的内存。例如,Java虚拟机在启动时分配大量虚拟内存,但不会立即使用它。 Linux 内核中的内存统计尝试通过跟踪进程实际使用的内存量来弥补这一点,并且过度承诺虚拟内存量。换句话说,内核分配的虚拟内存量可能超过系统上物理内存和交换空间的总和。虽然这可以更好地利用物理内存和交换空间,但缺点是当使用的内存量超过可用的物理内存和交换空间量时,内核必须以某种方式释放内存资源以满足内存分配承诺。

用于回收内存以填充复用的内核机制称为内存不足杀手(OOM 杀手)。通常,该机制将开始杀死占用内存的“流氓”进程,为其他进程释放内存。但是,如果vm.panic_on_oomsysctl 设置非零,则当系统内存不足时,内核将出现恐慌。

该设置的可能值vm.panic_on_oom如下:

  • 0(默认)当出现内存不足的情况时,OOM-killer 将杀死恶意进程。

  • 1内核通常会出现恐慌,但如果进程已达到使用mbind(MPOL_BIND)或设置的内存分配限制cpuset,则该进程将被终止。

  • 2内核在内存不足的情况下总是会出现恐慌。

OOM-killer 使用的启发式可以通过vm.oom_kill_allocating_tasksysctl 设置进行修改。可能的值如下:

  • 0(默认)OOM-killer 将扫描任务列表并选择一个占用大量内存的恶意任务来杀死。

  • 1(非零)OOM-killer 将终止触发内存不足情况的任务。

可以使用 sysctl 设置来调整内核内存统计算法vm.overcommit_memory。可能的值如下:

  • 0(默认)带有弱检查的启发式过度使用。

  • 1总是过度承诺,​​没有检查。

  • 2vm.overcommit_ratio严格核算,该模式下虚拟地址空间限制由根据以下公式设置的值确定:

    virtual memory = (swap + physical memory * (overcommit_ratio / 100))
    

当使用严格的内存统计时,内核将不再分配匿名页面,除非它有足够的可用物理内存或交换空间来存储页面。这意味着该系统必须配置了足够的交换空间

可以在运行时使用该sysctl命令检查或修改 sysctl 设置。要使更改永久化,可以将设置写入/etc/sysctl.conf.上述设置也可以通过/proc/sys/vm界面。对应的文件有:

  • /proc/sys/vm/panic_on_oom

  • /proc/sys/vm/oom_kill_allocating_task

  • /proc/sys/vm/overcommit_memory

  • /proc/sys/vm/overcommit_ratio

答案2

  • 我认为你应该找出该进程消耗了大量内存。也许该程序存在内存泄漏错误。你应该修复它。
  • 如果没有足够的内存,Linux将关闭一些消耗大量内存的进程,或者重新启动自己。因为内核必须使用一些内存。
  • 不同的行为是由配置决定的。但我认为你应该修复内存泄漏错误。

答案3

我猜测某些(内核?)看门狗检测到系统挂起,这就是导致重新启动的原因。诸如此类的内核.config选项CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC可能会在检测到系统挂起的特定超时后导致重新启动。

真正的问题是:为什么系统会挂起?我相信这与这个问题相同:OOM 杀手无法正常工作,导致操作系统冻结

相关内容