Go 1.27.0 Goroutine Profile

Transcript

1. Goroutineleak Profile 第 回 Go1.27 リリースパーティ LOGOSWARE.go 1 内野 佑太郎
2. Goroutine 便利ですよね？
3. を象徴する機能でもある軽量スレッドですが... 実行開始したその Goroutine 、ちゃんと終了できていますか？ 誰も終了できない Goroutine ありませんか...？ それ Goroutineleak かもしれませんよ？ Go
4. Goroutineleak Goroutineleak のリスク はGCされない = メモリリークが起きる あるある 運用開始してから右肩上がり のメモリメトリクスで発覚
5. どのようなコードで Goroutineleak が起きるか
6. 送信されないチャネル ch := make(chan int) go func() { // val := <-ch }() 受信を待つ チャネルに何も送らず return // return
7. 無限ループ go func() { for { time.Sleep(time.Second) } }()
8. 回避例 go func() { for { select { case <-ctx.Done(): return // Context default: time.Sleep(time.Second) } } }() の終了を伝播させて抜ける
9. Goroutineleak そんなあなたに朗報 がないか心配で夜も眠れない？
10. Go1.27 Goroutineleak Profile の追加 で goroutineleak を検出できるプロファイルが正式に pprof に追加された 1.26で実装されていたが、使用するにはビルド時に GOEXPERIMENT=goroutineleakprofile を指定する必要があった 1.27
11. Goroutineleak Profile のスゴイ ところ 確実にリークしている Goroutine を検知することに重点を置いている。 ただし、偽陰性 (リークしているが検知されない) の可能性は、ある
12. 導入方法の検討
13. 手軽にプロダクト開発に取り入れるには？ 手始めに MediumTest (シナリオテスト) の最後に Goroutineleak Profile をチェッ クしてみる 理由：Goroutineを利用している箇所が Usecase や Domain といったレイヤー以 外に多かった MediumTest は CI で実行しているので異常があればすぐに検知可能
14. 実装 を import すると DefaultServeMux にエンドポイント /debug/pprof/ が追加されるので、それを利用するのが一番お手軽だが... 何かあった時に本番環境でも実行できるようにしておきたい プロファイル収集を実行しない限りオーバーヘッドはない 前述の通り、 pprof パッケージの init() 関数内でエンドポイントが追加さ れるだけ ため、限られた権限で実行できるエンドポイントとして実装してしまうことに。 _ "net/http/pprof"
15. 実装 (2) pprof.Handler を使い任意のパス階層にプロファイル取得用のエンドポイントを追加 r.Get("/pprof/{profile}", func(w http.ResponseWriter, r *http.Request) { pprof.Handler(chi.URLParam(r, "profile")).ServeHTTP(w, r) }) これで {profile} に指定したプロファイルを取得することができる MediumTest の最後にこのエンドポイントを実行して Goroutineleak をチェック
16. pprof.Handler goroutine goroutineleak allocs heap threadcreate block mutex で取得できるプロファイル - stack traces of all current goroutines - stack traces of all leaked goroutines - a sampling of all past memory allocations - a sampling of memory allocations of live objects - stack traces that led to the creation of new OS threads - stack traces that led to blocking on synchronization primitives - stack traces of holders of contended mutexes https://pkg.go.dev/runtime/pprof#Profile 追加
17. 引数なしで実行 バイナリ、 go tool pprof で開く形式でレスポンスされる。 今回のように、プロファイル取得エンドポイントに認証が必要な場合は go tool pprof {URL} で直接の呼び出しはできないが、 でダウンロードしておく # curl curl -H 'Authorization: Bearer TOKEN' -o goroutineleak.pprof \ "http://localhost/pprof/goroutineleak" # Web UI go tool pprof -http=:8080 ./goroutineleak.pprof で開く みたいに回避は可能。
18. debug=1 を指定 人が読めるテキスト形式でレスポンスされる。 件数} 1. goroutineleak profile: total { リーク件数、リーク箇所のプログラムカウンタ 3. リーク箇所の関数名、ソースファイル、ソースの行数 2. goroutineleak profile: total 3 3 @ 0x498821 0x498821 0x498821 0x498821 0x498821 # 0x100f4f2a3 main.leakfunc.func1+0x23 example.com/leak/main.go:15
19. debug=2 を指定 リークしていないものも含む全ての Goroutine のダンプが出力される。 引数なし、または debug=1 を使うケースが多いと思うので、今回は詳細割愛します
20. の動作確認 MediumTest
21. 早速リーク検知！
22. 検知されたリーク goroutineleak profile: total 1 1 @ 0x49134a 0x4696b7 0xb335e9 0x498821 # 0xb335e8 database/sql.(*DB).connectionOpener+0x88 database/sql/sql.go:1266
23. データベースコネクションのClose漏れ con, err := sql.Open("postgres", ... if err != nil { return nil, err } // ... ... // con if err != nil { // con.Close() return nil, err } 中略 生成後に何かしらのエラー ここで を実行していない！ => Goroutineleak 幸い、MediumTest実行時に正しくDBコンテナの起動待ちができていないことが原因 で、本番環境で起きる可能性は低い問題だった。
24. sql.Open() の内部実装 func OpenDB(c driver.Connector) *DB { ctx, cancel := context.WithCancel(context.Background()) db := &DB{ connector: c, openerCh: make(chan struct{}, connectionRequestQueueSize), lastPut: make(map[*driverConn]string), stop: cancel, } go db.connectionOpener(ctx) return db } database/sql 知された。 では Goroutine を使ってDBに接続しているので、そのリークが今回検
25. Goroutineleak は簡単に起こせてしまう レビューも有効ですが、Goroutine Profile を使って決定論的にチェックできるとさ らに安心ですね 今回はMediumTestに追加しましたが、検証環境等で実際に動かしているサーバーに 対して定期的にプロファイルを取得してみても良いかもしれません。 AI
26. ご清聴ありがとうございました。 アイコンは free-gophers-pack から使わせてもらっています（ライセンスは CC0）。