Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime/pprof: improve docs around short-lived processes #20202

Open
aaronjwood opened this issue May 1, 2017 · 11 comments
Open

runtime/pprof: improve docs around short-lived processes #20202

aaronjwood opened this issue May 1, 2017 · 11 comments

Comments

@aaronjwood
Copy link

@aaronjwood aaronjwood commented May 1, 2017

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

This comment has been minimized.

Copy link
Contributor

@josharian josharian commented May 1, 2017

What version of OS X?

@davecheney

This comment has been minimized.

Copy link
Contributor

@davecheney davecheney commented May 1, 2017

@aaronjwood

This comment has been minimized.

Copy link
Author

@aaronjwood aaronjwood commented May 2, 2017

@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

This comment has been minimized.

Copy link
Contributor

@davecheney davecheney commented May 2, 2017

@aaronjwood

This comment has been minimized.

Copy link
Author

@aaronjwood aaronjwood commented May 2, 2017

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

@josharian

This comment has been minimized.

Copy link
Contributor

@josharian josharian commented May 2, 2017

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

@vcabbage

This comment has been minimized.

Copy link
Member

@vcabbage vcabbage commented May 2, 2017

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

This comment has been minimized.

Copy link
Author

@aaronjwood aaronjwood commented May 2, 2017

@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

This comment has been minimized.

Copy link
Author

@aaronjwood aaronjwood commented May 2, 2017

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

@aaronjwood

This comment has been minimized.

Copy link
Author

@aaronjwood aaronjwood commented May 2, 2017

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.

@josharian josharian changed the title CPU profiling via pprof on OSX never produces data runtime/pprof: improve docs around short-lived processes May 2, 2017
@aaronjwood

This comment has been minimized.

Copy link
Author

@aaronjwood aaronjwood commented May 2, 2017

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.