It used to be. It was rewritten in Go.
On Mon, Aug 1, 2016 at 10:44 AM, Nathan LeClaire <nathan.lecla...@docker.com > wrote: > 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.
