Instance performance

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

This page describes the performance limits for Filestore instances along with recommended performance settings and testing options.

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 and not guaranteed. For information on custom performance settings and limits, see custom performance limits.

Performance scaling

Performance scales linearly with the capacity within the performance limits listed in the previous table. For example if you double your enterprise instance capacity from 1 TiB to 2 TiB, the performance limit of the instance doubles from 12,000/4,000 read and write IOPS to 24,000/8,000 read and write IOPS.

In single- and few-client scenarios, you must increase the number of TCP connections with the nconnect mount option to achieve maximum NFS performance. We recommend specifying up to 7 connections for the zonal service tier and up to 2 connections for the regional and enterprise tiers. 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.

Custom performance

Set custom performance to configure performance according to your workload needs, independently of the specified capacity. You can either specify an IOPS per TiB ratio, or set a fixed number of IOPS. For details, see Custom performance.

Recommended client machine type

We recommend having a Compute Engine machine type, such as n2-standard-8, that provides an egress bandwidth of 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.

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.

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 gcloud 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 PD-attached VM 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.

  • This helps to improve performance of read operations from Cloud Storage.

  • 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 more information, see Single and multiple client VM performance.

Test performance

If you are using Linux, you can use the fio tool to benchmark read and write throughput and IOPS for basic tier instances. Note that this method for benchmarking performance is not recommended for zonal, regional, and enterprise instances.

The examples in this section show common benchmarks you might want to run. You may need to run fio from multiple client VM instances to achieve maximum performance.

The following example benchmarks maximum write throughput:

fio --ioengine=libaio --filesize=32G --ramp_time=2s \
--runtime=5m --numjobs=16 --direct=1 --verify=0 --randrepeat=0 \
--group_reporting --directory=/mnt/nfs --buffer_compress_percentage=50 \
--name=write --blocksize=1m --iodepth=64 --readwrite=write

The following example benchmarks maximum write IOPS:

fio --ioengine=libaio --filesize=32G --ramp_time=2s \
--runtime=5m --numjobs=16 --direct=1 --verify=0 --randrepeat=0 \
--group_reporting --directory=/mnt/nfs --buffer_compress_percentage=50 \
--name=randwrite --blocksize=4k --iodepth=256 --readwrite=randwrite

The following example benchmarks maximum read throughput:

fio --ioengine=libaio --filesize=32G --ramp_time=2s \
--runtime=5m --numjobs=16 --direct=1 --verify=0 --randrepeat=0 \
--group_reporting --directory=/mnt/nfs --buffer_compress_percentage=50 \
--name=read --blocksize=1m --iodepth=64 --readwrite=read

The following example benchmarks maximum read IOPS:

fio --ioengine=libaio --filesize=32G --ramp_time=2s \
--runtime=5m --numjobs=16 --direct=1 --verify=0 --randrepeat=0 \
--group_reporting --directory=/mnt/nfs --buffer_compress_percentage=50 \
--name=randread --blocksize=4k --iodepth=256 --readwrite=randread

What's next

• Troubleshoot performance-related issues
• Scale capacity