볼륨 용량 늘리기: 프리미엄, 익스트림 또는 표준 서비스 수준 볼륨의 용량을 늘려 달성 가능한 최대 볼륨 처리량을 개선할 수 있습니다. Flex 서비스 수준 볼륨의 경우 대신 스토리지 풀 용량을 늘리세요.
서비스 수준 업그레이드: Premium 서비스 수준 볼륨을 Extreme 서비스 수준으로 업그레이드하여 처리량을 개선할 수 있습니다. 서비스 수준이 다른 다른 스토리지 풀에 볼륨을 할당하는 것이 좋습니다.
볼륨 용량을 늘리고 서비스 수준을 업그레이드해도 볼륨에서 처리 중인 I/O 워크로드에 영향을 주지 않으며 볼륨 액세스에 영향을 주지 않습니다.
클라이언트 조정
클라이언트에서 다음 설정을 조정하여 성능을 개선할 수 있습니다.
클라이언트 공동 배치: 지연 시간 결과는 클라이언트의 기능과 위치에 직접적인 영향을 받습니다. 최상의 결과를 얻으려면 클라이언트를 볼륨과 동일한 리전 또는 최대한 가까운 곳에 배치하세요. 각 영역의 클라이언트에서 지연 시간을 테스트하여 영역별 영향을 테스트하고 지연 시간이 가장 짧은 영역을 사용합니다.
Compute Engine 네트워크 대역폭 구성: Compute Engine 가상 머신의 네트워크 기능은 사용되는 인스턴스 유형에 따라 다릅니다. 일반적으로 인스턴스가 클수록 더 많은 네트워크 처리량을 사용할 수 있습니다. 적절한 네트워크 대역폭 기능이 있는 클라이언트 가상 머신을 선택하고, Google 가상 NIC (gVNIC) 네트워크 인터페이스를 선택하고, Tier_1 성능을 사용 설정하는 것이 좋습니다. 자세한 내용은 Compute Engine 문서의 네트워크 대역폭을 참고하세요.
여러 TCP 세션 열기: 애플리케이션에 높은 처리량이 필요한 경우 결국 일반 NFS 및 SMB 세션의 기반이 되는 단일 전송 제어 프로토콜 (TCP) 세션이 포화될 수 있습니다. 이 경우 NFS 및 SMB 연결에서 사용하는 TCP 세션 수를 늘립니다.
다음 탭 중 하나를 사용하여 클라이언트 유형에 따라 클라이언트를 조정합니다.
Linux
기존에는 NFS 클라이언트가 스토리지 엔드포인트를 공유하는 모든 NFS 마운트 파일 시스템에 단일 TCP 세션을 사용했습니다. nconnect 마운트 옵션을 사용하면 지원되는 TCP 세션 수를 최대 16개까지 늘릴 수 있습니다.
nconnect를 최대한 활용할 수 있도록 Linux 클라이언트 유형을 조정하려면 다음 권장사항을 따르세요.
nconnect를 사용하여 TCP 세션 수 늘리기: TCP 세션을 추가할 때마다 대기 중인 128개 요청의 대기열이 추가되어 잠재적인 동시 실행 능력이 향상됩니다.
sunrpc.max_tcp_slot_table_entries 매개변수 설정: sunrpc.max_tcp_slot_table_entries는 성능을 제어하도록 수정할 수 있는 연결 수준 조정 매개변수입니다. sunrpc.max_tpc_slot_table_enteries를 요청당 또는 연결당 128로 설정하고 NetApp 볼륨에 연결되는 단일 프로젝트 내의 모든 NFS 클라이언트의 슬롯을 10,000개를 초과하지 않는 것이 좋습니다. sunrpc.max_tcp_slot_table_entries 매개변수를 설정하려면 /etc/sysctl.conf 파일에 매개변수를 추가하고 sysctl -p 명령어를 사용하여 매개변수 파일을 새로고침합니다.
세션당 지원되는 최대 값을 180으로 조정: NFSv3와 달리 NFSv4.1 클라이언트는 세션에서 클라이언트와 서버 간의 관계를 정의합니다. NetApp 볼륨은 NFSv3을 사용하여 연결당 최대 128개의 대기 중인 요청을 지원하지만 NFSv4.1은 세션당 대기 중인 요청이 180개로 제한됩니다. Linux NFSv4.1 클라이언트는 기본적으로 세션당 64 max_session_slots로 설정되지만 필요에 따라 이 값을 조정할 수 있습니다. 세션당 지원되는 최대 값을 180으로 변경하는 것이 좋습니다.
max_session_slots를 조정하려면 /etc/modprobe.d 아래에 구성 파일을 만듭니다. 인라인에 따옴표 (" ")가 표시되지 않아야 합니다. 그렇지 않으면 옵션이 적용되지 않습니다.
다음 NFS nconnect 비교 그래프는 nconnect 구성을 사용하면 NFS 워크로드에 미칠 수 있는 영향을 보여줍니다. 이 정보는 다음 설정으로 Fio를 사용하여 캡처되었습니다.
100% 읽기 워크로드
단일 볼륨에 대한 8KiB 블록 크기
Red Hat 9 OS를 사용하는 n2-standard-32 가상 머신
6TiB 작업 세트
nconnect 값을 16으로 사용하면 사용 설정하지 않은 경우보다 성능이 5배 향상되었습니다.
Windows
Windows 기반 클라이언트의 경우 클라이언트는 수신 측 확장 (RSS)과 함께 SMB 멀티채널을 사용하여 여러 TCP 연결을 열 수 있습니다. 이 구성을 사용하려면 가상 머신에 RSS를 지원하는 할당된 네트워크 어댑터가 있어야 합니다. RSS를 4 또는 8 값으로 설정하는 것이 좋지만 1보다 큰 값을 사용하면 처리량이 증가합니다.
다음 그래프는 RSS 구성을 사용하면 SMB 워크로드에 미칠 수 있는 차이를 보여줍니다. 이 정보는 다음 설정으로 Fio를 사용하여 캡처되었습니다.
100% 읽기 워크로드
단일 볼륨에 대한 8KiB 블록 크기
Windows 2022 OS를 실행하는 단일 n2-standard-32 가상 머신
6TiB 작업 세트
테스트 실행 간에 SMB 클라이언트 RSS 옵션만 변경하여 8개의 작업을 실행했습니다. RSS 값을 4, 8, 16으로 사용하면 값 1을 사용할 때보다 성능이 두 배 향상되었습니다. 각 RSS 인스턴스는 numjobs 매개변수가 8인 상태로 9번 실행되었습니다. 최대 처리량에 도달할 때까지 실행할 때마다 iodepth 매개변수가 5씩 증가했습니다.
[[["이해하기 쉬움","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)"],[],[],null,["# Optimize performance\n\nThis page provides details on how you can optimize Google Cloud NetApp Volumes\nperformance.\n\nBefore you begin\n----------------\n\nBefore you make changes to your volumes to optimize performance, review\n[performance considerations](/netapp/volumes/docs/performance/performance-considerations).\n\nAdjust volume settings\n----------------------\n\nYou can optimize performance by adjusting the following volume settings:\n\n- **Increase volume capacity**: You can increase the capacity of your Premium,\n Extreme or Standard service level volume to improve maximum achievable volume\n throughput. For volumes of Flex service level, increase storage pools capacity\n instead.\n\n- **Upgrade your service level**: You can upgrade your Premium service level\n volumes to the Extreme service level to improve throughput. We recommend that\n you assign the volume to a different storage pool with a different service\n level.\n\nIncreasing volume capacity and upgrading service levels are both non-disruptive\nto I/O workloads in process on the volume and don't affect access to the volume\nin any way.\n\nAdjust the client\n-----------------\n\nYou can improve performance by adjusting the following settings on the client:\n\n- **Co-locate clients**: latency results are directly impacted by the\n capabilities and location of the client. For best results, place the client\n in the same region as the volume or as close as possible. Test the zonal\n impact by testing latency from a client in each zone and use the zone with\n the lowest latency.\n\n- **Configure Compute Engine network bandwidth** : the network capabilities of\n Compute Engine virtual machines depend on the instance type used. Typically,\n larger instances can drive more network throughput. We recommend that you\n select a client virtual machine with an appropriate network bandwidth\n capability, select the Google Virtual NIC (gVNIC) network interface and\n enable `Tier_1` performance. For more information, see Compute Engine\n documentation on [network bandwidth](/compute/docs/network-bandwidth).\n\n- **Open multiple TCP sessions**: if your application requires high throughput,\n you can eventually saturate the single transmission control protocol (TCP)\n session that underlies a normal NFS and SMB session. For such cases, increase\n the number of TCP sessions your NFS and SMB connection uses.\n\n Use one of the following tabs to adjust your client based on the type of\n client: \n\n ### Linux\n\n Traditionally, an NFS client uses a single TCP session for all\n NFS-mounted file systems that share a storage endpoint. Using the\n [`nconnect` mount option](https://man7.org/linux/man-pages/man5/nfs.5.html)\n lets you increase the number of supported TCP sessions up to a maximum\n of 16.\n\n We recommend the following best practices for adjusting your Linux client\n type to fully take advantage of `nconnect`:\n - **Increase the number of TCP sessions with `nconnect`**: Each\n additional TCP session adds a queue for 128 outstanding requests,\n improving potential concurrency.\n\n - **Set `sunrpc.max_tcp_slot_table_entries` parameter** :\n `sunrpc.max_tcp_slot_table_entries` is a connection-level adjustment\n parameter which you can modify to control performance. We recommend\n setting `sunrpc.max_tpc_slot_table_enteries` to 128 requests or per\n connection and not surpassing 10,000 slots for all NFS clients within\n a single project connecting to NetApp Volumes. To set the\n `sunrpc.max_tcp_slot_table_entries` parameter, add the parameter to\n your `/etc/sysctl.conf` file and reload the parameter file using the\n `sysctl -p` command.\n\n - **Tune maximum supported value per session to 180** : Unlike NFSv3,\n NFSv4.1 clients define the relationship between the client and server\n in sessions. While NetApp Volumes supports up to 128\n outstanding requests per connection using NFSv3, NFSv4.1 is limited to\n 180 outstanding requests per session. Linux NFSv4.1 clients default to\n `64 max_session_slots` per session but you can tune this value as\n needed. We recommend changing the maximum supported value per session\n to 180.\n\n To tune `max_session_slots`, create a configuration file under\n `/etc/modprobe.d`. Make sure that no quotation marks (\" \") appear\n inline. Otherwise, the option doesn't take effect. \n\n $ echo \"options nfs max_session_slots=180\" \u003e /etc/modprobe/d/nfsclient/conf\n $ reboot\n\n Use the systool -v -m nfs command to see the current maximum in use\n by the client. For the command to work, at least one NFSv4.1 mount\n must be in place.\n\n $ systool -v -v nfs\n {\n Module = \"nfs\"\n ...\n Parameters:\n ...\n Max_session_slots = \"63\" \u003c-\n ...\n }\n\n The following NFS `nconnect` comparison graph demonstrates the impact\n using the nconnect configuration can have on an NFS workload. This\n information was captured using Fio with the following settings:\n - 100% read workload\n\n - 8 KiB block size against a single volume\n\n - `n2-standard-32` virtual machine using Red Hat 9 OS\n\n - 6 TiB working set\n\n Using an `nconnect` value of 16 resulted in five times more performance\n than when it wasn't enabled.\n\n ### Windows\n\n For Windows-based clients, the client can use [SMB Multichannel](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn610980(v=ws.11))\n with Receive Side Scaling (RSS) to open multiple TCP connections. To\n achieve this configuration, your virtual machine must have an allocated\n network adapter that supports RSS. We recommend setting RSS to four or\n eight values, however, any value over one should increase throughput.\n\n The following graph displays the difference using the RSS configuration\n can have on an SMB workload. This information was captured using Fio with\n the following settings:\n - 100% read workload\n\n - 8 KiB block size against a single volume\n\n - Single `n2-standard-32` virtual machine running a Windows 2022 OS\n\n - 6 TiB working set\n\n Eight jobs were run with only the SMB client RSS option changing between\n test executions. Using RSS values of 4, 8, and 16 increased performance\n two-fold when compared to using a value of 1. Each RSS instance was run\n nine times with a `numjobs` parameter of 8. The `iodepth` parameter was\n increased by five each execution until maximum throughput was reached.\n\nWhat's next\n-----------\n\nRead about [storage pools](/netapp/volumes/docs/configure-and-use/storage-pools/overview)."]]
