【问题标题】:What does docker mean when it says "Memory limited without swap"docker 说“没有交换的内存有限”是什么意思
【发布时间】:2021-08-17 23:54:28
【问题描述】:

我在运行 docker 时收到警告:

警告:您的内核不支持交换限制功能或未安装 cgroup。内存有限,无交换。

我正在尝试弄清楚这意味着什么,尤其是“没有交换的内存受限”这句话。

这是否意味着容器可以使用比您通常通过使用主机的交换空间所允许的更多的内存?或者这是否意味着容器无法使用交换空间,即使主机完全耗尽内存?是因为没有配置交换空间造成的吗?如果您仍然不使用交换,这无关紧要吗?

注意:我对如何修复它不感兴趣 - 谷歌上有很多关于它的结果。我感兴趣的是它意味着什么,以及它为什么重要。

【问题讨论】:

标签: docker


【解决方案1】:

Docker 守护进程依赖以下虚拟文件来实现内存和交换限制:

/sys/fs/cgroup/memory/memory.limit_in_bytes
/sys/fs/cgroup/memory/memory.memsw.limit_in_bytes

如果您的内核不支持交换内存限制,则第二个文件将不存在,docker run 不会对交换空间的使用施加任何限制。这样,容器甚至可以使用比-m, --memory 设置更多的交换空间,就好像--memory-swap 已设置为-1。显然,容器不能使用比您在系统上配置的更多的交换空间。

但是,警告信息也试图说明选项-m, --memory仍然会生效,并且将按预期设置最大用户内存量(包括文件缓存)。


上述cgroup挂载点可能不同,请咨询/proc/self/mounts

【讨论】:

  • "选项 --memory-swap 无效" - 你的意思是容器可以使用它想要的所有交换,就好像你设置了--memory-swap -1docs.docker.com/config/containers/resource_constraints/… 如果您有 2 个需要大量内存的容器,这可能是一个问题 - 它们都将使用大量交换空间,直到没有剩余空间并且其中一个会死掉?
  • @rjmunro 我更正了答案。至于 2 个容器的问题,我不知道内核最终是选择了 2 个容器中的一个作为受害者杀死,还是选择了其他一些随机进程。
【解决方案2】:

这是我找到的。

默认情况下不使用交换。您可以在/sys/fs/cgroup/memory/memory.stat 上在 Ubuntu/Debian 容器上检查这一点。检查swap value,您会看到它设置为0(字节)。没有交换使用。

您通常可以使用--memory--memory-swap 标志来enable and limit swap usage,这就是这个警告似乎会得到你的地方。来自Docker's documentation 的关于非常相似的警告:

如果您不需要这些功能,可以忽略警告。您可以按照这些说明在 Ubuntu 或 Debian 上启用这些功能。

tl;dr:默认情况下禁用交换。如果 cgroup 被禁用或容器交换限制如此警告所示受到其他影响,您将无法设置这些限制。

【讨论】:

  • 请注意:“即使 Docker 未运行,内存和交换记帐也会产生大约 1% 的总可用内存开销和 10% 的整体性能下降。”因此,如果您确实需要,请启用它。
【解决方案3】:

对于上述问题,我们无法在 Ubuntu 16.04 上安装 Docker 设置限制。这是因为默认情况下禁用 cgroups 交换。

尝试设置限制时,您将收到以下错误。

root@ubuntuserver:~# docker container run -d -ti --hostname testcontainer -- 名称 testubuntu2 --restart=always --memory="50m" --memory-swap=0 --cpus="0.5" ubuntu:16.04 警告:您的内核不支持交换限制功能或 cgroup 未安装。内存有限,没有交换。 1fb75aba88e61cf4ca7c96fdd6db939b474d80c0d923233bcb176bf81224dc44 root@ubuntuserver:~#

为了解决上述问题,请使用以下条目更新 grub 文件:

root@ubuntuserver:~# cat /etc/default/grub |grep GRUB_CMDLINE_LINUX
GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity"
GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

现在更新 grub:

root@ubuntuserver:~# update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-74-generic
Found initrd image: /boot/initrd.img-4.15.0-74-generic
done
root@ubuntuserver:~#

完成后重启机器并创建具有内存限制的容器:

root@ubuntuserver:~# docker container run -d -ti --hostname testcontainer -- 
name testubuntu2 --restart=always --memory="50m" --memory-swap=0 --cpus="0.5" 
ubuntu:16.04
93969354be0445f3458999259747d82231b4084728c3ccf8801dc89be8aadaa3
root@ubuntuserver:~#

【讨论】:

  • 是的,但是不“修复”这个问题会有什么后果呢?请回答OP问题:v(我也想知道)
  • 另外,为什么默认情况下没有这样设置? “解决”这个问题有什么缺点?
  • 下面有一条评论建议修复此问题会导致较小的内存损失和较大的性能损失。我个人没有经验。
【解决方案4】:

我发现 Docker 的解决方案如下:

在您的 docker build 机器上,使用以下条目创建一个 sysctl.conf 文件:

vm.nr_hugepages=128 

(128是我选的,你可以相应改变)

在 Dockerfile 中的下一步 - 将以下内容添加到进程中。

COPY /folderlocation/sysctl.conf /etc/sysctl.conf

这会将sysctl文件复制到docker镜像中的正确目录中。

这适用于我的 docker XMRig 解决方案。

【讨论】:

  • 正如我在问题中所说:我对如何修复它不感兴趣 - 谷歌上有很多关于此的结果。我对它的含义以及它的重要性很感兴趣。
  • 对于我们这些想要修复的人来说可能会很有趣;-)
  • 如果您对不同问题的答案感兴趣,您应该提出不同的问题。问题显然是关于消息的含义和含义以及交换机制等。而不是关于如何启用一种或另一种设置。
【解决方案5】:

docker post-install documentation 中说明了修复此警告的一个影响:

即使 Docker 未运行,内存和交换记帐也会产生大约 1% 的总可用内存开销和 10% 的整体性能下降。

如果您不需要这些功能,可以忽略警告。

This answer 状态

如果您正在使用交换并希望强制执行包括内存和交换的内存限制,则 cgroup 交换限制很重要。

这听起来像是警告意味着容器仍然可以使用“无限”量的内存。一旦达到强制的--memory= 限制,它就会开始交换到交换空间。如果它已满,它就会停止。但是通过“修复”这个警告,我们也可以给它有限的交换空间。
这在我们需要保证其他程序也有可用交换空间的情况下很有用。

【讨论】:

    【解决方案6】:

    如果您使用交换,并且只关心 RAM 限制,我可以确认在 ubuntu 18.04 上,容器内的进程将被终止一次即使没有内核设置,也已达到其指定的内存限制。

    在我的测试中,我在容器的正常进程旁边执行并运行了一些内存密集型的东西,只是大进程被杀死了:我期待整个容器重新启动。这是在 docker swarm 中使用 compose 文件中设置的资源限制。

    我不知道 cgroup_enable=memory 是否会以某种方式使这变得更好......也许它会导致容器中所有进程的组合内存作为一个组被更有效地监控?

    【讨论】:

      【解决方案7】:

      可能是因为你在这里使用了 -m 标志:

      docker build \
        --build-arg commit_datavana="$commit_sha" \
        --build-arg CACHE_BUST="$(date)" \
        -m 8g \     # hurrrr
        -t "$name_tag" .
      

      如果不需要,可以删除 -m 标志

      【讨论】:

      • 问题是关于由于-m的消息并继续使用它。问题也是关于如何解决docker报告的警告。
      猜你喜欢
      • 2012-08-18
      • 2020-11-22
      • 2023-03-27
      • 1970-01-01
      • 1970-01-01
      • 2015-10-31
      • 1970-01-01
      • 2015-09-07
      • 1970-01-01
      相关资源
      最近更新 更多