This page shows you how to set up and use Stackdriver Profiler. You download a sample Go program, run it with profiling enabled, and then use the Profiler interface to explore the captured data.
Before you begin
Sign in to your Google Account.
If you don't already have one, sign up for a new account.
In the GCP Console, go to the Manage resources page and select or create a project.
- Enable the Stackdriver Profiler API.
Start Cloud Shell
At the top of the Google Cloud Platform Console page for your project, click the Activate Cloud Shell button:
A Cloud Shell session opens inside a new frame at the bottom of the console and displays a command-line prompt. It can take a few seconds for the shell session to be initialized.
Get a program to profile
The sample program,
main.go, is in the
golang-samples repository on
GitHub. To get it, retrieve the package of Go samples:
go get -u github.com/GoogleCloudPlatform/golang-samples/profiler/...
The package retrieval takes a few moments to complete.
Profile the code
Go to the directory of sample code for Profiler in the retrieved package:
main.go program creates a CPU-intensive workload to provide data to
the profiler. Start the program and leave it running:
go run main.go
This program is designed to load the CPU as it runs. It is configured to use Profiler, which collects profiling data from the program as it runs and periodically saves it.
After you start the program, you see the
profiler has started message
in a few seconds. In about a minute, two more messages are displayed:
successfully created profile CPU start uploading profile
These messages indicate that a profile was created and uploaded to your Cloud Storage project. The program continues to emit the last two messages, about one time per minute, for as long as it runs.
Start the Profiler interface
To go to the Profiler interface, select Profiler from the Google Cloud Platform Console dashboard:
The interface offers an array of controls and a flame graph for exploring the profiling data:
Below the time controls are options that let you choose the set of profile data to use. Service is for selecting the origin of the profiled data, useful if you are profiling several different applications. Profile type lets you choose the kind of profile data to display. Zone name and Version let you restrict display to data from Compute Engine zones or versions of the application. Weight lets you select profiles captured during peak resource consumption.
Just below the selectors for Service, Profile type and others is the
filter selector. Filters let you to refine how the flame graph displays data.
In the previous screenshot, there is a
Metric filter for the
Because there are no other filters, all of the CPU time data is displayed.
Exploring the data
Below the selection controls, the call stacks of the program are displayed in a flame graph. Each function is represented by a frame in the graph. The proportion of resource consumption by that function is represented by the width of the frame. The top frame represents the entire program. This frame always shows 100% of the resource consumption. This frame also lists how many profiles are averaged together in this graph.
The sample program doesn't have a complicated set of call stacks; in the preceding screenshot, you see 5 frames:
- The gray frame represents the entire executable, which accounts for 100% of the resources being consumed.
- The green
mainframe is the Go
- The orange
mainframe is the
mainroutine of the sample program.
- The orange
busyloopframe is a routine called from the sample's
- The orange
main.loadframe is a routine called from the sample's
The filter selector lets you do things like filter out functions that match
some name. For example, if there is a standard library of utility functions,
you can remove them from the graph. You can also remove call stacks
originating at a certain method or simplify the graph in other ways.
main.go application is very simple, so there isn't much to
filter out. For a complex application, being able to remove elements
from the graph is very useful.
In the profiling screenshot for the sample code, the gray frame is slightly
larger than the first
main frame under it. Why? Is there something else
going on that's not immediately apparent because the
main call stack
consumes such an overwhelming percentage of the resources?
You can use a filter to hide the call stack from the
and let you see what's happening outside
main. This extra work accounts
for a tiny 0.227% of the resource consumption, but it makes a much more
interesting flame graph:
See Using the Profiler interface for much more information on filtering and other ways to explore the profiling data.
Need more general information?
- For an overview of Stackdriver Profiler, see About Stackdriver Profiler.
- For an introduction to profiling, see Profiling concepts.
- For detailed information on Profiler features, see Using the Stackdriver Profiler interface.
Ready to profile your own code? Choose your language: