Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
crypto/tls: web server leaking memory at block.reserve #28654
What version of Go are you using (
Thank you for looking into this. I can only reproduce this issue in production. I haven't seen it on my local machine. That makes it hard to debug. You need a real domain with a valid certificate to make TLS work.
Is there a Dockerfile which builds Go from scratch that I could use instead of the one from Docker Hub that I'm currently using?
I upgraded Go inside Docker to use
I assume you're just accumulating HTTP keep-alive servers and each is retaining some memory.
How many file descriptors do you have open? Paste the output of
And include output of running with environment variable
Also, you write:
r := chi.NewRouter()
Your first line of the "minimal version" includes some unspecified package.
Do you have a complete standalone repro, ideally without using external packages? But if you need the external packages, can you at least specify their imports & versions?
Here is the current graph showing the last 6 hours.
Still seeing the linear growth. Here is the current
I'm using chi for routing https://github.com/go-chi/chi. The version from my
I'm also using https://github.com/felixge/httpsnoop to capture http related metrics. It's in the critical path as you can see in the SVG above. Here is the exact version.
They are held by the
I'm also seeing this apparent memory leak on a production server, which serves HTTP/2 on TLS directly to the Internet without being behind a proxy like nginx.
It takes some time to get close to exhausting the 2GB of RAM its comtaining VM is allowed, but when that happens, top looks about like:
I tried the minimal example in the net/http docs and could not reproduce this. Its memory usage remained constant even after close to a million HTTP/2 requests, while my app goes OOM after a tiny fraction of that. Something else is going on.
In my case I'm routing with gorilla/mux and using justinas/alice for middleware handling. I'm going to try to put together a minimal example to reproduce the problem but it will take some time. At this point I do suspect the trouble might not be in the standard library after all...
It looks like you're also using the gorilla packages. I know there is a memory leak in https://github.com/gorilla/context when combining it with
Maybe @elithrar could help?
There is a discussion about releasing new versions for the gorilla packages. The maintainers don't want to break compatibility with existing code. This is a good thing. By now we have Go Modules which could help releasing a new version without breaking old import paths.