内存管理 – 没有足够的ram来运行整个docker-compose堆栈

2023年10月9日 195次阅读

我们的微服务堆栈现在已经为业务逻辑提供了多达15个小型服务,如Auth,消息传递,计费等.现在,它已经达到了一个Docker-compose比我们的开发人员在他们的笔记本电脑上使用更多ram的程度.

这不是一个疯狂的数量,大约4GB,但我经常感受到我的8GB机器的压力(谢谢,Chrome).

应用程序级别的优化我们可以,并且确实在做,但最终我们还需要一种替代策略.

我看到两个明显的选择：

>使用大型多云开发机器,可能配备码头机和aws.
>将一些机器分成共享开发云,如postgres和redis

这些都不是很令人满意,在(1)中,本地文件没有同步,使得本地开发成为噩梦,而在(2)中我们可以打破彼此的环境.

救命！

Apendix 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

最佳答案 我们一直在努力解决这个问题,但仍然没有一个理想的解决方案.但是,我们目前正在讨论两个想法.

>在云中运行“开发”环境,不断更新每个图像的主/最新版本.然后,每个单独的项目都可以在其docker-compose.yml文件中代理该环境……因此它们在本地运行THEIR服务,但所有依赖项都是远程的.这个(从你的问题)的一个重要部分是你有共享的依赖,如数据库.绝不应该这样……永远不要整合数据库.每个服务都应存储自己的数据.
>每项服务都负责构建其应用程序的“模拟”版本,可用于本地开发和中级集成测试.模拟版本不应该具有依赖性,并且应该允许某人仅需要来自其服务的单个层(3或4个模拟,而不是3或4个真实服务,每个服务具有自己的3或4个等等).

点赞