Go 1.5 的垃圾收集器准备好进行 TB 级内存管理了吗？

How Fast Is the Go 1.5 GC with Terabytes of RAM?

背景：

Java 面临着 GC 中断时间过长的瓶颈，无法有效利用 TB 级内存。随着 Go GC 的优化，人们不禁好奇它是否能在 TB 级内存环境下实现足够短的 GC 中断时间。

问题：

• Go 1.5 GC 是否已经准备好应对 TB 级内存？
• 是否有相关的基准测试？
• 是否可以使用一款带有 GC 的语言来管理如此庞大的内存？

答案：

要点：

• 目前，单个 Go 进程无法使用 TB 级内存。Linux 上的最大限制为 512 GB，而实际测试中最高记录仅为 240 GB。
• 在当前的后台 GC 模式下，GC 工作负载往往比 GC 中断时间更为关键。
• GC 工作负载可以用 指针数量 * 分配速率 / 剩余内存 来表示。在使用大量内存的应用中，只有指针数量较少或分配较少的应用才能保持较低的 GC 工作负载。

详细内容：

Go 堆具有 512 GB 的限制，已实际测试的最大堆大小为 240 GB。

Go 1.5 GC 旨在减少 GC 中断时间，而不是减少 GC 工作。代码在 GC 扫描堆栈和全局变量中的指针时会被中断。

根据 GopherCon 2015 演讲中的图表，1.5 GC 在拥有约 18GB 堆的 GC 基准测试中具有较短的中断时间，如图所示：

[图表：GC 中断时间与堆大小关系，显示了 1.5 版本的改进]

在实际应用中，一些原本 GC 中断时间为 300ms 的进程报告下降至 4ms 和 20ms，另一个应用报告 95th 百分位数 GC 时间从 279ms 降低至 10ms。

Go 1.6 进一步优化，将部分工作置于后台。结果是，即使堆大小超过 200GB，测试中的最大中断时间仍然为 20ms，如下图所示：

[图表：1.6 GC 时间随堆大小变化，在 180GB 附近达到 20ms]

在 1.6 版本中，堆大小约为 8GB、每分钟分配约 150M 的应用，其中断时间从 20ms 降低至 3-4ms。

Twitch 使用 Go 来运行聊天服务，他们报告说在 1.7 版本中，暂停时间已减少到 1ms，而同时运行大量协程。

1.8 将堆栈扫描移出停止世界阶段，将大多数中断时间控制在 1ms 以内，即使是在大堆内存情况下。早期测试结果表明情况良好。有时，应用程序中仍然存在使协程难以中断的代码模式，从而有效延长了所有其他线程的中断时间，但总体来说，GC 的后台工作通常比 GC 中断时间更为重要。

一般性观察：

• GC 的收集频率取决于内存使用速度。
• 每个 GC 收集完成的工作量部分取决于正在使用的指针数量。（包括切片、接口值、字符串等中的指针）

换句话说，即使应用会访问大量内存，如果指针数量较少（例如，它处理相对较少的 []byte 缓冲区），并且分配速率很低（例如，因为在最容易溢出内存的场景中应用了 sync.Pool 来重用内存），则 GC 问题可能会不存在。

因此，如果您考虑使用包含数百 GB 堆的大型计算机，并且其本质上不适合 GC，我建议您考虑以下选项：

1. 使用 C 或类似语言编写
2. 将大量数据移出对象图，例如将其管理为嵌入式数据库（如 Bolt），放入外部数据库服务中，或者如果您需要更多缓存功能而不是数据库，可以使用类似 groupcache 或 memcache 的缓存工具。
3. 运行使用较小堆的进程集，而不是一个大型进程。
4. 精心设计原型、测试和优化，以避免内存问题。

以上是Go 1.5 的垃圾收集器准备好进行 TB 级内存管理了吗？的详细内容。更多信息请关注PHP中文网其他相关文章！