GCにおけるパフォーマンス改善

https://gocon.jp/2023/sessions/LT1/

Transcript

1. GCにおけるパフォーマンス改善
2. 自己紹介 Toyohito Murooka 室岡 豊人 株式会社SpeeeにてUZOUという広告配信システムの開発に従事 https://twitter.com/muroon01 https://github.com/muroon
3. Goの広告配信アプリを1.17 ⇒ 1.19 を上げたときの結果 CPU負荷は変わらず、メモリ使用量を抑えられた 負荷試験の結果
4. Goの広告配信アプリを1.17 ⇒ 1.19 を上げたときの結果 レイテンシも変化なし 負荷試験の結果
5. アプリの設定 • GOMEMLIMITは未設定 (runtime/debug.SetMemoryLimitも不使用) • GOGCはデフォルト値 (=100) • 意図的にruntime.GC()も使用していない 特にチューニングすることなくても レイテンシもCPU負荷も上げることなく、メモリ使用量が減少している
6. どんなサービス UZOUというメディアに関連する記事や広告を配信するネイティブアド配信プラットフォーム 2016年からサービスを開始しており 7年目のプロダクト
7. システム構成
8. アプリについて • 事前にデータ更新しておいてランタ イム処理のリソースアクセスはオン メモリとKVSへのReadのみ • Write処理は非同期で実施
9. アプリについて Goのバージョンアップ時の使用パッケージのバージョンのアップグレード • 基本的にはlatestのバージョンにアップグレード • ただし、一部のパッケージは別途個別にアップグレードを実施 ◦ メジャーアップグレードによる改修コストが大きく、現行バージョンにおけるEOL に余裕があるもの ◦ リソース側のバージョンを上げないと、Goのクライアントパッケージのバージョ ンがlatestにはアップグレードできないもの
10. 1.18と1.19におけるGC関連の変更 • 1.18における追加機能 ◦ GCの実行頻度決定にスタック スキャンなどの非ヒープソースが含まれ、 オーバーヘッドの予測制 度がより向上 • 1.19での追加機能 ◦ Soft Memory Limitが導入 ▪ Goのヒープとランタイムによって管理されるすべてのメモリにおいてソフトメモリ制限をサポー ト ▪ 下記に代表されるの外部メモリリソースは対象外 1. バイナリ自体のマッピング 2. 他の言語で管理されるメモリ 3. OSによって保持されるメモリ ▪ runtime/debug.SetMemoryLimitまたはGOMEMLIMIT環境変数を介して管理可能 ▪ GOGC=off時でも当設定は有効
11. GOのGCのGuide ドキュメントが公開 https://go.dev/doc/gc-guide
12. GOのGCのGuide https://go.dev/doc/gc-guide Goのガベージコレクタの役割と仕組 み Goのガベージコレクタは、自動的にメモリを管理し、必要に応じて割り当てとリサイクルを行う Goの値の生存場所 Goの値のメモリは、コンパイラが寿命を決定できない場合、ヒープにエスケープする。ガベージコレクタは、この動的メ モリ割り当てを特定し、クリーンアップする トレースガベージコレクション ガベージコレクションは、自動的にメモリをリサイクルする多くの異なる方法を指すことができる。このドキュメントの文 脈では、ガベージコレクションはトレースガベージコレクションを指し、ポインタを逐次的に追跡することで使用中のオブ ジェクトを特定する GCサイクル GoのGCはマーク-スイープGCであるため、大まかにはマークフェーズとスイープフェーズの 2つのフェーズで動作す る。これらのフェーズは、 GCがオフの状態と交互に回転し、これを GCサイクルと呼ぶ コストの理解 GCは、CPU時間と物理メモリという 2つのリソースを使用する。 GCのメモリコストは、前の GCサイクルで生存していた ヒープメモリ、マークフェーズ前に割り当てられた新しいヒープメモリ、そしてメタデータのスペース（これは前のコストに 比例するが、比較的小さい）から成る。 GCのCPUコストは、サイクルごとの固定コストと、生存ヒープのサイズに比例し てスケールするマージナルコストとしてモデル化される。
13. GOのGCのGuide https://go.dev/doc/gc-guide GOGC GOGCは、GCのCPUとメモリのトレードオフを決定 。各GCサイクル後のターゲットヒープサイズ、つまり次のサイクル での合計ヒープサイズのターゲット値を決定する。 GCの目標は、合計ヒープサイズがターゲットヒープサイズを超える 前に、コレクションサイクルを終了することである メモリ制限 Go 1.19で、ランタイムメモリをソフトに制限する方法が追加 された。従来から存在した GOGCはトレードオフを設定す るためには優れていたが、 利用可能なメモリが有限であるという事実を考慮 に入れていなかったため。ただしこの制 限はソフトリミットであり、必ずしもメモリ使用量を設定値以下に保証するものではない。 (強固なメモリ制限の結果、 GCに時間がかかりすぎてスラッシングが起きるのを避ける ) レイテンシ GoのGCはCPU時間を使用し、その動作頻度は GOGCパラメータで制御される。 GOGCが高ければCPU使用率は 低く、メモリ使用量は増加する 。逆にGOGCが低ければCPU使用率は高く、メモリ使用量は減少する 仮想メモリについて 物理メモリが不足しディスクが使用されるスワップアウトを極力避けるように、 GoのGCはメモリ使用量が物理メモリ容 量に近づくと頻繁に実行される
14. GOGC GC使用時のCPUとメモリのトレードオフを決定する環境変数 GOGCの値を高く設定すれば、CPU使用率は低く(結果レイテンシも低く )、メモリ使用量は増加する
15. GOGC 値が100(デフォルト値)の場合、 GC完了後のheapサイズ①にプラス100%(トータル200%)のheapサイズが使用されたら GCを実行する
16. メモリ制限 ピークのメモリがどれくらいかを設定できる (1.19から導入される)
17. メモリ制限 GOGCのみの設定だとヒープスパイクが発生時にピークメモリ使用量が急激に大きくなることを警戒 ただしこの制限はソフトリミットであり、必ずしもメモリ使用量を設定値以下に保証するものではない (強固なメモリ制限の結果、 GCに時間がかかりすぎてスラッシングが起きるのを避ける )
18. GoのGCの歴史 Go 1.4以前 単純なStop The World (STW) GC Go 1.5・1.6 新たなGCアルゴリズムが導入され、レイテンシが大きく改善された 将来のハードウェアが GCのスループットを改善することを見据えて スループットよりレイテンシを重視 Go 1.18 GCの実行頻度決定に非ヒープソースが含まれ、オーバーヘッドの予測制度がより向上 Go 1.19 Soft Memory Limitが導入
19. まとめ 従来GoのGCはレイテンシ重視と言われているだが、メモリ使用もなるべく抑えられるこ とを目指している模様 • Soft Memory Limit導入によりチューニングをより細かく設定する機能を提供 • 未チューニングでもGCがより効果的に動作する可能性あり （注意：1.19での弊社アプリでの検証結果による）
20. 参考資料 https://tip.golang.org/doc/go1.18 https://tip.golang.org/doc/go1.19 https://go.dev/doc/gc-guide https://go.dev/blog/go15gc https://speakerdeck.com/uji/gofalsegc-garbage-collector-nituiteli-jie-suru https://deeeet.com/writing/2016/05/08/gogc-2016/ https://speakerdeck.com/taxio/go-gc-algorithm-101