Vous pouvez optimiser les performances en ajustant les paramètres de volume suivants:
Augmenter la capacité de volume: vous pouvez augmenter la capacité de votre volume de niveau de service Premium, Extreme ou Standard pour améliorer le débit de volume maximal possible. Pour les volumes du niveau de service Flex, augmentez plutôt la capacité des pools de stockage.
Passer à un niveau de service supérieur: vous pouvez passer de votre niveau de service Premium au niveau de service Extreme pour améliorer le débit. Nous vous recommandons d'attribuer le volume à un autre pool de stockage avec un autre niveau de service.
L'augmentation de la capacité de volume et la mise à niveau des niveaux de service ne perturbent pas les charges de travail d'E/S en cours sur le volume et n'affectent en rien l'accès au volume.
Ajuster le client
Vous pouvez améliorer les performances en ajustant les paramètres suivants sur le client:
Colocaliser les clients: les résultats de latence sont directement affectés par les fonctionnalités et l'emplacement du client. Pour de meilleurs résultats, placez le client dans la même région que le volume ou aussi près que possible. Testez l'impact zonal en testant la latence d'un client dans chaque zone et utilisez la zone avec la latence la plus faible.
Configurer la bande passante réseau Compute Engine: les fonctionnalités réseau des machines virtuelles Compute Engine dépendent du type d'instance utilisé. En règle générale, les instances plus importantes peuvent générer un débit réseau plus élevé. Nous vous recommandons de sélectionner une machine virtuelle cliente avec une capacité de bande passante réseau appropriée, de sélectionner l'interface réseau gVNIC (Google Virtual NIC) et d'activer les performances Tier_1. Pour en savoir plus, consultez la documentation Compute Engine sur la bande passante réseau.
Ouverture de plusieurs sessions TCP: si votre application nécessite un débit élevé, vous pouvez finir par saturer la seule session TCP (Transmission Control Protocol) sous-jacente à une session NFS et SMB normale. Dans ce cas, augmentez le nombre de sessions TCP utilisées par votre connexion NFS et SMB.
Utilisez l'un des onglets suivants pour ajuster votre client en fonction du type de client:
Linux
Traditionnellement, un client NFS utilise une seule session TCP pour tous les systèmes de fichiers installés NFS qui partagent un point de terminaison de stockage. L'utilisation de l'option d'installation nconnect vous permet d'augmenter le nombre de sessions TCP compatibles jusqu'à 16 maximum.
Nous vous recommandons de suivre les bonnes pratiques suivantes pour ajuster le type de client Linux afin de profiter pleinement de nconnect:
Augmentez le nombre de sessions TCP avec nconnect: chaque session TCP supplémentaire ajoute une file d'attente pour 128 requêtes en attente, ce qui améliore la simultanéité potentielle.
Définir le paramètre sunrpc.max_tcp_slot_table_entries : sunrpc.max_tcp_slot_table_entries est un paramètre d'ajustement au niveau de la connexion que vous pouvez modifier pour contrôler les performances. Nous vous recommandons de définir sunrpc.max_tpc_slot_table_enteries sur 128 requêtes ou par connexion,et de ne pas dépasser 10 000 emplacements pour tous les clients NFS d'un même projet se connectant à des volumes NetApp. Pour définir le paramètre sunrpc.max_tcp_slot_table_entries, ajoutez-le à votre fichier /etc/sysctl.conf et rechargez le fichier de paramètres à l'aide de la commande sysctl -p.
Définir la valeur maximale prise en charge par session sur 180: contrairement à NFSv3, les clients NFSv4.1 définissent la relation entre le client et le serveur dans les sessions. Bien que NetApp Volumes accepte jusqu'à 128 requêtes en attente par connexion à l'aide de NFSv3, NFSv4.1 est limité à 180 requêtes en attente par session. Les clients Linux NFSv4.1 utilisent par défaut 64 max_session_slots par session, mais vous pouvez ajuster cette valeur si nécessaire. Nous vous recommandons de définir la valeur maximale prise en charge par session sur 180.
Pour régler max_session_slots, créez un fichier de configuration sous /etc/modprobe.d. Assurez-vous qu'aucun guillemet (" ") n'apparaît en ligne. Sinon, l'option ne s'applique pas.
Le graphique de comparaison nconnect NFS suivant illustre l'impact de l'utilisation de la configuration nconnect sur une charge de travail NFS. Ces informations ont été collectées à l'aide de Fio avec les paramètres suivants:
Charge de travail 100% lecture
Taille de bloc de 8 Ko sur un seul volume
Machine virtuelle n2-standard-32 utilisant l'OS Red Hat 9
Ensemble de travail de 6 Tio
L'utilisation d'une valeur nconnect de 16 a permis d'obtenir des performances cinq fois supérieures à celles obtenues lorsqu'elle n'était pas activée.
Windows
Pour les clients Windows, le client peut utiliser SMB Multichannel avec RSS (Receive Side Scaling) pour ouvrir plusieurs connexions TCP. Pour obtenir cette configuration, votre machine virtuelle doit disposer d'une carte réseau allouée compatible avec RSS. Nous vous recommandons de définir RSS sur quatre ou huit valeurs. Toutefois, toute valeur supérieure à un devrait augmenter le débit.
Le graphique suivant montre l'impact de la configuration RSS sur une charge de travail SMB. Ces informations ont été collectées à l'aide de Fio avec les paramètres suivants:
Charge de travail 100% lecture
Taille de bloc de 8 Ko sur un seul volume
Une seule machine virtuelle n2-standard-32 exécutant un OS Windows 2022
Ensemble de travail de 6 Tio
Huit tâches ont été exécutées, et seule l'option RSS du client SMB a changé entre les exécutions de test. L'utilisation de valeurs RSS de 4, 8 et 16 a doublé les performances par rapport à l'utilisation d'une valeur de 1. Chaque instance RSS a été exécutée neuf fois avec un paramètre numjobs de 8. Le paramètre iodepth a été augmenté de cinq à chaque exécution jusqu'à ce que le débit maximal soit atteint.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]
