Context
An E2 shared-core VM can show multiple vCPUs inside the guest while having a smaller sustained CPU entitlement than that visible count suggests. A short benchmark may also benefit from temporary bursting. Size the service using sustained useful work and latency rather than the fastest few seconds after an idle period.
Read the machine type's CPU model
Google documents shared-core E2 types as time-sharing physical CPU with a defined sustained allocation and periodic bursting behavior. The guest's visible vCPU count is therefore not a standalone statement of continuous physical CPU capacity.
Record the exact machine type, memory, operating system, architecture, and relevant placement context. Distinguish shared-core types from standard E2 configurations. A recommendation that is sensible for one small shared-core instance should not be generalized to the entire E2 family.
Avoid importing an AWS CPU-credit interpretation into this platform. Use Google Cloud's actual entitlement and bursting model, metrics, and billing documentation. Similar symptoms across providers do not imply identical controls or accounting.
Measure beyond the initial burst
Run a repeatable workload long enough to observe sustained behavior after an idle start. Record request throughput, queue depth, percentile latency, process CPU, guest scheduling evidence, and the provider's CPU metrics over the same interval.
Normalize CPU percentages carefully. A graph reporting average utilization across visible vCPUs and a process reporting one busy thread can use different denominators. Write down what each percentage represents before comparing it with the machine's sustained allocation.
Test both steady demand and the real traffic pattern. An intermittently used administrative application may fit a shared-core model well, while a continuously busy API or background processor may not. The correct comparison is against the service's deadline and cost per accepted task.
Separate CPU entitlement from other delays
A single-threaded application can be limited by one execution path even on a larger VM. A database wait, remote service call, or storage queue can make the application slow without exhausting CPU. Profile the actual request path before attributing every delay to shared-core behavior.
Capture workload schedules. Compression, log processing, vulnerability scanning, and package jobs can consume the same limited sustained capacity as customer requests. A server that is mostly idle in a daily average can still be overloaded during the critical business hour.
Do not fix this by unbounded worker creation. Extra runnable workers can increase queueing and memory use without adding CPU time. Use bounded concurrency and explicit admission or queueing behavior while testing a capacity change.
An illustrative misleading benchmark
A startup tests a small API immediately after deployment. The short run looks fast, so the same VM size is selected for continuous production traffic. After sustained work, request queues grow and response times exceed the accepted target.
The team repeats the test with the real request mix, a longer duration, and the scheduled worker active. A configuration with suitable sustained capacity produces more accepted requests within the deadline. It compares total monthly usage under current regional prices rather than treating the smallest hourly VM as automatically cheapest.
Quick diagnostic map
| Evidence | Hypothesis | Next check |
|---|---|---|
| Fast after idle; slower under steady load | Burst versus entitlement | Long-duration controlled run |
| One thread busy; others quiet | Serial application work | Request profile and parallelism |
| Slow only during a scheduled job | Shared capacity conflict | Job timeline and bounded concurrency |
| CPU modest; remote spans dominate | Dependency delay | Database, network, and storage timing |
A focused operator exercise
Choose a fixed input dataset and a latency acceptance target. Run three phases: an idle-start burst, a sustained load, and the expected mixed workload with background jobs. Keep application version and data identical and count failed or timed-out requests separately.
Compare an appropriate alternative machine configuration using the same phases. Verify results and record throughput after the initial burst period. Include memory headroom, restart requirements, and cost assumptions in the decision. A benchmark receipt should name the exact type and duration so a later reader knows what was actually established.
Keep capacity decisions observable
Track queue delay and customer latency alongside utilization. A service can appear cheap while accumulating work it cannot finish on time. Revisit the choice after a traffic or software change and keep the intended machine type in reviewed provisioning configuration.
Frequently asked questions
Does the guest's vCPU count equal sustained shared-core CPU capacity?
Not by itself. Read the exact machine type's documented entitlement and bursting model.
Are shared-core VMs unsuitable for production?
They can suit intermittent workloads. Validate sustained demand, peak behavior, memory, recovery needs, and the service's actual latency contract.
Continue the investigation
- Cloud Run Concurrency: Diagnose a Busy Single Thread
- Investigate performance from the first response.
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Cloud Cost Optimization to discuss implementation, validation and operational handover.
Technical reference
General-purpose machine family for Compute Engine | Google Cloud Documentation
Machine families resource and comparison guide | Compute Engine | Google Cloud Documentation