| --- |
| title: CustomPprofProfiles |
| --- |
| |
| Originally published at https://rakyll.org/custom-profiles/. |
| |
| ---- |
| |
| Go provides several pprof profiles out of the box to gather |
| profiling data from Go programs. |
| |
| The builtin profiles provided by the [runtime/pprof](https://pkg.go.dev/runtime/pprof/) package: |
| |
| * **profile**: CPU profile determines where a program spends its time while actively consuming CPU cycles (as opposed while sleeping or waiting for I/O). |
| * **heap**: Heap profile reports the currently live allocations; used to monitor current memory usage or check for memory leaks. |
| * **threadcreate**: Thread creation profile reports the sections of the program that lead the creation of new OS threads. |
| * **goroutine**: Goroutine profile report the stack traces of all current goroutines. |
| * **block**: Block profile show where goroutines block waiting on synchronization primitives (including timer channels). Block profile is not enabled by default; use runtime.SetBlockProfileRate to enable it. |
| * **mutex**: Mutex profile reports the lock contentions. When you think your CPU is not fully utilized due to a mutex contention, use this profile. Mutex profile is not enabled by default, see runtime.SetMutexProfileFraction to enable. |
| |
| Additional to the builtin profiles, [runtime/pprof](https://pkg.go.dev/runtime/pprof/) package allows you to export your custom profiles, and instrument your code to record |
| execution stacks that contributes to this profile. |
| |
| Imagine we have a blob server, and we are writing a Go client for it. And our users want to be able to profile the opened blobs on the client. We can create a profile and record the events of blob opening and closing, so the user can tell how many open blobs they are at any time. |
| |
| Here is a blobstore package that allows you to open some blobs. We will create a new custom profile and start |
| recording execution stacks that contributes to opening of blobs: |
| |
| ``` go |
| package blobstore |
| |
| import "runtime/pprof" |
| |
| var openBlobProfile = pprof.NewProfile("blobstore.Open") |
| |
| // Open opens a blob, all opened blobs need |
| // to be closed when no longer in use. |
| func Open(name string) (*Blob, error) { |
| blob := &Blob{name: name} |
| // TODO: Initialize the blob... |
| |
| openBlobProfile.Add(blob, 2) // add the current execution stack to the profile |
| return blob, nil |
| } |
| ``` |
| |
| And once users want to close the blob, we need to remove the execution stack associated with the current blob from the profile: |
| |
| ```go |
| // Close closes the blob and frees the |
| // underlying resources. |
| func (b *Blob) Close() error { |
| // TODO: Free other resources. |
| openBlobProfile.Remove(b) |
| return nil |
| } |
| ``` |
| |
| And now, from the programs using this package, we should be able to retrieve `blobstore.Open` profile data and use our daily pprof tools to examine and visualize them. |
| |
| Let's write a small main program than opens some blobs: |
| |
| ``` |
| package main |
| |
| import ( |
| "fmt" |
| "math/rand" |
| "net/http" |
| _ "net/http/pprof" // as a side effect, registers the pprof endpoints. |
| "time" |
| |
| "myproject.org/blobstore" |
| ) |
| |
| func main() { |
| for i := 0; i < 1000; i++ { |
| name := fmt.Sprintf("task-blob-%d", i) |
| go func() { |
| b, err := blobstore.Open(name) |
| if err != nil { |
| // TODO: Handle error. |
| } |
| defer b.Close() |
| |
| // TODO: Perform some work, write to the blob. |
| }() |
| } |
| http.ListenAndServe("localhost:8888", nil) |
| } |
| ``` |
| |
| Start the server, then use go tool to read and visualize the profile data: |
| |
| ``` |
| $ go tool pprof http://localhost:8888/debug/pprof/blobstore.Open |
| (pprof) top |
| Showing nodes accounting for 800, 100% of 800 total |
| flat flat% sum% cum cum% |
| 800 100% 100% 800 100% main.main.func1 /Users/jbd/src/hello/main.go |
| ``` |
| |
| You will see that there are 800 open blobs and all openings are coming from main.main.func1. In this small example, there is nothing more to see, but in a complex server you can examine the hottest spots that works with an open blob and find out bottlenecks or leaks. |