Puoi ottimizzare le prestazioni regolando le seguenti impostazioni del volume:
Aumenta la capacità del volume: puoi aumentare la capacità del volume del livello di servizio Premium, Extreme o Standard per migliorare il throughput massimo del volume. Per i volumi del livello di servizio Flex, aumenta invece la capacità dei pool di archiviazione.
Esegui l'upgrade del livello di servizio: puoi eseguire l'upgrade dei volumi con livello di servizio Premium al livello di servizio Extreme per migliorare il throughput. Ti consigliamo di assegnare il volume a un pool di archiviazione diverso con un livello di servizio diverso.
L'aumento della capacità del volume e l'upgrade dei livelli di servizio non influiscono sul caricamento delle attività I/O in esecuzione sul volume e non influiscono in alcun modo sull'accesso al volume.
Modificare il client
Puoi migliorare il rendimento modificando le seguenti impostazioni sul client:
Posiziona i client in modo da raggrupparli: i risultati della latenza sono direttamente influenzati dalle funzionalità e dalla posizione del client. Per risultati ottimali, posiziona il client nella stessa regione del volume o il più vicino possibile. Verifica l'impatto a livello di zona testando la latenza da un client in ogni zona e utilizza la zona con la latenza più bassa.
Configura la larghezza di banda di rete di Compute Engine: le funzionalità di rete delle macchine virtuali Compute Engine dipendono dal tipo di istanza utilizzato. In genere, le istanze più grandi possono aumentare il throughput della rete. Ti consigliamo di selezionare una macchina virtuale client con una larghezza di banda di rete appropriata, selezionare l'interfaccia di rete Google Virtual NIC (gVNIC) e attivare le prestazioni Tier_1. Per ulteriori informazioni, consulta la documentazione di Compute Engine sulla larghezza di banda della rete.
Apri più sessioni TCP: se la tua applicazione richiede un throughput elevato, potresti saturare la singola sessione TCP (Transmission Control Protocol) alla base di una normale sessione NFS e SMB. In questi casi, aumenta il numero di sessioni TCP utilizzate dalla connessione NFS e SMB.
Utilizza una delle seguenti schede per modificare il client in base al tipo di
client:
Linux
Tradizionalmente, un client NFS utilizza una singola sessione TCP per tutti
i file system montati NFS che condividono un endpoint di archiviazione. L'utilizzo dell'opzione di montaggio nconnect consente di aumentare il numero di sessioni TCP supportate fino a un massimo di 16.
Ti consigliamo le seguenti best practice per modificare il tipo di client Linux per sfruttare appieno nconnect:
Aumenta il numero di sessioni TCP con nconnect: ogni sessione TCP aggiuntiva aggiunge una coda per 128 richieste in attesa, migliorando la potenziale concorrenza.
Imposta il parametro sunrpc.max_tcp_slot_table_entries:
sunrpc.max_tcp_slot_table_entries è un parametro di aggiustamento a livello di connessione
che puoi modificare per controllare le prestazioni. Ti consigliamo di impostare sunrpc.max_tpc_slot_table_enteries su 128 richieste o per connessione e di non superare i 10.000 slot per tutti i client NFS all'interno di un singolo progetto che si connette ai volumi NetApp. Per impostare il parametro sunrpc.max_tcp_slot_table_entries, aggiungilo al file /etc/sysctl.conf e ricarica il file dei parametri utilizzando il comando sysctl -p.
Imposta il valore massimo supportato per sessione su 180: a differenza di NFSv3,
i client NFSv4.1 definiscono la relazione tra il client e il server
nelle sessioni. Sebbene NetApp Volumes supporti fino a 128 richieste in sospeso per connessione utilizzando NFSv3, NFSv4.1 è limitato a 180 richieste in sospeso per sessione. Per impostazione predefinita, i client NFSv4.1 Linux hanno un valore di 64 max_session_slots per sessione, ma puoi ottimizzare questo valore in base alle tue esigenze. Ti consigliamo di modificare il valore massimo supportato per sessione impostandolo su 180.
Per ottimizzare max_session_slots, crea un file di configurazione in /etc/modprobe.d. Assicurati che non vengano visualizzate virgolette (" ") in linea. In caso contrario, l'opzione non viene applicata.
Il seguente grafico di confronto nconnect NFS mostra l'impatto che l'utilizzo della configurazione nconnect può avere su un carico di lavoro NFS. Queste informazioni sono state acquisite utilizzando Fio con le seguenti impostazioni:
Workload di lettura al 100%
Dimensione del blocco di 8 KiB rispetto a un singolo volume
Macchina virtuale n2-standard-32 che utilizza il sistema operativo Red Hat 9
Set di lavoro di 6 TiB
L'utilizzo di un valore nconnect pari a 16 ha generato un rendimento cinque volte superiore rispetto a quando non era attivato.
Windows
Per i client basati su Windows, il client può utilizzare SMB Multichannel con RSS (Receive Side Scaling) per aprire più connessioni TCP. Per
ottenere questa configurazione, la macchina virtuale deve avere un adattatore di rete allocato che supporti RSS. Ti consigliamo di impostare RSS su quattro o acht valori, tuttavia qualsiasi valore superiore a 1 dovrebbe aumentare il throughput.
Il seguente grafico mostra la differenza che l'utilizzo della configurazione RSS può avere su un carico di lavoro SMB. Queste informazioni sono state acquisite utilizzando Fio con
le seguenti impostazioni:
Workload di lettura al 100%
Dimensione del blocco di 8 KiB rispetto a un singolo volume
Singola macchina virtuale n2-standard-32 che esegue un sistema operativo Windows 2022
Set di lavoro di 6 TiB
Sono stati eseguiti otto job con solo l'opzione RSS del client SMB che variava tra un'esecuzione di test e l'altra. L'utilizzo di valori RSS pari a 4, 8 e 16 ha raddoppiato il rendimento rispetto all'utilizzo di un valore pari a 1. Ogni istanza RSS è stata eseguita
nove volte con un parametro numjobs pari a 8. Il parametro iodepth è stato incrementato di cinque a ogni esecuzione fino al raggiungimento della velocità in uscita massima.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]
