没有足够的内存来运行整个 docker-compose 堆栈答案

【问题标题】：Not enough ram to run whole docker-compose stack没有足够的内存来运行整个 docker-compose 堆栈
【发布时间】：2016-06-29 17:24:48
【问题描述】：

我们的微服务堆栈现在已经为身份验证、消息传递、计费等业务逻辑提供了多达 15 个小型服务。现在，docker-compose up 使用的内存比我们的开发人员笔记本电脑上的内存还要多。

这不是一个疯狂的数字，大约 4GB，但我经常感觉到我的 8GB 机器上的压力（感谢 Chrome）。

我们确实可以并且正在做应用级优化，但最终我们将需要一种替代策略。

我看到了两个明显的选择：

使用大型多云开发机器，可能配备 docker-machine 和 aws。
将一些机器转入共享开发云，例如 postgres 和 redis

这些都不是很令人满意，在 (1) 中，本地文件不同步，使本地开发成为一场噩梦，在 (2) 中我们可以破坏彼此的环境。

帮助！

附录 I：来自 docker stats 的输出

CONTAINER           CPU %               MEM USAGE / LIMIT     MEM %               NET I/O               BLOCK I/O
0ea1779dbb66        32.53%              137.9 MB / 8.186 GB   1.68%               46 kB / 29.4 kB       42 MB / 0 B
12e93d81027c        0.70%               376.1 MB / 8.186 GB   4.59%               297.7 kB / 243 kB     0 B / 1.921 MB
25f7be321716        34.40%              131.1 MB / 8.186 GB   1.60%               38.42 kB / 23.91 kB   39.64 MB / 0 B
26220cab1ded        0.00%               7.274 MB / 8.186 GB   0.09%               19.82 kB / 648 B      6.645 MB / 0 B
2db7ba96dc16        1.22%               51.29 MB / 8.186 GB   0.63%               10.41 kB / 578 B      28.79 MB / 0 B
3296e274be54        0.00%               4.854 MB / 8.186 GB   0.06%               20.07 kB / 1.862 kB   4.069 MB / 0 B
35911ee375fa        0.27%               12.87 MB / 8.186 GB   0.16%               29.16 kB / 6.861 kB   7.137 MB / 0 B
49eccc517040        37.31%              65.76 MB / 8.186 GB   0.80%               31.53 kB / 18.49 kB   36.27 MB / 0 B
6f23f114c44e        31.08%              86.5 MB / 8.186 GB    1.06%               37.25 kB / 29.28 kB   34.66 MB / 0 B
7a0731639e31        30.64%              66.21 MB / 8.186 GB   0.81%               31.1 kB / 19.39 kB    35.6 MB / 0 B
7ec2d73d3d97        0.00%               10.63 MB / 8.186 GB   0.13%               8.685 kB / 834 B      10.4 MB / 12.29 kB
855fd2c80bea        1.10%               46.88 MB / 8.186 GB   0.57%               23.39 kB / 2.423 kB   29.64 MB / 0 B
9993de237b9c        40.37%              170 MB / 8.186 GB     2.08%               19.75 kB / 1.461 kB   52.71 MB / 12.29 kB
a162fbf77c29        24.84%              128.6 MB / 8.186 GB   1.57%               59.82 kB / 54.46 kB   37.81 MB / 0 B
a7bf8b64d516        43.91%              106.1 MB / 8.186 GB   1.30%               46.33 kB / 31.36 kB   35 MB / 0 B
aae18e01b8bb        0.99%               44.16 MB / 8.186 GB   0.54%               7.066 kB / 578 B      28.12 MB / 0 B
bff9c9ee646d        35.43%              71.65 MB / 8.186 GB   0.88%               63.3 kB / 68.06 kB    45.53 MB / 0 B
ca86faedbd59        38.09%              104.9 MB / 8.186 GB   1.28%               31.84 kB / 18.71 kB   36.66 MB / 0 B
d666a1f3be5c        0.00%               9.286 MB / 8.186 GB   0.11%               19.51 kB / 648 B      6.621 MB / 0 B
ef2fa1bc6452        0.00%               7.254 MB / 8.186 GB   0.09%               19.88 kB / 648 B      6.645 MB / 0 B
f20529b47684        0.88%               41.66 MB / 8.186 GB   0.51%               12.45 kB / 648 B      23.96 MB / 0 B

【问题讨论】：

提前谢谢大家！
我们最容易实现的目标是postgres，运行ALTER SYSTEM SET max_connections TO 1000
为了解决您的问题，我们必须对您的堆栈有更多的了解。你能分享一下这 15 种服务是什么吗？每个服务的配置是什么？每个服务的内存占用是多少？
4GB 对于 15 项服务来说听起来很多。您更改 postgres 设置的解决方案听起来不错。您可能还可以执行其他一些操作来调整服务使用的内存。
确实是postgres 吞噬了所有内存。大多数服务是 python-bases、flask 或 django，尽管我们也有 go 和 scala 服务。所有这些都使用

标签： memory-management docker docker-compose boot2docker

【解决方案1】：

我们也一直在努力解决这个问题，但仍然没有真正的理想解决方案。但是，我们目前正在讨论两个想法。

在云中运行“开发”环境，该环境在构建时使用每个映像的主/最新版本不断更新。然后每个单独的项目可以在他们的 docker-compose.yml 文件中代理到那个环境......所以他们在本地运行他们的服务，但所有的依赖项都是远程的。这其中的一个重要部分（根据您的问题）是您具有共享的依赖项，例如数据库。永远不应该是这种情况......永远不要跨数据库集成。每个服务都应该存储自己的数据。
每个服务都负责构建其应用程序的“模拟”版本，该版本可用于本地开发和中级集成测试。模拟版本不应该有依赖关系，并且应该使某人只需要他们的服务中的一个层（3 或 4 个模拟，而不是 3 或 4 个真实服务，每个服务都有 3 或 4 个自己的服务等等）。

【讨论】：