This page shows you how to set up and use Cloud 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 Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
In the Google Cloud Console, on the project selector page, select or create a Google Cloud project.
- To enable the Cloud Profiler API for your project, in the
Google Cloud Console navigation pane, click Profiler, or use the
- To open the Cloud Shell, in the Google Cloud Console toolbar, click
Activate Cloud Shell:
After a few moments, a Cloud Shell session opens inside the Google Cloud Console:
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.
If you receive a permission denied error message after starting the service, see Why am I getting a permission denied error? for possible causes.
A few moments after you start the application, Profiler displays the initial profile data. 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. When you are profiling multiple applications, you use Service to select the origin of the profiled data. 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.
To refine how the flame graph displays the profiles you've selected to analyze,
you add filters. In the previous screenshot, the filter bar
one filter. This filter option is
Metric and the filter value is
Exploring the data
Below the selection controls, the call stacks of the program are displayed in a flame graph. The flame graph represents each function with a frame. The width of the frame represents the proportion of resource consumption by that function. 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 simple, so there isn't much to
Even for a simple application, filters let you hide uninteresting frames so
that you can more clearly view interesting frames. For example, 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?
To view what is occurring outside of the application's
add a filter that hides the call stack of the
Only 0.227% of the resource consumption occurs outside of
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 Cloud Profiler, see About Cloud Profiler.
- For an introduction to profiling, see Profiling concepts.
- For detailed information on Profiler features, see Using the Cloud Profiler interface.
- Read our resources about DevOps and explore our research program.
- Profiling Go applications
- Profiling Java applications
- Profiling Node.js applications
- Profiling Python applications
- Profiling applications running outside Google Cloud