Will Cloud Profiler catch a CPU spike that lasts less than a second?

Maybe, but it's not guaranteed. The agent profiles for a bounded duration (default ~10s) once per collection interval (default ~60s), so a spike that falls entirely inside one of the roughly 50-second gaps between collection windows won't be captured at all. For catching short, rare spikes reliably, you'd need continuous profiling coverage or a different tool, Profiler is built for finding sustained hot paths under typical load, not transient one-off events.

What does the heap profiling sampling rate actually control?

It's the average number of bytes allocated between each recorded sample, not a sample count or a time interval. A lower value (fewer bytes between samples) means more samples and better resolution on where memory is going, at the cost of more overhead on every allocation; it's directly analogous to a statistical sampling profiler's rate, just denominated in bytes instead of time.

Does profiling one version affect the metrics of another version running in parallel?

No, as long as serviceVersion is set distinctly for each, Profiler segments data by service + version, so a canary running v2.2.0 alongside stable v2.1.0 shows up as two separate comparable profile sets in the UI rather than blended together, which is the entire point of tagging deploys with a real version string.

GCP Cloud Profiler Config Builder

MonitoringGCP

Build Cloud Profiler agent configurations with CPU, heap, and contention profiling settings.

Cloud Profiler Configuration

Build Cloud Profiler agent configurations with CPU, heap, and contention profiling settings and collection intervals.

Required Fields

projectIdserviceserviceVersionprofilerConfig.profileTypes

Generated Output

Output will appear here...

See It in Action

A backend team suspects a slow memory leak in a service that gets restarted nightly anyway, so it's never triggered an OOM alert, but response latency creeps up hour over hour before each restart. Default heap sampling at 512KB intervals shows a vague upward trend but not enough resolution to identify which allocation site is responsible. They use the builder to temporarily lower heapProfiling.samplingRate to 128KB for a focused investigation window, redeploy to a canary instance, and the finer-grained heap profile clearly attributes the growth to an unbounded in-memory cache that was missing an eviction policy.

What This Tool Does

Build a Cloud Profiler agent configuration covering which profile types to collect (CPU, HEAP, THREADS, CONTENTION, WALL) and their sampling parameters. heapProfiling.samplingRate is the average byte interval between allocation samples (the 524288 default means roughly one sample per 512KB allocated, not a fixed number of samples per second), so lowering it increases both profiling accuracy and overhead, a real memory-bandwidth tradeoff rather than a free knob. The agent wakes on a collection interval (default around 60s) and captures for a bounded duration (default around 10s) rather than continuously profiling, which is why CPU profiler output is naturally sampled and won't catch a spike that happens entirely between collection windows.

Technical Details

The builder requires projectId, service, serviceVersion, and profilerConfig.profileTypes to resolve, the fields the Profiler agent needs to correctly attribute and segment collected profiles; the collection interval, backoff, and per-profile-type sampling parameters are validated as well-formed JSON but their tuning is a real tradeoff between overhead and resolution that's on you to make.

Common Use Cases

1Lowering heapProfiling.samplingRate below the 524288-byte default to catch a suspected memory leak with finer granularity, temporarily, since the extra sampling frequency adds measurable allocation overhead.
2Grouping profile data correctly across a canary rollout by setting serviceVersion distinctly per deploy, so the Profiler UI can compare v2.1.0's CPU profile against the previous version instead of merging them together.
3Enabling CONTENTION profiling specifically after a suspected lock-contention issue where CPU profiling alone shows threads as busy without revealing they're mostly blocked waiting on a mutex.
4Setting deploymentLabels for cluster and namespace so profiles from a multi-tenant GKE cluster can be filtered down to just the service under investigation instead of a mixed pool.

Common Questions

Will Cloud Profiler catch a CPU spike that lasts less than a second?: Maybe, but it's not guaranteed. The agent profiles for a bounded duration (default ~10s) once per collection interval (default ~60s), so a spike that falls entirely inside one of the roughly 50-second gaps between collection windows won't be captured at all. For catching short, rare spikes reliably, you'd need continuous profiling coverage or a different tool, Profiler is built for finding sustained hot paths under typical load, not transient one-off events.
What does the heap profiling sampling rate actually control?: It's the average number of bytes allocated between each recorded sample, not a sample count or a time interval. A lower value (fewer bytes between samples) means more samples and better resolution on where memory is going, at the cost of more overhead on every allocation; it's directly analogous to a statistical sampling profiler's rate, just denominated in bytes instead of time.
Does profiling one version affect the metrics of another version running in parallel?: No, as long as serviceVersion is set distinctly for each, Profiler segments data by service + version, so a canary running v2.2.0 alongside stable v2.1.0 shows up as two separate comparable profile sets in the UI rather than blended together, which is the entire point of tagging deploys with a real version string.

Expert Tips

TIP

Continuous profiling retention (retentionDays) only controls how long historical profiles are kept for comparison, it doesn't mean the agent profiles continuously, collection is still windowed per collectionInterval regardless of retention settings.

TIP

A missing or reused serviceVersion across genuinely different deploys merges their profile data in the UI, making before/after comparisons across a deploy meaningless, always bump the version string on every build that changes code, not just on major releases.

TIP

Allocation profiling overhead scales with allocation rate, not request rate — a service doing heavy short-lived object churn per request pays more profiling tax than a request-count-equivalent service with lean allocation patterns, budget for that when deciding whether to enable it in production.

Related Learning Guides

Firestore Data Modeling26 min read
Cost Optimization Guide24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.