Oh, interesting call out. Thanks Brad. For some reason I assumed pprof was a more general-purpose tool written in C++. Forget where I may have read that.
On Mon, Aug 1, 2016 at 10:14 AM, Brad Fitzpatrick <bradf...@golang.org> wrote: > Note that Go's "go tool pprof" is basically just > https://github.com/google/pprof > > You can vendor that into the Docker daemon and have the server profile > itself and send the all-in-one output over the unix socket to the docker > command line tool, which users can then run and file a bug report with the > output. > > > > On Mon, Aug 1, 2016 at 10:10 AM, Nathan LeClaire < > nathan.lecla...@docker.com> wrote: > >> Hey Brad! >> >> Yes, end users. Generally, we can't make assumptions about what they >> have installed locally (e.g. Go toolchain) and I would like to provide a >> way for folks to "click a button" and get a fully symbolized profile to >> send to us. Doing this inside of an existing Go program would be ideal. >> >> On Sat, Jul 30, 2016 at 1:34 PM, Brad Fitzpatrick <bradf...@golang.org> >> wrote: >> >>> Who is your target audience for this? >>> >>> You seem to know how to do it (socat + go tool pprof), which suggests >>> you want end users to do this or something? >>> >>> >>> On Fri, Jul 29, 2016 at 3:43 PM, nathan.leclaire via golang-nuts < >>> golang-nuts@googlegroups.com> wrote: >>> >>>> 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. >>>> >>> >>> >> > -- 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.
