我在 GCE 上有一个虚拟机，我在其中运行自定义 Docker 映像。我在 COS (cos-stable-74-11895-125-0) 上将其安装到 g1-small (1 vCPU，1.7 GB 内存) 实例上。
这是一个具有锁定内存设置的 Elasticsearch。它消耗的 RAM 恰好为 1 GB。
该设置运行完美近一年，但突然因内存不足而停止工作。
在串行控制台上，它记录了 oom-killer 被调用并且它选择了要终止的 java 进程。快速重启后，它运行正常，但大约一两天后，它又失败了，并出现相同的内存不足错误。
事实证明，GCE 安装并运行了一个 Stackdriver Logging Agent，与我的容器并行运行。根据 oom-killer 日志，一个相关的红宝石进程消耗了大量的内存。重启后，它占用了 50 MB 的内存，几个小时后内存就堆积到了 300MB。在我看来，这似乎是内存泄漏。
要清楚一点：ES 服务器没有接收任何负载，只有定期的正常运行时间检查每 5 分钟发出一次请求。因此，没有大量的日志，每小时只有几行。一整年的日志不会占用 300MB 的存储空间或内存。
我尝试使用以下方法检查内存占用附言和顶部命令，但结果完全不可信。根据系统，红宝石任务消耗 1-10GB 的物理内存 (RSS) 和最多 70GB 的虚拟内存 (VSZ)。（根据自由的命令。）这些数字不可能是真实的，因为虚拟机没有这么多的 RAM。
我尝试将操作系统更新到较新的版本 (cos-81-12871-119-0)。这确实有帮助，因为 ES 已经运行了 5 天多，没有出现问题。但是红宝石进程的内存消耗令人担忧。根据附言和顶部命令，它使用 70-300MB 的物理内存（RSS）和高达 7GB 的虚拟内存（VSZ）。
我发现红宝石过程是流畅根据 GitHub 上的信息，该工具也存在类似的内存问题。由于配置和安装由 GCE 自动完成，因此我没有找到更改其设置的方法。
最简单的解决方案是通过更改 VM 元数据来禁用日志代理的安装。（google-logging-enabled=false）。但我想找出发生这种情况的原因以及如何解决它。
我真的很好奇是否有人遇到过类似的问题，以及解决方案是什么。
Stackdriver 日志代理 Docker 映像：gcr.io/stackdriver-agents/stackdriver-logging-agent:0.2-1.5.33-1-1
该错误可以重现。我在不同的 GCP 项目中有一个开发环境和一个生产环境。这两个错误大约同时出现。（~2020 年 5 月 28 日。）据此，我认为这是由 Stackdriver 中的更改引起的，但我在日志中没有找到任何证据。（两个 VM 实例都在 eu-west3 地区的 c 区。）
我将非常感激您的帮助或建议。谢谢！
答案1
对于遇到类似问题的人：
cos-77-12371-1109-0正在运行g1-小使用内存如下：
MiB Mem : 1692.4 total, 1409.3 free, 176.0 used, 107.1 buff/cache
云端监控代理有自己的内存要求：
建议至少有 250 MiB 的常驻（RSS）内存来运行监控代理。
除此之外，还有docker：
这是一个具有锁定内存设置的 Elasticsearch。它消耗的 RAM 恰好为 1 GB。
因此剩余 1409-1000-250=159 MB，余量小于 10%。
为了避免内存不足问题，请考虑禁用 fluentd或创建具有更多 RAM 的虚拟机。
如果您认为您发现了 GCP 的错误，您可以在公共问题追踪。