A DevOps engineer is troubleshooting significant latency spikes and write request timeouts on a mission-critical database workload running on a Compute Engine VM. The VM uses an attached Persistent Disk for its primary data storage directory. During peak traffic hours, Cloud Monitoring reveals the following metrics: compute.googleapis.com/instance/disk/performance_status: Shows a steady state value of Healthy (1) Disk Queue Depth: Continuously elevated well above optimal baseline levels Disk I/O Throughput & IOPS: Flatlining at a constant ceiling despite surging database write requests Personalized Service Health (PSH): No active infrastructure incidents or zonal maintenance operations How should the DevOps engineer interpret these telemetry findings and resolve the I/O bottleneck?

Conclude that the underlying storage infrastructure is operating normally and that the workload is constrained by the disk's provisioned performance limits; resolve the bottleneck by increasing the provisioned disk capacity or migrating to a higher-tier disk type with greater IOPS and throughput caps.: ### What the `Healthy` Performance Status Indicates In Google Cloud, the `compute.googleapis.com/instance/disk/performance_status` metric reports the operational state of a Persistent Disk from Google's infrastructure perspective. A status value of **`Healthy` (value 1 / 100%)** indicates that the underlying Google Cloud storage subsystem is operating without internal infrastructure degradation, storage host failures, or ongoing maintenance interference. ### How This Diagnoses and Resolves the Bottleneck When a disk reports **`Healthy`** while simultaneously experiencing flatlined IOPS/throughput, elevated disk queue depth, and write latency spikes: - **Persistent Disk scaling model**: Standard Persistent Disk (`pd-standard`), Balanced Persistent Disk (`pd-balanced`), and SSD Persistent Disk (`pd-ssd`) scale their maximum IOPS and throughput limits linearly with the **provisioned capacity (disk size)**. - **Saturating throughput ceilings**: If an application requires 400 MiB/s of write throughput or 15,000 IOPS, but the attached disk is sized such that its calculated baseline cap is much lower, the storage driver throttles I/O operations at the VM-to-storage interface. - **Remediation**: The engineer can dynamically resize the existing Persistent Disk without downtime to scale up its baseline throughput and IOPS limits, or transition the storage architecture to **Hyperdisk** / **Extreme Persistent Disk** where IOPS and throughput can be provisioned independently of storage capacity. ### Key Capabilities and Best Practices - **Non-disruptive capacity expansion**: Resizing a Persistent Disk in Compute Engine can be done on the fly while the VM is running, allowing immediate throughput increases after resizing the partition/filesystem. - **Observability alignment**: Pairing queue depth metrics with read/write throughput charts helps pinpoint whether an issue is caused by external hardware faults or provisioned quota exhaustion. - **Service Health correlation**: Validating against Personalized Service Health (PSH) confirms that no storage platform incidents are artificially degrading volume responsiveness. ### Why This Is Optimal This approach directly targets the root cause of the storage bottleneck. Rather than treating the symptom as an infrastructure failure or misdirected OS error, resizing or re-tiering the disk provides the required I/O bandwidth to clear the elevated queue depth.

Troubleshoot Persistent Disk Performance Status Healthy | Professional Cloud DevOps Engineer

Troubleshoot Persistent Disk Performance Status Healthy

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A DevOps engineer is troubleshooting significant latency spikes and write request timeouts on a mission-critical database workload running on a Compute Engine VM. The VM uses an attached Persistent Disk for its primary data storage directory.

During peak traffic hours, Cloud Monitoring reveals the following metrics:

compute.googleapis.com/instance/disk/performance_status: Shows a steady state value of Healthy (1)
Disk Queue Depth: Continuously elevated well above optimal baseline levels
Disk I/O Throughput & IOPS: Flatlining at a constant ceiling despite surging database write requests
Personalized Service Health (PSH): No active infrastructure incidents or zonal maintenance operations

How should the DevOps engineer interpret these telemetry findings and resolve the I/O bottleneck?

Conclude that the Persistent Disk metric is reporting a false positive because the underlying storage cluster is experiencing severe contention; file a priority support ticket to request an immediate manual live migration of the storage volume.

Conclude that the underlying storage infrastructure is operating normally and that the workload is constrained by the disk's provisioned performance limits; resolve the bottleneck by increasing the provisioned disk capacity or migrating to a higher-tier disk type with greater IOPS and throughput caps.

Conclude that the guest operating system filesystem has encountered severe metadata corruption; reboot the VM instance into single-user recovery mode to execute an offline non-interactive fsck repair.

Conclude that the VM instance has experienced network packet loss across its replication channel; terminate disk replication, unmount the volume, and force-attach it to a standby instance in an alternate zone.

Professional Cloud DevOps Engineer

Troubleshoot Persistent Disk Performance Status Healthy

Related questions