이 페이지에서는 Filestore 인스턴스의 성능 제한과 권장 성능 설정 및 테스트 옵션을 설명합니다.
Filestore 서비스는 등급마다 성능 수준에 차이가 있으며, 이는 캐싱 사용, 클라이언트 VM의 수, 클라이언트 VM의 머신 유형, 테스트 중인 워크로드와 같은 요인으로 인해 달라질 수 있습니다.
다음 표에는 각 서비스 등급의 최소 및 최대 용량을 설정할 때 달성할 수 있는 최대 성능이 나와 있습니다.
모든 표 값은 예상 한도이며 보장되지 않습니다. 맞춤 성능 설정 및 제한에 관한 자세한 내용은 맞춤 성능 제한을 참고하세요.
각 서비스 등급의 최소 및 최대 용량에서 성능 제한
서비스 등급
용량
읽기 IOPS
쓰기 IOPS
읽기 처리량 (MiBps)
쓰기 처리량 (MiBps)
단일 클라이언트 읽기 처리량 (MiBps)
단일 클라이언트 쓰기 처리량 (MiBps)
맞춤 성능 지원 여부
BASIC_HDD
1TiB~10TiB
600
1,000
100
100
100
100
아니요
10TiB~63.9TiB
1,000
5,000
180
120
180
120
BASIC_SSD
2.5TiB~63.9TiB
60,000
25,000
1,200
350
1,200
350
ZONAL
1TiB
9,200
2,600
260
88
260
88
예
9.75TiB
89,700
25,350
2,535
858
450
260
10TiB
92,000
26,000
2,600
880
1,600
800
100TiB
920,000
260,000
26,000
8,800
1,600
800
리전
1TiB
12,000
4,000
120
100
120
100
9.75TiB
117,000
39,000
1,170
975
450
260
10TiB
92,000
26,000
2,600
880
1,600
800
100TiB
920,000
260,000
26,000
8,800
1,600
800
ENTERPRISE
1TiB
12,000
4,000
120
100
120
100
아니요
10TiB
120,000
40,000
1,200
1,000
450
260
성능 확장
성능은 이전 표에 나열된 성능 제한 내에서 용량에 따라 선형적으로 확장됩니다. 예를 들어 엔터프라이즈 인스턴스 용량을 1TiB에서 2TiB로 두 배로 늘리면 인스턴스의 성능 한도가 12,000/4,000 읽기 및 쓰기 IOPS에서 24,000/8,000 읽기 및 쓰기 IOPS로 두 배로 늘어납니다.
단일 및 소수의 클라이언트 시나리오에서는 최대 NFS 성능을 달성하기 위해 nconnect 마운트 옵션을 사용하여 TCP 연결 수를 늘려야 합니다.
특정 서비스 등급의 경우 클라이언트와 서버 간의 연결 수를 다음과 같이 지정하는 것이 좋습니다.
등급
용량
연결 수
지역, 영역
1~9.75TiB
nconnect=2
지역, 영역
10~100TiB
nconnect=7
Enterprise
-
nconnect=2
대규모 SSD
-
nconnect=7
일반적으로 파일 공유 용량이 크고 연결하는 클라이언트 VM의 수가 적을수록 nconnect와의 추가 연결을 지정하여 더 많은 성능을 얻을 수 있습니다.
커스텀 성능
지정된 용량과 관계없이 워크로드 요구사항에 따라 성능을 구성하도록 맞춤 성능을 설정합니다. TiB당 IOPS 비율을 지정하거나 고정된 수의 IOPS를 설정할 수 있습니다. 자세한 내용은 맞춤 실적을 참고하세요.
권장 클라이언트 머신 유형
16Gbps 이상의 이그레스 대역폭을 제공하는 n2-standard-8와 같은 Compute Engine 머신 유형을 사용하는 것이 좋습니다. 이 이그레스 대역폭을 사용하면 클라이언트는 캐시에 적합한 워크로드에서 약 16Gbps의 읽기 대역폭을 달성할 수 있습니다. 추가 컨텍스트는 네트워크 대역폭을 참고하세요.
Linux 클라이언트 마운트 옵션
Linux 클라이언트 VM 인스턴스에서 최상의 성능을 얻으려면 다음 NFS 마운트 옵션, 특히 hard 마운트, async, rsize 및 wsize 옵션을 사용하는 것이 좋습니다. NFS 마운트 옵션에 대한 자세한 내용은 nfs를 참고하세요.
기본 옵션
설명
hard
NFS 클라이언트는 NFS 요청을 무제한으로 시도합니다.
timeo=600
NFS 클라이언트는 600데시초(60초) 간격으로 NFS 요청을 다시 시도합니다.
retrans=3
NFS 클라이언트는 NFS 요청을 3회 시도한 후 추가 복구 작업을 수행합니다.
rsize=524288
NFS 클라이언트는 NFS 서버로부터 READ 요청당 최대 524,288바이트를 수신할 수 있습니다. 참고: 기본 등급 인스턴스의 경우 rsize 값을 1048576로 설정합니다.
wsize=1048576
NFS 클라이언트는 WRITE 요청당 NFS 서버에 최대 1,048,576바이트(1MiB)를 보낼 수 있습니다.
resvport
NFS 클라이언트는 이 마운트 지점에 대해 NFS 서버와 통신할 때 권한이 있는 소스 포트를 사용합니다.
async
NFS 클라이언트는 특정 조건이 충족될 때까지 NFS 서버에 대한 애플리케이션 쓰기 전송을 지연합니다. 주의: sync 옵션을 사용하면 성능이 크게 저하됩니다.
read_ahead_kb 매개변수를 사용하여 NFS 읽기 처리량 최적화
NFS read_ahead_kb 매개변수는 순차 읽기 작업 중에 Linux 커널이 미리 가져와야 하는 데이터의 양(킬로바이트)을 지정합니다. 따라서 후속 읽기 요청은 메모리에서 직접 제공되어 지연 시간을 줄이고 전반적인 성능을 개선할 수 있습니다.
Linux 커널 버전 5.4 이상에서는 Linux NFS 클라이언트가 기본 read_ahead_kb 값 128KB를 사용합니다.
순차 읽기 처리량을 개선하려면 이 값을 20MB로 늘리는 것이 좋습니다.
Linux 클라이언트 VM에 파일 공유를 마운트한 후 다음 스크립트를 사용하여 read_ahead_kb 매개변수 값을 수동으로 조정할 수 있습니다.
Filestore의 확장 가능한 서비스 등급은 단일 클라이언트 VM이 아닌 여러 클라이언트 VM에 맞춰 성능이 최적화되어 있습니다.
영역, 지역, 엔터프라이즈 인스턴스의 경우 전체 성능을 활용하려면 최소 4개의 클라이언트 VM이 필요합니다. 그래야 기본 Filestore 클러스터의 모든 VM이 완전히 활용됩니다.
추가 컨텍스트를 제공하자면 확장 가능한 가장 작은 Filestore 클러스터에는 4개의 VM이 있습니다. 각 클라이언트 VM은 nconnect 마운트 옵션을 사용하여 지정된 클라이언트당 NFS 연결 수와 관계없이 Filestore 클러스터 VM 하나와만 통신합니다. 단일 클라이언트 VM을 사용하는 경우 읽기 및 쓰기 작업은 단일 Filestore 클러스터 VM에서만 실행됩니다.
Google Cloud 리소스 전반의 성능 개선
gcloud CLI를 사용하여 Cloud Storage에서 Filestore 인스턴스로 데이터를 복사하는 것과 같이 여러 Google Cloud 리소스에 걸쳐 작업을 실행하면 속도가 느려질 수 있습니다. 성능 문제를 완화하려면 다음을 시도해 보세요.
Cloud Storage 버킷, 클라이언트 VM, Filestore 인스턴스가 모두 동일한 리전에 있는지 확인합니다.
이중 리전은 Cloud Storage에 저장된 데이터에 최대 성능의 옵션을 제공합니다. 이 옵션을 사용하는 경우 다른 리소스가 이중 리전에 포함된 단일 리전 중 하나에 있는지 확인합니다. 예를 들어 Cloud Storage 데이터가 us-central1,us-west1에 있는 경우 클라이언트 VM과 Filestore 인스턴스가 us-central1에 있는지 확인합니다.
참고용으로 영구 디스크(PD)가 연결된 VM의 성능을 확인하고 Filestore 인스턴스의 성능과 비교합니다.
Filestore 인스턴스와 비교할 때 PD 연결 VM의 성능이 비슷하거나 느리면 Filestore와 관련 없는 성능 병목 현상이 나타날 수 있습니다. Filestore 이외의 리소스의 기준 성능을 개선하려면 동시 복합 업로드와 연결된 gcloud CLI 속성을 조정하면 됩니다. 자세한 내용은 도구 및 API에서 동시 복합 업로드를 사용하는 방법을 참고하세요.
Filestore 인스턴스의 성능이 PD 연결 VM보다 현저히 느리면 작업을 여러 VM에 분산해 보세요.
이렇게 하면 Cloud Storage의 읽기 작업 성능이 개선됩니다.
영역, 지역, 엔터프라이즈 인스턴스의 경우 전체 성능을 활용하려면 최소 4개의 클라이언트 VM이 필요합니다. 그래야 기본 Filestore 클러스터의 모든 VM이 완전히 활용됩니다.
자세한 내용은 단일 및 다중 클라이언트 VM 성능을 참고하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eThis page provides an overview of Filestore's expected performance across different service tiers and capacities, along with factors that can influence performance.\u003c/p\u003e\n"],["\u003cp\u003ePerformance scales linearly with capacity increases in Filestore instances, such as doubling the capacity from 1 TiB to 2 TiB which also doubles the expected performance.\u003c/p\u003e\n"],["\u003cp\u003eTo maximize NFS performance, especially in single- or few-client scenarios, you should increase the number of TCP connections using the \u003ccode\u003enconnect\u003c/code\u003e mount option, with recommendations varying by service tier.\u003c/p\u003e\n"],["\u003cp\u003eFor optimal performance, especially in zonal, regional, and enterprise instances, utilizing at least four client VMs ensures full utilization of the underlying Filestore cluster.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003efio\u003c/code\u003e tool can be used to benchmark read and write throughput and IOPS for basic tier instances on Linux, but it is not recommended for zonal, regional, and enterprise tiers.\u003c/p\u003e\n"]]],[],null,["# Instance performance\n\nThis page describes the performance limits for Filestore instances along with recommended performance settings and testing options.\n\nEach 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\n[machine type](/compute/docs/machine-types) of the client VMs, and the workload tested.\n\nThe following table lists the maximum performance you can achieve when setting minimum and maximum capacity for each service tier.\n\nAll table values are estimated limits and not guaranteed. For information on custom performance settings and limits, see [custom performance limits](/filestore/docs/custom-performance#custom-performance-limits).\n\nPerformance scaling\n-------------------\n\nPerformance 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.\n\nIn single- and few-client scenarios, you must increase the number of TCP\nconnections with the\n[`nconnect`](https://man7.org/linux/man-pages/man5/nfs.5.html)\nmount option to achieve maximum NFS performance.\n\nFor specific service tiers, we recommend specifying the following number of connections between the client and server:\n\nIn 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`.\n\nCustom performance\n------------------\n\nSet 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](/filestore/docs/custom-performance).\n\nRecommended client machine type\n-------------------------------\n\nWe recommend having a Compute Engine [machine type](/compute/docs/machine-types), 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](/compute/docs/network-bandwidth).\n\nLinux client mount options\n--------------------------\n\nWe recommend using the following NFS mount options, especially `hard` mount,\n`async`, and the `rsize` and `wsize` options, to achieve the best performance on\nLinux client VM instances. For more information on NFS mount options, see\n[nfs](https://linux.die.net/man/5/nfs).\n\nOptimize the NFS read throughput with `read_ahead_kb` parameter\n---------------------------------------------------------------\n\nThe 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.\n\nFor Linux kernel versions `5.4` and higher, the Linux NFS client uses a default `read_ahead_kb` value of 128 KB.\nWe recommend increasing this value to 20 MB to improve the sequential read throughput.\n\nAfter 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: \n\n mount_point=\u003cvar translate=\"no\"\u003eMOUNT_POINT_DIRECTORY\u003c/var\u003e\n device_number=$(stat -c '%d' $mount_point)\n ((major = ($device_number & 0xFFF00) \u003e\u003e 8))\n ((minor = ($device_number & 0xFF) | (($device_number \u003e\u003e 12) & 0xFFF00)))\n sudo bash -c \"echo 20480 \u003e /sys/class/bdi/$major:$minor/read_ahead_kb\"\n\nWhere:\n\n\u003cvar translate=\"no\"\u003eMOUNT_POINT_DIRECTORY\u003c/var\u003e is the path to the directory where the file share is mounted.\n| **Note:** You can't use this script directly with GKE if the pod is not running as the root user. To set the `read_ahead_kb` parameter, use an [init container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) with root permissions or [DeaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/).\n\nSingle and multiple client VM performance\n-----------------------------------------\n\nFilestore's scalable service tiers are performance optimized for\nmultiple client VMs, not a single client VM.\n\nFor zonal, regional, and enterprise instances, at least four client VMs are\nneeded to take advantage of full performance. This ensures that all of the VMs\nin the underlying Filestore cluster are fully utilized.\n\nFor added context, the smallest scalable Filestore cluster has four\nVMs. Each client VM communicates with just one Filestore cluster VM,\nregardless of the number of NFS connections per client specified using the\n[`nconnect`](https://man7.org/linux/man-pages/man5/nfs.5.html)\nmount option. If using a single client VM, read and write operations are only\nperformed from a single Filestore cluster VM.\n\nImprove performance across Google Cloud resources\n-------------------------------------------------\n\nOperations across multiple Google Cloud resources, such as copying data\nfrom Cloud Storage to a Filestore instance using the\ngcloud CLI, can be slow. To help mitigate performance issues, try the\nfollowing:\n\n- Ensure the Cloud Storage bucket, client VM, and Filestore\n instance all reside in the same [region](/filestore/docs/regions).\n\n [Dual-regions](/storage/docs/locations#location-dr) 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`.\n- For a point of reference, verify the performance of a VM with a Persistent Disk\n (PD) attached and compare to the performance of a Filestore instance.\n\n - 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](/storage/docs/parallel-composite-uploads#behavior).\n\n | **Note:** The gcloud CLI has no built-in support for throttling requests. Users should experiment with requested values as optimal values can vary based on a number of factors including network speed, number of CPUs, and available memory.\n - If the performance of the Filestore instance is notably slower than the \n\n PD-attached VM, try spreading the operation over multiple VMs.\n\n - This helps to improve performance of read operations from Cloud Storage.\n\n - For zonal, regional, and enterprise instances, at least four client VMs\n are needed to take advantage of full performance. This ensures that all of\n the VMs in the underlying Filestore cluster are fully utilized.\n For more information, see [Single and multiple client VM performance](/filestore/docs/performance#single-multiple-performance).\n\nWhat's next\n-----------\n\n- [Test performance](/filestore/docs/testing-performance)\n- [Troubleshoot performance-related issues](/filestore/docs/troubleshooting)\n- [Scale capacity](/filestore/docs/scale)"]]
