标签: out-of-memory

我正在运行一些非常繁重的 python 程序。我已经运行这个脚本好几个星期了，但在过去的几天里，程序被以下消息杀死：

Killed

我尝试创建一个8 GB的新交换文件，但它一直在发生。

我也尝试使用：

dmesg -T| grep -E -i -B100 'killed process'

其中列出了错误：

[Sat Oct 17 02:08:41 2020] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service,task=python,pid=56849,uid=1000
[Sat Oct 17 02:08:41 2020] Out of memory: Killed process 56849 (python) total-vm:21719376kB, anon-rss:14311012kB, file-rss:0kB, shmem-rss:4kB, UID:1000 pgtables:40572kB oom_score_adj:0

我有一台强大的机器，我尝试在运行时也没有运行其他任何东西（Pycharm 或终端），但它一直在发生。

眼镜：

• Ubuntu 20.04 LTS（64 位）
• 15.4 GiB 内存
• 英特尔酷睿 i7-105100 CPU @ 1.80 GHz x 8

跑步时 free -h t

             total        used        free      shared  buff/cache   available
Mem:           15Gi       2.4Gi        10Gi       313Mi       2.0Gi        12Gi …

我想从我的 carddav 服务器 (ownCloud) 备份我所有的 .vcf 文件。该脚本非常简单，如下所示：

$ wget -Avcf -r -np -l0 --no-check-certificate -e robots=off --user=user \
    --password='password' https://cloud.domain.com/foo/carddav

.vcf 文件总数约 400 个，下载约 70 个后，wget 返回此错误：

原文网址：http : //oi40.tinypic.com/2ch9itt.jpg

由于系统“内存不足”而终止进程。系统是Debian Wheezy 虚拟机，运行在Windows 7 上。我尝试将RAM 提高到1024MB 而不是实际的128MB，但问题仍然存在。

有关如何解决此问题或实现此目标的替代方法的任何建议？

我正在开发基于 ARM 的嵌入式平台。32 位，512MB RAM，无交换。Linux 3.10.53（某些种类的 Ubuntu，如果相关的话）。

我正在处理的一些代码一直被 oom 杀死，尽管我实际测量的所有内容都表明它死后有足够的内存可用。这可能是什么原因造成的？

在运行进程之前， free -m 报告了大约 320MB free，这也接近 /proc/meminfo 中的 LowFree 数字；来自 ps -e -o vsize 的所有数字的总和约为 212MB，/proc/meminfo 中的平板数字约为 10MB，这表明不应使用超过约 222MB，这与空闲内存。

然后我运行我的代码，一段时间后它被 oom 杀死了。dmesg 中的注释说该进程的总大小为 180MB；请注意，这远小于运行它之前应该免费的 300MB 左右。正是这个进程自己的内存请求触发了 oom-killer。

（这绝对是杀死进程的 oom-killer；它在 dmesg 中说了这么多，而我的 ulimits 是无限的。）

一个简单的程序

我发现我可以使用绝对微不足道的程序重现我不理解的关键内容。我将描述它，然后（以防有人关心）返回到最初发送给我的更复杂的程序，我已经对其进行了更广泛的测试。

所以，这里有一些代码。无聊的#includes 省略。普通的 C.

int main(void) {
  int i=0, j;
  char * p;
  while (1) {
    fprintf(stderr, "allocating block %d\n", ++i);
    p = malloc(10000000);
    for (j=0; j<10000000; ++j) p[j] = j; …

我遇到了一些间歇性问题，这些问题似乎与 oomkiller 清除一些子进程有关，但我不明白为什么。

有没有一种方便的方法可以通过 sysctl 抑制所有 oomkiller 活动？

我发现一些说明说这些应该有效，但它们对我来说不存在。

sysctl -w memory.oom_control=1
sysctl -w vm.oom-kill=0

我也看到有人建议这两个，但 oom 杀手仍在继续。

sysctl vm.overcommit_memory=2
sysctl vm.overcommit_kbytes=0

多年来，我在没有交换的情况下设置我的 Linux 机器，因为它们有足够的内存来完成我需要的事情，我宁愿一个进程在使用太多内存时被杀死，而不是变得越来越大并悄悄地减慢一切。

然而，我发现我需要交换才能在笔记本电脑上使用休眠功能，因此我创建了一个交换分区，并且休眠功能一直工作正常。

最近我发现机器进入待机状态而不是休眠状态，经过调查发现交换分区中没有足够的空间来进行休眠。这是因为我认为保留用于休眠的交换分区实际上被用作普通交换空间。

有什么方法可以告诉 Linux 仅将给定的交换分区用于休眠，而不是在正常操作期间使用它进行交换？

编辑：根据下面的问题，机器有 8GB 内存，交换分区也是 8GB，因为我只想将其用于休眠使用而不是实际交换使用，因此任何大于机器内存大小的都会被浪费。根本问题是，由于 8GB 交换分区被用作额外内存，因此机器现在最多可以分配 16GB 内存（8GB 物理 + 8GB 交换）。它最近使用了 10GB，当然无法休眠，因为 10GB 无法放入 8GB 交换分区。

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

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

我猜当可用内存非常低，但没有达到系统开始回收内存的数量时。然后内核不能做任何事情，所以它然后重新启动。

你能给我一些见解吗？

我一直在运行一个进程 (gdb)，它可以轻松地用完我所有的 ram 和交换空间。每次发生这种情况时，整个系统都会变得非常无响应，Xorg 几乎不会更新，我无法切换到另一个 tty，我无法在控制台中键入命令等。

我试图通过以下方式留出内存：

sudo sysctl -w vm.min_free_kbytes=407580
sudo sysctl -w vm.swappiness=5

一些虚拟内存被保留下来，但交换空间已用完，然后系统仍然无响应。

有没有人有任何万无一失的方法来防止系统完全冻结？这样我就可以杀死内存占用进程？

更新：

我找到了一种方法来限制从特定 shell 启动的每个进程的内存使用：

ulimit -v 2037900

这将每个进程的虚拟内存限制为 2037900 KiB（这是我的总内存）。这比任何一个进程都应该使用的要多。到目前为止，这似乎可以防止系统变慢和冻结。

我仍然想知道是否有人知道任何好的系统资源管理实践。

我随机遇到 OOM 问题（大约每月一次），但似乎有足够的可用内存。

我无法理解原因以及如何解决它......

vm.min_free_kbytes = 90112

Linux xxx-alpha 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

slabtop

 Active / Total Objects (% used)    : 45902519 / 54189870 (84.7%)
 Active / Total Slabs (% used)      : 1260240 / 1260240 (100.0%)
 Active / Total Caches (% used)     : 151 / 187 (80.7%)
 Active / Total Size (% used)       : 9241442.17K / 10856556.48K (85.1%)
 Minimum / Average / Maximum Object : 0.01K / 0.20K / 23.25K

  OBJS ACTIVE  USE OBJ SIZE  SLABS …

使用 bash 的 globstar ( **) 运算符会导致内存不足错误吗？考虑这样的事情：

for f in /**/*; do printf '%s\n' "$f"; done

何时**用于生成大量文件列表，假设列表太大而无法放入内存，bash 会崩溃还是有处理此问题的机制？

我知道我已经运行**了大量文件并且没有注意到问题，所以我假设 bash 将使用类似临时文件的东西来存储正在生成的一些列表。那是对的吗？bash 可以**处理任意数量的文件，还是会在文件列表超出内存容量时失败？如果它不会失败，它使用什么机制来做到这一点？类似于sort?生成的临时文件的东西。

我正在通过 bash 脚本运行复杂的工作流程，这些脚本使用外部程序/命令来执行不同的操作。它运行了几个小时，但突然 OOM 杀手终止了我的工作流程或整个 bash 脚本的程序，即使仍然有足够的内存可用。我用 ps 命令每 0.01 秒记录一次内存使用情况，根本没有增加或变化，仍然有几个 GB 可用。但是突然从一个内存快照到下一个内存快照，某个进程被 OOM 杀手终止。这是内存使用情况的典型 ps 快照：

PID     %MEM  RSS      VSZ      COMMAND      USER
139443  1.2   1651768  8622936  java         jadzia
123601  0.1   163352   523068   obabel       jadzia
139355  0.0   5488     253120   srun         jadzia
125747  0.0   5252     365088   obabel       jadzia
125757  0.0   5252     365088   obabel       jadzia
125388  0.0   5224     365088   obabel       jadzia
125824  0.0   3764     267736   obabel       jadzia
21062   0.0   3724     128628   bash         jadzia
125778  0.0   3628     267736   obabel       jadzia
127018  0.0   1904 …