Go 1.5 的垃圾收集器準備好進行 TB 級記憶體管理了嗎？

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

背景：

背景：

Java過長的瓶頸，無法有效利用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中文網其他相關文章！