runtime/pprof: improve docs around short-lived processes

[aaronjwood]

What version of Go are you using (go version)?

go version go1.8.1 darwin/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/v832043/Code"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.8.1/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.8.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/zj/hgnczfs53zg8s4_d_t686715y61ynl/T/go-build686693782=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?

Added basic CPU profiling code to main():

f, err := os.Create("test.prof")
if err != nil {
	log.Fatal(err)
}
pprof.StartCPUProfile(f)
defer pprof.StopCPUProfile()

Then I ran my program and threw a load tester at it.

What did you expect to see?

Data in test.prof after gracefully exiting my program.

What did you see instead?

After heavily loading my program with a load testing tool I made I observed that no bytes were ever written to test.prof. It seems like there is no sampling being done at all...?

[josharian]

What version of OS X?

[davecheney]

How are you exiting your program? If you ^C it the defer in main may not be able to run.

…

On Tue, 2 May 2017, 08:54 Josh Bleecher Snyder ***@***.***> wrote: What version of OS X? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#20202 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcAx5ocjTfrXTP7ye4WLZWlb6DPtgqks5r1mKpgaJpZM4NNeYm> .

[aaronjwood]

@josharian Sierra 10.12.4
@davecheney I have a signal handler in my code that catches SIGINT and SIGTERM so it should exit cleanly. It (very roughly) looks like this:

func (s *MyThing) registerShutdownHandlers() {
	sigs := make(chan os.Signal)
	signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM)
	go func() {
		<-sigs
	         // Do my stuff

		os.Exit(0)
	}()
}

[davecheney]

That's pretty much what my github.com/pkg/profile package does. Maybe try using that instead

…

On Tue, 2 May 2017, 10:37 Aaron Wood ***@***.***> wrote: @josharian <https://github.com/josharian> Sierra 10.12.4 @davecheney <https://github.com/davecheney> I have a signal handler in my code that catches SIGINT and SIGTERM so it should exit cleanly. It (very roughly) looks like this: func (s *MyThing) registerShutdownHandlers() { sigs := make(chan os.Signal) signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM) go func() { <-sigs // Do my stuff os.Exit(0) }() } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20202 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA3vWvkbEvoIEhf5NgSgy36fFl2guks5r1nrRgaJpZM4NNeYm> .

[aaronjwood]

Sure, I'll give it a shot tomorrow once I'm back at work. Is this a known issue with OS X?

[josharian]

Old versions, yes. Yours should be fine. https://research.swtch.com/macpprof

[vcabbage]

The deferred statement won't run if os.Exit(0) is used. @davecheney's package explicitly stops the profile after catching the signal but before calling os.Exit(0).
https://github.com/pkg/profile/blob/master/profile.go#L237

[aaronjwood]

@davecheney I was able to try out your suggestion just now with no luck:

defer profile.Start(profile.ProfilePath(".")).Stop()

cpu.pprof is 0 bytes after load testing the program and exiting gracefully :(

[aaronjwood]

@vcabbage you're right, I removed my signal handler and used @davecheney's package by itself and finally got some (2 KB) data.

[aaronjwood]

So basically it sounds like I need to do the same thing as what @davecheney is doing in his package if we use the builtin pprof package. Not a big deal, I just wasn't aware of this. Maybe the docs could be updated to reflect this? It seems that the docs target programs that run and exit instead of ones that run indefinitely.

[aaronjwood]

By default is everything that would go to the file 100% buffered? No writes would ever occur until the program exits? Or is it that everything is buffered until pprof.StopCPUProfile() is called? It sounds like pprof.StopCPUProfile() doesn't return until all writes are done but does that mean it also triggers a flush of everything?