我们怎样在30项关键服务任务中节省 70K 内核
发布时间：2022-03-06 17:35:11 所属栏目：动态 来源：互联网
导读：作为 Uber 工程实现盈利的众多努力的一部分，最近我们的团队致力于通过提高效率来降低算力成本。其中最有影响力的一些工作是围绕 GOGC 优化展开的。在这篇博客，我们想分享我们在高效、低风险、大规模、半自动化 Go 垃圾回收调优机制方面的经验。 Uber 的
|
作为 Uber 工程实现盈利的众多努力的一部分，最近我们的团队致力于通过提高效率来降低算力成本。其中最有影响力的一些工作是围绕 GOGC 优化展开的。在这篇博客，我们想分享我们在高效、低风险、大规模、半自动化 Go 垃圾回收调优机制方面的经验。 Uber 的技术栈由数千个微服务组成，由云原生的基于调度的基础设施支持。这些服务中的大部分都是用 Go 编写的。我们的团队——地图制作工程组，以前曾在通过调优 GC 来显著提高多个 Java 服务的效率方面发挥过重要作用。在 2021 年初，我们探讨了对基于 Go 的服务进行性能调优的可能性。我们运行了几个 CPU 配置文件来评估当前的状态，发现 GC 是大多数关键任务服务的最大 CPU 消费者。下面是一些 CPU 配置文件的代表，其中 GC（由 runtime.scanobject 方法标识）消耗了分配的计算资源的很大一部分。 Go 运行时环境以周期性的间隔调用并发垃圾回收器，除非之前有一个触发事件。触发事件基于内存背压。因此，受 GC 影响的 Go 服务受益于更多的内存，因为这减少了 GC 必须运行的次数。另外，我们意识到我们的主机级 CPU 与内存的比率是 1:5（1 core：5 GB 内存），而大多数 Golang 服务的配置比率是 1:1 到 1:2。因此，我们相信我们可以利用更多的内存来减少 GC CPU 的影响。这是一种与服务无关的机制，如果应用得当，会产生很大 不知道分配给容器的最大内存，可能导致内存溢出问题。 我们的微服务具有显著不同的内存使用量组合。例如，分片系统可以有非常不同的实时数据集。我们在其中一个服务中遇到了这种情况，其中 p99 的使用量是 1GB，而 p1 的使用量是 100MB，因此 100MB 的实例对 GC 有巨大影响。 自动化案例 前面提到的痛点是提出 GOGCTuner 概念的原因。GOGCTuner 库简化了服务所有者优化垃圾回收的过程，并在其上添加了一个可靠性层。 GOGCTuner 根据容器的内存限制（或服务所有者的上限）动态计算正确的 GOGC 值，并使用 Go 的运行时 API 进行设置。以下是 GOGCTuner 库功能的详细信息： 简化配置来便于推理和确定性计算。GOGC 的 100% 对于 GO 初学开发者来说并不明确，也并不确定，因为它仍然依赖于实时数据集。另一方面，70% 的限制可确保服务始终使用 70% 的堆空间。 防止 OOM（内存溢出）：这个库从 cgroup 读取内存限制，并使用默认的硬限制 70%（这是我们经验中的安全值）。 值得一提的是，这种保护是有限度的。微调器只能调整缓冲区分配，因此如果您的服务的存活对象高于微调器的限制，微调器会将比较低的存活对象的使用量的 1.25 倍设置成默认的限制值。 对于以下情况，允许更高的 GOGC 值： 如上所述，手动 GOGC 是不确定的。我们仍然依赖实时数据集的大小。如果实时数据集是我们上一个峰值的两倍怎么办？GOGCTuner 将使用更多的 CPU 来强制执行相同的内存限制。相反，手动调整会导致内存溢出。因此，服务所有者过去常常为这些类型的场景提供大量的缓存。请参见下面的示例： 使用 MADV_FREE 内存策略的服务会导致错误的内存度量。例如，我们的可观测性指标显示了 50% 的内存使用量（实际上它已经释放了这 50% 中的 20%）。然后，服务所有者只使用这个“不准确的”指标来调整 GOGC。 可观测性 我们发现，我们缺乏一些可以让我们对每个服务的垃圾回收有更多了解的关键指标。 垃圾回收之间的间隔 ：这可以使我们了解是否还可以调整。如果你的服务仍然有很高的 GC 影响，但你已经看到了这个图 120s，这意味着你不能再使用 GOGC 进行调整。在这种情况下，您需要优化分配。 实 现 我们最初的方法是，让一个计时器每秒运行一次来监控堆指标，然后相应地调整 GOGC 值。这种方法的缺点是，开销开始变得相当大，因为为了读取堆指标，Go 需要执行一次 STW（ReadMemStats），这还不怎么准确，因为我们每秒可能会多次进行垃圾回收。 （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
