Context
A larger Persistent Disk can still feel slow when attached to a VM that cannot drive its performance. Compute Engine disk planning involves the disk type and capacity, the machine series and vCPU count, and the application's I/O behavior. Evaluate these limits together before treating disk size as the only performance control.
Establish which storage product is attached
Record whether the workload uses a Persistent Disk type, Hyperdisk, or another storage product. Their performance models differ. This guide focuses on Persistent Disk; do not apply its capacity-linked performance assumptions to a separately provisioned performance model without checking the matching documentation.
Inventory every relevant disk, its size, zone or region scope, attachment mode, and the VM machine type. Identify which device and filesystem hold the application's data, logs, and temporary work. A benchmark against the boot disk will not explain a bottleneck on a separate data volume.
Compare disk entitlement with the VM ceiling
Google documents Persistent Disk performance as depending on disk type and size as well as the attached VM's machine type and vCPU count. The achievable result is constrained by the applicable disk and VM limits, along with the workload.
Review aggregate behavior when several disks of the same type are attached. Do not add every advertised per-disk maximum and assume the VM can deliver their sum. Also keep read and write behavior distinct where the documented limits differ.
Use the current machine-series tables for the selected configuration. A maximum quoted for a large machine in one series is not a promise for a small VM in another. Document the actual configuration beside every target number.
Describe I/O before changing capacity
Measure read/write mix, operation size, concurrency, queueing, throughput, and completion latency. A small random-read workload can be operation-bound while a streaming task is byte-bound. A synchronous application can submit too little parallel work to approach either documented maximum.
Correlate guest iostat observations with provider metrics and application spans over the same interval. A slow database request may be waiting on a lock or CPU even when storage activity happens nearby. Establish a causal experiment rather than assigning all latency to the busiest-looking graph.
Include filesystem, encryption, and caching context in comparisons. A warm-cache read and a first read from a restored environment are different workloads. Record initialization state and data correctness when testing recovery-related performance.
An illustrative stalled resize
A team doubles a Persistent Disk's size to improve a reporting job. The job remains slow because the small VM's applicable performance limit is already lower than the disk's new capability. A second attached volume also competes during the backup window.
The team compares a suitable VM configuration using the same dataset and read pattern. It measures the full reporting and backup overlap, then selects the least expensive configuration that meets both deadlines. The accepted change is supported by completed work and latency, not only by a larger theoretical disk number.
Quick diagnostic map
| Evidence | Boundary to test | Next check |
|---|---|---|
| Disk enlarged; performance unchanged | VM limit or another bottleneck | Machine-series performance table |
| High operations; modest bytes | Small-I/O pressure | Operation size and IOPS entitlement |
| Multiple disks slow together | Shared VM constraint | Aggregate activity |
| Low device queue; task remains slow | Application serialization | Profile and dependency timing |
A focused operator exercise
Create a disposable environment with a representative dataset and the production disk type. Record the exact VM, disk sizes, filesystem, and test profile. Use non-destructive, bounded tests against test data and verify the output.
Compare one disk or VM change at a time. Include enough duration to observe steady behavior and repeat the expected competing workload. Capture application completion, queueing, and provider metrics. Preserve the previous configuration and the cost assumptions so the result can be reviewed without rerunning an uncontrolled benchmark.
Validate the operational tradeoff
A VM resize can affect compute cost, restart requirements, quotas, and placement availability. A disk change can affect storage cost and future recovery time. Include those consequences in the change plan instead of presenting performance as an isolated slider.
After rollout, observe a full business cycle and the backup window. Set alerts around useful workload symptoms and capacity headroom rather than a universal disk-utilization percentage.
Frequently asked questions
Does more disk capacity always improve Persistent Disk performance?
It can raise a disk's applicable entitlement, but the VM and workload can remain limiting. Check both sides before resizing.
Can Hyperdisk be tuned using the same assumptions?
Use its own documented performance model. Identify the actual storage product before applying a tuning procedure.
Continue the investigation
- Compute Engine Snapshot Restores: Validate the Application, Not the Disk
- Linux Iowait: Connect CPU Accounting to Storage Evidence
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix NAS, SAN & File Server Infrastructure to discuss implementation, validation and operational handover.
Technical reference
Persistent Disk performance overview | Compute Engine | Google Cloud Documentation
Optimize Persistent Disk performance | Compute Engine | Google Cloud Documentation