[论文解读] Blade: A Data Center Garbage Collector

David Terei, Amit Levy|arXiv (Cornell University)|Apr 10, 2015

Advanced Data Storage Technologies参考文献 6被引用 6

一句话总结

Blade 是一种用于垃圾回收（GC）语言中分布式系统的垃圾回收协调 API，将 GC 暂停视为可预测的故障，从而通过故障恢复机制实现协调。它消除了 HTTP 负载均衡器和 Raft 共识等系统中的 GC 导致的尾部延迟，将影响降低至单次网络往返时间（48 μs），性能表现与完全无 GC 的系统相当。

ABSTRACT

An increasing number of high-performance distributed systems are written in garbage collected languages. This removes a large class of harmful bugs from these systems. However, it also introduces high tail-latency do to garbage collection pause times. We address this problem through a new technique of garbage collection avoidance which we call Blade. Blade is an API between the collector and application developer that allows developers to leverage existing failure recovery mechanisms in distributed systems to coordinate collection and bound the latency impact. We describe Blade and implement it for the Go programming language. We also investigate two different systems that utilize Blade, a HTTP load-balancer and the Raft consensus algorithm. For the load-balancer, we eliminate any latency introduced by the garbage collector, for Raft, we bound the latency impact to a single network round-trip, (48 μs in our setup). In both cases, latency at the tail using Blade is up to three orders of magnitude better.

研究动机与目标

• 许多现代分布式系统使用 Go 和 Java 等垃圾回收语言构建，这些语言可防止内存错误，但因 GC 暂停时间不可预测，导致尾部延迟较高。
• 现有的 GC 优化主要关注平均性能，未能解决对现代数据中心工作负载至关重要的微秒级延迟保证所要求的尾部延迟问题。
• 应用层 GC 调优困难且依赖工作负载，禁用 GC 或切换到手动内存管理则会牺牲安全性和开发效率。
• 本文旨在通过与系统级故障恢复机制集成，使应用开发者能够控制 GC 触发时机，从而隐藏 GC 暂停的影响。
• 目标是无需修改底层 GC 运行时，即可在生产系统中消除或限制与 GC 相关的尾部延迟。

提出的方法

• Blade 暴露一个简单 API，允许应用在垃圾回收开始前注册回调函数，从而实现与故障恢复机制的协调。
• 该 API 允许应用将 GC 延迟到安全时刻执行，例如网络往返之后或已知的空闲时段。
• 它将 GC 暂停视为一种可控故障，利用现有的系统容错模式（如请求复制或领导者选举）来隐藏其影响。
• 该方法集成于 Go 运行时，使开发者无需更改语言或 GC 实现即可选择性启用 GC 协调。
• 系统通过应用层协调避免节点间 GC 重叠，从而降低端到端延迟影响。
• 两个案例研究——HTTP 负载均衡器和 Raft 共识——证明了 Blade 在真实系统中的有效性。

实验结果

研究问题

• RQ1 是否可以通过应用层协调而非 GC 优化，来消除或限制分布式系统中 GC 暂停的影响？
• RQ2 是否可以复用分布式系统中现有的故障恢复机制，以隐藏 GC 暂停的影响，而无需修改 GC 运行时？
• RQ3 在端到端尾部延迟方面，Blade 与默认 GC 和完全禁用 GC 相比表现如何？
• RQ4 Blade 是否能在真实工作负载中实现与无 GC 系统相当的性能？
• RQ5 使用 Blade 在多个节点间协调 GC 时，性能开销或延迟影响如何？

主要发现

• 在 HTTP 负载均衡器用例中，Blade 完全消除了与 GC 相关的尾部延迟，性能与无 GC 系统无异。
• 对于 Raft 共识算法，Blade 将 GC 影响限制为单次网络往返时间，实验设置下测量结果为 48 μs。
• 使用 Blade 的端到端延迟与无 GC 系统的最优性能相当，证明了 GC 影响可被完全隐藏。
• 与默认的 Go 垃圾回收器相比，该方法在尾部延迟方面实现了高达三个数量级的改进。
• Blade 通过将延迟缓解任务交由应用层协调，使高吞吐量、简单 GC 设计成为可能，而无需依赖复杂的低延迟收集器。
• 该方法具有通用性，无需修改 GC 运行时，因此可推广至其他具有类似 API 的垃圾回收语言。