Groupcache: 内存限制上限问题

你好，

感谢组缓存，我们使用它几乎取得了巨大成功。

我想更多了解的一件事是如何估计/了解应用程序内存需求的上限，其主要功能只是从组缓存中提供服务。

所以我们有 6GB vm 的运行组缓存，我们的第一个倾向是将可用缓存大小设置为 5gb，为操作系统和其他东西留出 1gb 空闲空间。

由于调用了 OOM 杀手，这立即在生产负载下崩溃了。 所以我们最终将这个数字降低到 2GB 以下，以便进程使用的内存在 OOM 杀手开始之前保持在 6GB 以下。

所以下一步是分析内存，并且发现堆大小不远超过我们在组缓存中配置的 2GB。 但是这个过程最终使用了 4-6GB 的内存。

所以最新的尝试是每隔几分钟手动调用 debug.FreeOSMemory() ，当它运行时，不久之后，进程需要的内存量下降，很多都返回给操作系统。

但是，由于 OOM 杀手，我们仍然偶尔会崩溃。 我们添加了 SSD 交换来缓冲这种情况，但是在 48 小时没有问题后，这些机器的流量出现了一个短暂的现象（大幅增加），导致单个机器 OOM 被杀死，然后滚雪球般地变成其他几个发生这种情况的机器。

因此，为了完成这项工作，我们可以将 2GB 缓存设置（又名 groupcache.NewGroup 中的第二个参数）降低到 1GB，但是拥有一个只能使用 1GB 缓存的 6GB 虚拟机似乎有点愚蠢。

这只是使用 go 的内存管理方法进行缓存的缺点吗？

不确定它是否重要，但我们的用例与 dl.google.com 非常相似。 我们正在为中等大小的文件（50mb-1gb，以 100MB 块缓存）的下载提供服务，组缓存用于前置一个更慢、更昂贵的 api，其中包含我们需要提供的文件。 所以很自然地，当找到这个时，它似乎是解决问题的一个很好的方法。

我们将非常感谢您可以分享管理此类问题的任何技巧。 我一直在想我错过了什么。

感谢您可以分享的任何见解。

• 斯科特