Hi all, I am interested in doing performance profiling on the Docker daemon using the existing pprof tools and/or code inside of the internal packages of commands, and I was hoping to get some guidance on the challenges I've encountered attempting this.
The Docker daemon (a Go program) exposes the pprof endpoints at /debug/pprof. However, by default the Docker daemon only listens on a Unix domain socket to expose its HTTP API, and exposing it over a non-encrypted TCP port is generally inadvisable due to privilege escalation concerns. The current most common method for accessing this pprof information seems to be to use socat to temporarily forward requests from the socket to a locally listening TCP port, and use go tool pprof to collect profile information and analyze it. This works OK for local development, but I have a few questions about how we might be able to expand support for collecting these pprof dumps and analyzing them more easily: 1. Would a proposal be considered to add support for collecting this information directly through go tool pprof , e.g. go tool pprof unix:///var/run/docker.sock, or is it not an area of interest for the Go tools? Some possible dilemmas include the unix:// protocol convention, which seems to be fairly Docker-unique to me and a little odd to conflate (transport layer vs. protocol) with http://. I've looked extensively at the code and it doesn't seem to cover this today. 2. Is it possible to install and use go tool pprof in a minimal manner, i.e. without the rest of the Golang toolchain? If so, how? 3. How inadvisable would it be to use the internal code for generating *Profile and symbolizing the profiles in a 3rd party program? Obviously due to the internal it's not meant to be exported but it would be very nice to be able to directly embed this type of code in a library-like fashion to be able to quickly generate dumps from running daemons that could later be loaded with rich semantic information into go tool pprof on another computer (without also needing the source binary). Naturally it's *possible* to just cp and vendor the code from the stdlib and work around this restriction, but is it advisable? 4. Any other ideas for getting a easily importable stand-alone *.pb.gz pprof output from inside of an exiting Go program (separate from the one that is being profiled)? I had an idea to make a minimal Go program (or embed in an existing one) which might be quite good at this, but getting richly annotated information (including symbols, etc.) via HTTP alone without any of the surrounding internal code to process it has proven a lot trickier than I naively assumed at first. Thanks all, and thanks of course for go tool pprof in the first place, it's a really excellent tool. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
