Para optimizar el rendimiento, puedes ajustar los siguientes parámetros de volumen:
Aumentar la capacidad del volumen: Puedes aumentar la capacidad de tu volumen de nivel de servicio Premium, Extreme o Estándar para mejorar la capacidad de procesamiento máxima que se puede lograr. En el caso de los volúmenes del nivel de servicio Flex, aumenta la capacidad de los grupos de almacenamiento.
Actualiza tu nivel de servicio: Puedes actualizar tus volúmenes del nivel de servicio Premium al nivel de servicio Extreme para mejorar la capacidad de procesamiento. Te recomendamos que asignes el volumen a un grupo de almacenamiento diferente con un nivel de servicio diferente.
El aumento de la capacidad del volumen y la actualización de los niveles de servicio no interrumpen las cargas de trabajo de E/S en proceso en el volumen ni afectan el acceso al volumen de ninguna manera.
Cómo ajustar el cliente
Para mejorar el rendimiento, ajusta los siguientes parámetros de configuración en el cliente:
Colocaliza los clientes: Los resultados de latencia se ven afectados directamente por las capacidades y la ubicación del cliente. Para obtener los mejores resultados, coloca el cliente
en la misma región que el volumen o lo más cerca posible. Para probar el impacto de la zona, prueba la latencia de un cliente en cada zona y usa la zona con la latencia más baja.
Configura el ancho de banda de la red de Compute Engine: Las capacidades de red de las máquinas virtuales de Compute Engine dependen del tipo de instancia que se usa. Por lo general,
las instancias más grandes pueden generar más rendimiento de red. Te recomendamos que selecciones una máquina virtual cliente con una capacidad de ancho de banda de red adecuada, selecciones la interfaz de red de la NIC virtual de Google (gVNIC) y habilites el rendimiento de Tier_1. Para obtener más información, consulta la documentación de Compute Engine sobre el ancho de banda de red.
Abrir varias sesiones TCP: Si tu aplicación requiere una alta capacidad de procesamiento, con el tiempo, puedes saturar la única sesión del protocolo de control de transmisión (TCP) que subyace a una sesión normal de NFS y SMB. En esos casos, aumenta
la cantidad de sesiones TCP que usa tu conexión NFS y SMB.
Usa una de las siguientes pestañas para ajustar el cliente según el tipo de cliente:
Linux
Tradicionalmente, un cliente NFS usa una sola sesión TCP para todos los sistemas de archivos activados de NFS que comparten un extremo de almacenamiento. El uso de la opción de activación nconnect te permite aumentar la cantidad de sesiones TCP admitidas hasta un máximo de 16.
Te recomendamos que sigas las siguientes prácticas recomendadas para ajustar el tipo de cliente de Linux y aprovechar nconnect por completo:
Aumenta la cantidad de sesiones TCP con nconnect: Cada sesión TCP adicional agrega una cola para 128 solicitudes pendientes, lo que mejora la simultaneidad potencial.
Establece el parámetro sunrpc.max_tcp_slot_table_entries: sunrpc.max_tcp_slot_table_entries es un parámetro de ajuste a nivel de la conexión que puedes modificar para controlar el rendimiento. Te recomendamos que configures sunrpc.max_tpc_slot_table_enteries en 128 solicitudes o por conexión y que no superes las 10,000 ranuras para todos los clientes de NFS en un solo proyecto que se conecte a volúmenes de NetApp. Para configurar el parámetro sunrpc.max_tcp_slot_table_entries, agrégalo a tu archivo /etc/sysctl.conf y vuelve a cargarlo con el comando sysctl -p.
Ajusta el valor máximo admitido por sesión a 180: A diferencia de NFSv3, los clientes de NFSv4.1 definen la relación entre el cliente y el servidor en las sesiones. Si bien NetApp Volumes admite hasta 128 solicitudes pendientes por conexión con NFSv3, NFSv4.1 se limita a 180 solicitudes pendientes por sesión. Los clientes NFSv4.1 de Linux usan 64 max_session_slots de forma predeterminada por sesión, pero puedes ajustar este valor según sea necesario. Te recomendamos que cambies el valor máximo admitido por sesión a 180.
Para ajustar max_session_slots, crea un archivo de configuración en /etc/modprobe.d. Asegúrate de que no aparezcan comillas (" ") intercaladas. De lo contrario, la opción no tendrá efecto.
En el siguiente gráfico de comparación de nconnect de NFS, se muestra el impacto que puede tener el uso de la configuración de nconnect en una carga de trabajo de NFS. Esta información se capturó con Fio con la siguiente configuración:
Carga de trabajo de lectura del 100%
Tamaño de bloque de 8 KiB en un solo volumen
Máquina virtual n2-standard-32 con el SO Red Hat 9
Conjunto de tareas de 6 TiB
El uso de un valor nconnect de 16 generó un rendimiento cinco veces mayor que cuando no estaba habilitado.
Windows
En el caso de los clientes basados en Windows, el cliente puede usar SMB multicanal con escalamiento del lado receptor (RSS) para abrir varias conexiones TCP. Para lograr esta configuración, tu máquina virtual debe tener un adaptador de red asignado que admita RSS. Te recomendamos que configures RSS en cuatro o ocho valores. Sin embargo, cualquier valor superior a uno debería aumentar la capacidad de procesamiento.
En el siguiente gráfico, se muestra la diferencia que puede tener la configuración de RSS en una carga de trabajo de SMB. Esta información se capturó con Fio con la siguiente configuración:
Carga de trabajo de lectura del 100%
Tamaño de bloque de 8 KiB en un solo volumen
Máquina virtual n2-standard-32 única que ejecuta un SO Windows 2022
Conjunto de tareas de 6 TiB
Se ejecutaron ocho trabajos con solo la opción de RSS del cliente SMB que cambiaba entre las ejecuciones de prueba. El uso de valores de RSS de 4, 8 y 16 aumentó el rendimiento al doble en comparación con el uso de un valor de 1. Cada instancia de RSS se ejecutó nueve veces con un parámetro numjobs de 8. El parámetro iodepth se incrementó en cinco en cada ejecución hasta que se alcanzó la capacidad de procesamiento máxima.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)."]]
