About instance performance

This page introduces the performance options available for Filestore instances and provides general recommendations to optimize performance. When you use Google Cloud console to create zonal and regional instances, custom performance is enabled by default to let you scale IOPS independently of capacity to meet your specific workload needs.

The following table provides a summary of performance limits for the lower and higher capacity ranges under custom performance settings:

Understand performance calculations

The following table displays performance calculations based on provisioned IOPS per TiB and allocated capacity. The calculations are based on different capacity ranges to show how the values for read IOPS, write IOPS, read throughput, and write throughput change for the minimum and maximum IOPS per TiB values.

For more information, see Read and write IOPS .

^* Depending on the access to the small capacity instances feature, the lower capacity range for Filestore regional instances can be either 100 GiB to 10,239 GiB or 1 TiB to 9.75 TiB. For more information, see Small capacity Filestore instances .

Performance scaling

In single- and few-client scenarios, you must increase the number of TCP connections with the nconnect mount option to achieve maximum NFS performance.

For specific service tiers, we recommend specifying the following number of connections between the client and server:

In general, the larger the file share capacity and the fewer the connecting client VMs, the more performance you gain by specifying additional connections with nconnect .

Recommended client machine type

We recommend having a Compute Engine machine type , such as n2-standard-8 , that provides an egress bandwidth of at least 16 Gbps. This egress bandwidth allows the client to achieve approximately 16 Gbps read bandwidth for cache-friendly workloads. For additional context, see Network bandwidth .

Linux client mount options

We recommend using the following NFS mount options, especially hard mount, async , and the rsize and wsize options, to achieve the best performance on Linux client VM instances. For more information on NFS mount options, see nfs .

Optimize the NFS read throughput with read_ahead_kb parameter

The NFS read_ahead_kb parameter specifies the amount of data, in kilobytes, that the Linux kernel should prefetch during a sequential read operation. As a result, the subsequent read requests can be served directly from memory to reduce latency and improve the overall performance.

For Linux kernel versions 5.4 and higher, the Linux NFS client uses a default read_ahead_kb value of 128 KB. We recommend increasing this value to 20 MB to improve the sequential read throughput.

After you successfully mount the file share on the Linux client VM, you can use the following script to manually adjust the read_ahead_kb parameter value:

 mount_point= MOUNT_POINT_DIRECTORY 
device_number=$(stat -c '%d' $mount_point)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo 20480 > /sys/class/bdi/$major:$minor/read_ahead_kb" 

Replace the following:

MOUNT_POINT_DIRECTORY is the path to the directory where the file share is mounted.

Single and multiple client VM performance

Filestore's scalable service tiers are performance optimized for multiple client VMs, not a single client VM.

For zonal, regional, and enterprise instances, at least four client VMs are needed to take advantage of full performance. This ensures that all of the VMs in the underlying Filestore cluster are fully utilized.

For added context, the smallest scalable Filestore cluster has four VMs. Each client VM communicates with just one Filestore cluster VM, regardless of the number of NFS connections per client specified using the nconnect mount option. If using a single client VM, read and write operations are only performed from a single Filestore cluster VM.

Capacity-based performance limits

Capacity-based limits apply to service tiers that don't support custom performance, such as basic tiers, or instances in which you manually deactivate custom performance.

Each Filestore service tier provides a different level of performance that might vary due to factors such as the use of caching, the number of client VMs, the machine type of the client VMs, and the workload tested.

The following table lists the maximum performance you can achieve when setting minimum and maximum capacity for each service tier. All table values are estimated limits.

Improve performance across Google Cloud resources

Operations across multiple Google Cloud resources, such as copying data from Cloud Storage to a Filestore instance using the Google Cloud CLI, can be slow. To help mitigate performance issues, try the following:

• Ensure the Cloud Storage bucket, client VM, and Filestore instance all reside in the same region .

  Dual-regions provide a maximally-performant option for data stored in Cloud Storage. If using this option, ensure the other resources reside in one of the single regions contained in the dual-region. For example, if your Cloud Storage data resides in us-central1,us-west1 , ensure that your client VM and Filestore instance reside in us-central1 .

• For a point of reference, verify the performance of a VM with a Persistent Disk (PD) attached and compare to the performance of a Filestore instance.

  • If the PD-attached VM is similar or slower in performance when compared to the Filestore instance, this might indicate a performance bottleneck unrelated to Filestore. To improve the baseline performance of your non-Filestore resources, you can adjust the gcloud CLI properties associated with parallel composite uploads. For more information see How tools and APIs use parallel composite uploads .
  • If the performance of the Filestore instance is notably slower than the
    PD-attached VM, try spreading the operation over multiple VMs to improve performance of read operations from Cloud Storage.

What's next

• Custom performance
• Test performance
• Troubleshoot performance-related issues
• Scale capacity