If your client VM is running Linux, confirm that you're using the
default mount options.
Ensure that the client VM is located in the same region as the
Filestore instance. Mounting across regions not only reduces
performance, it also incurs a networking cost.
Ensure that your Filestore instance isn't at or near full
capacity. When capacity is nearly full, any remaining space is highly
fragmented, causing read and write operations to slow down. The amount of
free space needed to avoid this scenario is case-dependent. We recommend
setting up
low disk space alerts.
If the test results show abnormally slow performance, contact your account
representative. If the test results show similar or greater performance than
expected, continue to the next section.
Use cases that cause slow performance
Here are some use cases and scenarios that cause poor performance:
Workloads involving high volumes of small files
Filestore file shares use the sync export option for data safety
and NFS protocol compliance. For most data-modifying operations, the
Filestore instance waits for the data to be committed to storage
before replying to requests from the client VM. When many files are involved
in an operation, the client makes a long series of synchronous operations
and the cumulative latency adds up.
An example of this scenario is when you extract an archive on the file share,
like tar files. TAR makes many synchronous operations in a series when
extracting an archive containing many files. As a result, performance is
reduced.
If you're trying to copy many small files to a file share, try parallelizing
file creation with a tool like the Google Cloud CLI:
mkdir -p /mnt/nfs/many_files_rsync/
time gcloud storage rsync many_files /mnt/nfs/many_files_rsync/ --recursive
Each file stored on the file share consumes one inode. If the file system
runs out of inodes, you won't be able to store more files on the file share
even if you haven't reached the maximum allocated capacity. However, reaching
the maximum number of inodes is rare and is only a concern if you need to
store numerous small files.
Copying data from Cloud Storage to a Filestore instance using the
gcloud CLI is known to be slow. For detailed information on how to
improve performance, see
Improve performance across Google Cloud resources.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[[["\u003cp\u003eThis page helps troubleshoot slow performance issues with Filestore, providing actionable steps to diagnose and resolve them.\u003c/p\u003e\n"],["\u003cp\u003eSlow performance can often be attributed to client VM configuration, such as incorrect machine type, mount options (avoid using \u003ccode\u003esync\u003c/code\u003e), or being in a different region than the Filestore instance.\u003c/p\u003e\n"],["\u003cp\u003eFilestore performance can degrade when the instance is near full capacity, leading to fragmentation and slower read/write operations, so monitoring is crucial.\u003c/p\u003e\n"],["\u003cp\u003eWorkloads involving a high volume of small files can result in slow performance due to the synchronous nature of Filestore operations, and copying data between Cloud Storage and Filestore using the gcloud CLI can be slow as well.\u003c/p\u003e\n"],["\u003cp\u003eTesting performance using \u003ccode\u003efio\u003c/code\u003e is recommended to identify issues, and if performance is slower than expected, contacting an account representative is advised.\u003c/p\u003e\n"]]],[],null,["# Troubleshoot slow performance\n\nThis page provides troubleshooting information to help address slow performance\nissues you might encounter while using Filestore.\n\nSlow read or write performance\n------------------------------\n\n1. Ensure that you are using the\n [recommended machine type](/filestore/docs/performance#client-machine)\n for the client VM.\n\n2. If your client VM is running Linux, confirm that you're using the\n [default mount options](/filestore/docs/performance#linux_client_mount_options).\n\n | **Note:** Using the `sync` client mount option significantly reduces performance.\n3. Ensure that the client VM is located in the same region as the\n Filestore instance. Mounting across regions not only reduces\n performance, it also incurs a [networking cost](/vpc/network-pricing).\n\n4. Ensure that your Filestore instance isn't at or near full\n capacity. When capacity is nearly full, any remaining space is highly\n fragmented, causing read and write operations to slow down. The amount of\n free space needed to avoid this scenario is case-dependent. We recommend\n setting up\n [low disk space alerts](/filestore/docs/monitoring-instances#low-disk-space).\n\n For more information, see [Troubleshoot capacity issues](/filestore/docs/capacity-issues).\n5. [Test the performance](/filestore/docs/performance#testing_performance)\n of your Filestore instance using the `fio` tool.\n\n If the test results show abnormally slow performance, contact your account\n representative. If the test results show similar or greater performance than\n expected, continue to the next section.\n\nUse cases that cause slow performance\n-------------------------------------\n\nHere are some use cases and scenarios that cause poor performance:\n\n### Workloads involving high volumes of small files\n\n- Filestore file shares use the `sync` export option for data safety\n and NFS protocol compliance. For most data-modifying operations, the\n Filestore instance waits for the data to be committed to storage\n before replying to requests from the client VM. When many files are involved\n in an operation, the client makes a long series of synchronous operations\n and the cumulative latency adds up.\n\n An example of this scenario is when you extract an archive on the file share,\n like tar files. TAR makes many synchronous operations in a series when\n extracting an archive containing many files. As a result, performance is\n reduced.\n\n If you're trying to copy many small files to a file share, try parallelizing\n file creation with a tool like the [Google Cloud CLI](/sdk/gcloud/reference/storage/rsync): \n\n mkdir -p /mnt/nfs/many_files_rsync/\n time gcloud storage rsync many_files /mnt/nfs/many_files_rsync/ --recursive\n\n- Each file stored on the file share consumes one inode. If the file system\n runs out of inodes, you won't be able to store more files on the file share\n even if you haven't reached the maximum allocated capacity. However, reaching\n the maximum number of inodes is rare and is only a concern if you need to\n store numerous small files.\n\n For more information, see [Inode usage](/filestore/docs/scale#inode-usage).\n\n### Copying data between Cloud Storage and Filestore\n\nCopying data from Cloud Storage to a Filestore instance using the\ngcloud CLI is known to be slow. For detailed information on how to\nimprove performance, see\n[Improve performance across Google Cloud resources](/filestore/docs/performance#across-resources).\n\nWhat's next\n-----------\n\n- [Troubleshoot capacity issues](/filestore/docs/capacity-issues)\n- [Improve performance across Google Cloud resources](/filestore/docs/performance#across-resources).\n- [Scale capacity](/filestore/docs/scale)."]]
