【问题标题】:What happens when docker container running JVM reaches memory limit?当运行 JVM 的 docker 容器达到内存限制时会发生什么?
【发布时间】:2020-03-23 14:51:51
【问题描述】:

比方说,一个 docker 容器在一个 16G RAM、2 核 CPU 的服务器中运行 JVM,以下是容器的内存限制:

mem_limit: 14G
max_mem: 13G
threads: 1
max_pool_size: 20

max_mem 是 JVM 使用的最大堆大小,mem_limit 是容器使用的最大内存。我正在尝试了解以下内容:

  1. 当 JVM 达到 max_mem 限制时会发生什么?
  2. 当容器到达mem_limit时会发生什么?
  3. 是否会在有或没有 OOM 错误日志消息的情况下重新启动?我们在哪里可以看到这些日志?
  4. max_mem 之后我们应该为容器留多少内存?
  5. 线程如何影响内存限制?

【问题讨论】:

  • 它应该在很大程度上与非 Docker JVM 进程的行为方式相同,以 -Xmx13G 开头,在具有 14 GB 内存的系统上;根据 JVM 内部发生的其他情况,您将获得内核 OOM-killed 或获得 Java 级别的 OutOfMemoryError。

标签: docker memory jvm


【解决方案1】:

1.当 JVM 达到 max_mem 限制时会发生什么?
它必须崩溃。如果您有实时恢复或在 docker-swarm 或 kubernetes 上,它会迅速启动另一个容器。

2。当容器达到 mem_limit 时会发生什么?
它必须报告和崩溃。答案同上。

3.它会在有或没有 OOM 错误日志消息的情况下重新启动吗?
它给出了OOM错误。问题1,错误日志在容器内部,所以需要登录死容器查看日志。问题 2,错误日志来自 docker,docker logs 必须显示。 Docker 日志也​​会显示您的容器日志。

4.我们在哪里可以看到这些日志?
上面的问题已经回答了

5.在 max_mem 之后我们应该为容器留多少内存?
为您的应用程序进行内存模型设计并添加一个缓冲区并据此限制您的容器。如果您的容器因 OOM 而不断崩溃,请确保修复您的应用程序代码

6.线程如何影响内存限制?
Thread 是一个运行器,它使用内存或磁盘中的资源。线程的数量阻塞内存不是因为它们的数量很大,而是因为它们在创建时携带的内存中的本机数据。


希望我已经回答了你的问题。

【讨论】:

  • 1. 当JVM达到内存限制时容器会崩溃吗? 2. JVM 崩溃和容器崩溃有什么区别吗? 3. 我查找了 1 和 2 的日志,但我看到的唯一日志是 var/log/messages。当容器达到内存限制时更新? 4. 请详细说明? 5. 据我了解,threads 用于多核处理器中的多线程。我的问题是关于它对容器的影响。
  • 你的容器进程本身是基于父线程的。并且容器内的每个进程都在多个线程上运行。线程对主机的影响是它对容器具有相同的影响。和日志。是的,如果你的容器崩溃了,docker logs 会给你 oom。如果您没有手动删除它们,您也可以在死容器上执行 docker logs。以及容器崩溃和 jvm 崩溃之间的差异。 ?对我来说,即使它们是 Diff 净结果也是一样的。您的应用已关闭。
【解决方案2】:

查看文档,似乎有一个 memswap_limit 选项,所以我认为可以安全地假设使用交换。它可能会崩溃,因为 jvm 擅长于此,但我想它只会运行缓慢。

线程本身不会变慢,但它本质上会因交换导致读/写速度慢而成为瓶颈。

你的 max mem 问题是一个相当难以回答的问题,而不会弄乱它。您可能会找到有人推荐 10-20% 净空的地方,但您应该真正尝试找到自己的最佳位置。

注意:14gb 内存对于单个容器来说已经很多了。如果可能,您应该考虑将工作负载分布在多个容器上。 Docker run 允许您使用 --scale arg 扩展容器,并且 kubernetes 等编排平台可以为您管理流程。

【讨论】:

  • 对不起,这不能回答我的问题。另外,对于容器来说,14GB RAM 并不是必须的,分配给容器的 RAM 完全取决于 docker 容器在做什么。
猜你喜欢
  • 2012-10-27
  • 1970-01-01
  • 2018-03-03
  • 2016-09-26
  • 1970-01-01
  • 2015-02-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多