This page shows you how to set up and use Stackdriver Profiler. You will download a sample Go program, run it with profiling enabled, and then use the Profiler interface to explore the captured data.

Before you begin

  1. Sign in to your Google Account.

    If you don't already have one, sign up for a new account.

  2. In the GCP Console, go to the Manage resources page and select or create a project.

    Go to the Manage resources page

  3. Enable the Stackdriver Profiler API.

    Enable the API

Start Cloud Shell

At the top of the Google Cloud Platform Console page for your project, click the Activate Cloud Shell button:

Activate Cloud Shell

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.

Google Cloud Shell session

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/...

Profile the code

Go to the directory of sample code for Profiler in the retrieved package:

cd ~/gopath/src/github.com/GoogleCloudPlatform/golang-samples/profiler/profiler_quickstart

The 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. As the program runs, it indicates its progress with a pair of messages:

 successfully created profile CPU
 start uploading profile

The program continues to emit these messages as long as it runs.

Start the Profiler interface

In the Google Cloud Platform Console dashboard, go to Profiler:

Go to Profiler

This takes you to the Profiler interface:

Profiler interface with the sample code

The interface is divided into two general areas:

  • A control area for selecting the data to visualize.
  • A flame-graph representation of the selected data.

Selecting profiles

The interface offers an array of controls for exploring the profiling data. At the top of the interface, there are time controls, so you can examine data for the time range you choose.

Below that are options choosing 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 Google Compute Engine zones or versions of the application.

Just below the selectors for Service, Profile type and others is the filter selector. This allows you to refine how the graph displays data. In the screenshot above, there are no filters beyond the data type (CPU time), so all the CPU time data will be displayed.

Exploring the data

Below the selection controls, the selected data is displayed as a flame graph. This type of chart shows you the call stacks in the program. Each function is represented by a frame in the graph, and its relative size shows the proportion of resource consumption that function is responsible for. The top frame represents the entire program. This frame always shows 100% of the resource consumption, and it indicates how many profiles are averaged together in this graph.

The sample program does not appear to have a complicated set of call stacks; in the preceding screenshot, you see 5 frames:

Primary call stacks in the sample program

  • The gray frame represents the entire executable, which accounts for 100% of the resources being consumed.
  • The green main frame is the Go runtime.main.
  • The orange main frame is the main routine of the sample program.
  • The orange busyloop frame is a routine called from the sample's main.
  • The orange main.load frame is a routine called from the sample's main.

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, simplify the graph in other ways. The main.go application is very simple, so there's not much to filter out, but in 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 main routine, and let you see what's happening outside main. This extra work accounts for a tiny 0.29% of the resource consumption, but it makes a much more interesting flame graph:

Hiding stacks in the sample program

See Using the Profiler Interface for much more information on filtering and other ways to explore the profiling data.

What's next

Need more general information?

Ready to profile your own code? Choose your language:

Was this page helpful? Let us know how we did:

Send feedback about...

Stackdriver Profiler