About Persistent Disk performance (original) (raw)

Skip to main content

• Documentation

  • Guides
  • Reference
  • Samples
  • Resources

• Technology areas

• Cross-product tools

• Related sites

• Console

• Contact Us

• Start free

• Discover

• Product overview

• Compute Engine instances

• Instance groups

• Get started

• Plan and prepare

  • Networking overview for VMs
  • Images and operating systems
  • Access control
    * Access control overview
    * Manage access to Compute Engine resources
    * Manage resources by using custom constraints
    * IAM roles and permissions
    * Service accounts
  • Name resources

• Create instances

• Instance creation overview

• Migrate VMs

• Choose a migration path

• Bring your own licenses

• Move an existing VM to a new VM

• Connect to VMs

• Connect to a VM

  • About SSH connections
  • Linux VMs
    * Connect to VMs
    * Connect as the root user
    * Connect using service accounts
    * Configure apps to use SSH
  • Windows VMs
    * Connect to Windows VMs using RDP
    * Connect to a Windows VM's SAC
    * Connect to Windows VMs using SSH
    * Connect to Windows VMs using PowerShell

• Manage access to VMs

  • Linux VMs
    * Choose an access management method
    * About OS Login
    * Set up OS Login
    * Enable security keys with OS Login
    * Manage OS Login in an organization
    * Monitor OS Login audit logs
    * Configure granular access within VMs
  • Manage tags for resources

• IP addresses

• Create a PTR record for a VM

• Verify VM identity

• Manage storage

• Choose a disk type

• Configure disks

  • Add disks to VMs
    * Add disks from a storage pool to VMs
    * Create a VM with Local SSD disks
    * Create a VM with additional non-boot disks
    * Create a new Hyperdisk
    * Create a new Persistent Disk
    * Share a disk between VMs
    * Attach a disk to a VM
    * Mount in-memory RAM disks

• Make disks highly available

• Back up and restore

• Data protection options

• Configure the default backup setting

• Recover a VM with a corrupted or full disk

• Manage VMs

• Basic operations and lifecycle

  • VM instance lifecycle
  • View VM properties
    * Detect if a VM is running in Compute Engine
    * Get a list of VMs
    * Get the details of a VM
    * Get the UUID of a VM
    * View the source image of a VM
    * View referrers to VMs
    * View network configuration of an instance
    * View the number of visible CPU cores

• Update VM tenancy

• Host maintenance events

  • About host events
  • Live migration process
  • Set the host maintenance policy
  • Query metadata server for notices
  • Simulate a host maintenance event
  • Handle GPU host maintenance events
  • Monitor and plan for a host maintenance event
  • Manually start host maintenance

• Manage operating systems

• Manage operating systems using VM Manager

• Manage OS images

  • Image management best practices
  • Image families best practices
  • Access Red Hat Knowledgebase
  • Manage access to custom images
  • Set up trusted image policies
  • Export a custom image to Cloud Storage
  • Set image versions in an image family
  • Deprecate a custom image
  • Delete a custom image

• Manage OS packages

• Run shutdown scripts

• Configure NTP

• Enable the virtual random number generator (Virtio RNG)

• Deploy workloads

• Applications

  • Interactive: Build a to-do app with MongoDB
  • Deploy an ASP.NET application
  • Set up Joomla
  • Set up LAMP
  • Perform blue/green deployments using Cloud Build

• Databases

  • MySQL
    * Set up MySQL on Compute Engine
    * Set up client access with a private IP address
    * Cloning a MySQL database on Compute Engine
    * Deploying a highly available MySQL 5.6 cluster with DRBD on Compute Engine
  • SQL Server
    * Best practices for SQL Server VMs
    * Create
    * Create a high-performance SQL Server VM
    * Add a SQL Server license to an existing Linux server
    * Add a SQL Server license to an existing Windows server
    * Configure SQL Server on Google Cloud Platform using Cloud Volumes Service
    * Configure
    * Set up AlwaysOn availability groups using an internal load balancer
    * Set up AlwaysOn availability groups using a distributed network name
    * Set up a failover cluster VM that uses S2D
    * Set up a failover cluster VM with multi-writer disks
    * Set up a SQL Server cluster on Linux with Alaways On availability groups and Pacemaker
    * Cloning a Microsoft SQL Server database on Compute Engine
    * Load test SQL Server using HammerDB
    * Disaster recovery for Microsoft SQL Server
    * Disaster recovery for Microsoft SQL Server with Async PD
    * Deploying Microsoft SQL Server for multi-regional disaster recovery
    * Migrate a SQL Server database from Windows to Linux

• Containers

  • Containers on Compute Engine
  • Deploy containers on VMs and managed instance groups
  • Configure options to run your container

• Microsoft Windows

  • Windows workloads
  • Best practices for Windows Server VMs
  • Setting up Active Directory
  • Best practices for running Active Directory on Google Cloud
  • Deploy Microsoft SharePoint Server on Compute Engine
  • Deploying Microsoft Exchange Server 2016 on Compute Engine
  • Windows Server
    * Perform an in-place upgrade of Windows Server
    * Perform an automated in-place upgrade of Windows Server
    * Run Windows Server failover clustering

• Monitor

• Monitor logs

  • View audit logs
  • View usage reports
  • View Compute Engine operations
  • Migrate from activity logs to audit logs
  • View activity logs

• Organize resources using labels

• Scale

• Autoscale node groups

• Load balancing

  • About load balancing and scaling
  • Add an instance group to a load balancer
  • Request routing to a multi-region external HTTPS load balancer
  • Cross-region load balancing for Microsoft IIS backends
  • Set up Internal TCP/UDP Load Balancing

• Optimize

• Network performance

  • Network bandwidth
  • Use Google Virtual NIC
  • Use IDPF network interface
  • Configure a VM with higher bandwidth
  • Reduce latency by using compact placement policies
  • Optimize TCP network performance
  • Benchmark higher bandwidth VMs
  • Optimize app latency with load balancing
  • Use DPDK to improve network performance

• Troubleshoot

• General tips

About Persistent Disk performance

Stay organized with collections Save and categorize content based on your preferences.

This page discusses the many factors that determine the performance of the Persistent Disk volumes and lists the maximum performance limits for Persistent Disk.

For a discussion of Google Cloud Hyperdisk performance, seeAbout performance for Hyperdisk. For about Google Cloud Hyperdisk performance limits, seeHyperdisk performance limits.

Before you begin, consider the following:

• Persistent Disk are networked storage and generally have higher latency compared to physical disks or Local SSDs. To reach the maximum performance limits of the Persistent Disk, you must issue enough I/O requests in parallel. To check if you're using a high enough queue depth to reach your required performance levels, seeI/O queue depth.
• Make sure that your application is issuing enough I/O requests to saturate the disk. Disk saturation occurs when the CPU time during I/O requests issued to the device is very high.
• For workloads that primarily involve small (from 4 KB to 16 KB) random I/O requests, the limiting performance factor is I/O requests per second (IOPS).
• For workloads that primarily involve sequential or large (256 KB to 1 MB) random I/O requests, the limiting performance factor is throughput.

Choose a Persistent Disk type

When you create a Persistent Disk volume, you can select one of the following disk types:

• Balanced Persistent Disk (pd-balanced)
  • An alternative to SSD (Performance) Persistent Disk.
  • Balance of performance and cost. For most Compute Engine machine types, these disks have the same maximum IOPS as SSD Persistent Disk and lower IOPS per GiB. This disk type offers performance levels suitable for most general-purpose applications at a price point between that of standard and SSD Persistent Disk.
  • Backed by solid-state drives (SSD).
• SSD (Performance) Persistent Disk (pd-ssd)
  • Suitable for enterprise applications and high-performance databases that require lower latency and more IOPS than standard Persistent Disk provides.
  • Backed by solid-state drives (SSD).
• Standard Persistent Disk (pd-standard)
  • Suitable for large data processing workloads that primarily use sequential I/Os.
  • Backed by standard hard disk drives (HDD).
• Extreme Persistent Disk (pd-extreme)
  • Offers consistently high performance for both random access workloads and bulk throughput.
  • Designed for high-end database workloads.
  • Lets you provision the target IOPS.
  • Backed by solid-state drives (SSD).
  • Available with a limited number ofmachine types.

If you create a disk in the Google Cloud console, the default disk type ispd-balanced. If you create a disk using the gcloud CLI or the Compute Engine API, the default disk type is pd-standard.

Each storage option has unique performance limits that depend on themachine type and number of vCPUs in use.

Performance limits for Persistent Disk

Persistent Disk have limits for the maximum IOPS and throughput that they can sustain. There are throughput and IOPS limits per GiB and per instance. Balanced Persistent Disk and SSD (performance) Persistent Disk also offerbaseline performancefor sustained IOPS and throughput. Balanced Persistent Disk, SSD (performance) Persistent Disk, and Extreme Persistent Disk are designed for sub-millisecond latencies.Factors that affect performanceinclude machine type, disk size, instance vCPU count, and I/O block size.

This page details the performance limits forzonal Persistent Disk andregional Persistent Disk.

Zonal Persistent Disk

This section shows IOPS and throughput limits for zonal Persistent Disk.

IOPS limits for zonal Persistent Disk

The following table shows IOPS limits for zonal Persistent Disk.

* Requires anN2 instance with at least 64 vCPUs to achieve the stated performance limit. For maximum limits for all other machine types, seePerformance by machine type and vCPU count.

Throughput limits for zonal Persistent Disk

The following table shows throughput limits for zonal Persistent Disk. Persistent Disk can achieve greater performance on instances with more vCPUs. For more information, readNetwork egress caps on write throughput.

* Requires anN2 instance with at least 64 vCPUs to achieve the stated performance limit. For maximum limits for all other machine types, seePerformance by machine type and vCPU count.

Regional Persistent Disk

Like zonal Persistent Disk, regional Persistent Disk can achieve greater performance when you modifyfactors that can affect performance, like disk size and number of vCPUs.

The following tables show IOPS and throughput limits for regional Persistent Disk. These conditions apply to the stated limits:

• Achieving the stated limits requires a compute instance with at least 64 vCPUs and an N2 machine type or an N1 machine type running on the Intel Skylake or newer CPU. Instances using other machine types, such as N2D, have lower performance limits.
• Instances using E2machine types have lower performance limits because E2 machine types support a maximum of 32 vCPUs.
• Read IOPS per instance and read throughput per instance might be lower when the disk is inunreplicated mode.

IOPS limits for regional Persistent Disk

The following table shows IOPS limits for regional Persistent Disk.

* For N2D, the maximum read IOPS per instance for balanced Persistent Disk is 60,000.

For N2D, the maximum read IOPS per instance for SSD Persistent Disk is 70,000.

† For N2D, the maximum write IOPS per instance for balanced Persistent Disk is 50,000.

‡ For N2D, the maximum write IOPS per instance for SSD Persistent Disk is 60,000.

Throughput limits for regional Persistent Disk

The following table shows the throughput limits for regional Persistent Disk.

‡ For N2D, the maximum write throughput per instance for SSD Persistent Disk is 600 MiBps.

Sharing disks between instances

Attaching a disk to multiple instances in read-only modemode or in multi-writer mode does not affect aggregate performance or cost. Each machine gets a share of the per-disk performance limit. Persistent Disk created in multi-writer mode have specific IOPS and throughput limits. To learn how to share Persistent Disk between multiple instances, seeSharing Persistent Disk between instances.

Persistent Disk I/O operations share a common path with network traffic within a instance's hypervisor. Therefore, if the instance has significant network traffic, the actual read bandwidth and IOPS consistency might be less than the listed maximum limits. Some variability in the performance limits is to be expected, especially when operating near the maximum IOPS limits with an I/O size of 16 KB. For a summary of bandwidth expectations, seeBandwidth summary table.

Baseline performance

The following Persistent Disk types offer baseline IOPS and throughput performance in addition to sustained per GiB performance limits:

• Balanced Persistent Disk
• SSD Persistent Disk

Baseline performance is the same for all disk sizes and doesn't scale based on the number of disks of the same type that are attached to an instance. For example, if you have two zonal balanced Persistent Disk attached to an instance, they share a baseline performance of 3,000 IOPS.

To calculate the maximum expected performance of a Persistent Disk type, add the disk type's baseline performance to the per GiB performance limit for the disk type multiplied by the combined size (in GiB) of all disks of the same type that are attached to the instance:

Maximum expected performance = Baseline performance + (Per GiB performance limit * Combined disk size in GiB).

For example, the maximum IOPS of two 1000 GiB zonal balanced Persistent Disk attached to the same instance is 15,000, which is calculated as follows:

3,000 baseline performance + (6 IOPS performance limit per GiB * 2000 GiB combined disk size) = 15,000 IOPS

The following table shows the baseline performance for balanced and SSD Persistent Disk.

Zonal Persistent Disk

The following table shows the baseline sustained IOPS and throughput for zonal Persistent Disk:

Regional Persistent Disk

Regional Persistent Disk are supported on only E2, N1, N2, and N2D instances. The following table shows the baseline sustained IOPS and throughput for regional Persistent Disk:

Configure your Persistent Disk and instances

Persistent Disk performance scales with the size of the disk and with the number of vCPUs on your instance.

Performance scales until it reaches either the limits of the disk or the limits of the instance to which the disk is attached. Themachine type and the number of vCPUs on the instancedetermine the per-instance limits.

The following tables show performance limits for zonal Persistent Disk.

Performance by machine type and vCPU count for zonal Persistent Disk

The following tables show how zonal Persistent Disk performance varies according to the machine type and number of vCPUs on the instance to which the disk is attached.

A2 Ultra instances

pd-balanced

pd-ssd

pd-standard

A2 Standard instances

pd-balanced

pd-ssd

pd-standard

A3 Mega instances

pd-balanced

pd-ssd

A3 High instances

pd-balanced

pd-ssd

A3 Edge instances

pd-balanced

pd-ssd

C2 instances

pd-balanced

pd-ssd

pd-standard

C2D Instances

pd-balanced

pd-ssd

pd-standard

C3D Instances

pd-balanced

pd-ssd

C3 Instances

pd-balanced

pd-ssd

E2 Instances

pd-balanced

* E2 shared-coremachine types run two vCPUs simultaneously shared on one physical core for a specific fraction of time.

pd-ssd

* E2 shared-coremachine types run two vCPUs simultaneously shared on one physical core for a specific fraction of time.

pd-standard

* E2 shared-coremachine types run two vCPUs simultaneously shared on one physical core for a specific fraction of time.

G2 Instances

pd-balanced

pd-ssd

H3 Instances

pd-balanced

N1 Instances

pd-balanced

pd-ssd

pd-standard

N2 Instances

pd-balanced

pd-ssd

pd-standard

pd-extreme

N2 Instances with 96 or more vCPUs require the Intel Ice Lake CPU platform.

N2D Instances

pd-balanced

pd-ssd

pd-standard

M1 Instances

pd-balanced

pd-ssd

pd-standard

pd-extreme

M2 Instances

pd-balanced

pd-ssd

pd-standard

pd-extreme

M3 Instances

pd-balanced

pd-ssd

pd-extreme

T2D Instances

pd-balanced

pd-ssd

pd-standard

T2A Instances

pd-balanced

pd-ssd

pd-standard

Z3 Instances

pd-balanced

pd-ssd

Example

Consider a 1,000 GiB zonal SSD Persistent Disk attached to an N2 instance with 4 vCPUs. The read limit based solely on the size of the disk is 36,000 IOPS (6,000 baseline IOPs + (30 IOPS per GiB * 1,000 GiB)). However, the instance has only 4 vCPUs so the read limit is restricted to 15,000 IOPS.

Review performance

You can review Persistent Disk performance metrics inCloud Monitoring, Google Cloud's integrated monitoring solution.

To learn more, seeReviewing Persistent Disk performance metrics.

Optimize disk performance

To increase disk performance, start with the following steps:

• Resize your Persistent Diskto increase the per-disk IOPS and throughput limits. Persistent Disk don't have any reserved, unusable capacity, so you can use the full disk without performance degradation. However, certain file systems and applications might perform worse as the disk becomes full, so you might need to consider increasing the size of your disk to avoid such situations.
• Change the machine typeand number of vCPUs on the instance to increase the per-instance IOPS and throughput limits.

After choosing the right disk size and machine type for your instance to resolve any performance bottlenecks, your application and OS might need additional tuning. For more information, seeOptimizing Persistent Disk performanceand Optimizing Local SSD performance.

What's next

• Benchmark your Local SSDsand Persistent Disk that are attached to Linux instances.
• Optimize your Persistent Diskand Local SSDperformance.
• Learn about Persistent Disk andLocal SSD pricing.
• Learn how to review your project log entriesusing the Logs Explorer.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-05-07 UTC.