使用太字节RAM的速度有多快1.5 gc？

Question

Java不能使用太字节RAM,因为GC暂停时间太长(几分钟).随着Go GC的最新更新,我想知道它的GC暂停是否足够短,可以使用大量的RAM,例如几兆兆字节.

这有什么基准吗？我们现在可以使用垃圾收集语言吗？

Answer 1

tl;博士:

• 您现在无法在单个Go进程中使用TB的RAM.Linux上的Max是512 GB,我见过的大多数都是240 GB.
• 使用当前的背景GC,GC 工作负载往往比GC 暂停更重要.
• 您可以将GC工作负载理解为指针*分配率/备用RAM.在使用大量RAM的应用程序中,只有指针少或分配少的应用程序才会具有较低的GC工作负载.

我同意inf的意见,认为巨大的堆值得向其他人询问(或测试).JimB指出,Go堆目前的硬限制为512 GB,18 240 GB是我见过的最多.

我们从设计文档和GopherCon 2015幻灯片中了解了一些关于巨大堆的内容:

• 1.5收集器的目的不是削减GC 工作,只是通过在后台工作来减少暂停.
• 当GC扫描堆栈上的指针和全局变量时,代码暂停.

• 1.5 GC在GC基准测试中有一个短暂的暂停,大约有18GB的堆,如GopherCon讲话中该图底部最右边的黄点所示:

  

跑了几个生产应用程序,最初有300ms左右的停顿乡亲报道滴〜4毫秒和〜20毫秒.另一个应用程序报告他们的第95百分位GC时间从279ms到~10ms.

去1.6 添加抛光并将一些剩余的工作推到后台.因此,测试堆积高达200GB以上仍然可以看到最大暂停时间为20ms,如2016年初状态下的幻灯片所示:

具有20ms暂停时间低于1.5的相同应用程序在1.6下有3-4ms暂停,大约8GB堆和150M分配/分钟.

使用Go进行聊天服务的Twitch报告称,Go 1.7的暂停时间已减少到1毫秒,并且运行了大量的goroutine.

1.8 将堆栈扫描带出了世界末日阶段,大多数暂停时间不到1毫秒,即使在大堆上也是如此.早期数字看起来不错.有时,应用程序仍然具有使goroutine难以暂停的代码模式,有效地延长了所有其他线程的暂停,但通常可以说GC的后台工作现在通常比GC 暂停更重要.

关于垃圾收集的一些一般性观察,不是特定于Go:

• 收集的频率取决于您使用您愿意为该过程提供的RAM的速度.
• 该工作量每个集合确实在一定程度上取决于有多少指针都在使用.(包括切片内的指针,接口值,字符串等)

换句话说,访问大量内存的应用程序可能仍然没有GC问题,如果它只有几个指针(例如,它处理相对较少的大[]byte缓冲区),并且如果分配率较低(例如,因为您应用了sync.Pool无论你在哪里咀嚼RAM最快,都要重用内存.

所以,如果你正在寻找一些涉及数百GB的内容,这些内容对GC来说并不自然,那么我建议你考虑一下

1. 用C语言写作
2. 将庞大的数据移出对象图.例如,您可以管理嵌入式数据库中的数据,例如bolt,将其放在外部数据库服务中,或者groupcache如果您需要更多缓存而不是数据库,则使用类似内存或内存缓存的内容
3. 运行一组较小堆的进程而不是一个大进程
4. 只需仔细进行原型设计,测试和优化,以避免内存问题.