Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite erfahren Sie, wie Sie die Leistung von Google Cloud NetApp-Volumes optimieren können.
Hinweise
Bevor Sie Änderungen an Ihren Volumes vornehmen, um die Leistung zu optimieren, sollten Sie sich die Leistungsüberlegungen ansehen.
Lautstärkeeinstellungen anpassen
Sie können die Leistung optimieren, indem Sie die folgenden Lautstärkeeinstellungen anpassen:
Volumekapazität erhöhen: Sie können die Kapazität Ihres Volumes mit dem Service Level „Premium“, „Extreme“ oder „Standard“ erhöhen, um den maximal erreichbaren Volume-Durchsatz zu verbessern. Erhöhen Sie stattdessen die Kapazität der Speicherpools für Volumes mit dem Service-Level „Flex“.
Servicelevel upgraden: Sie können die Speicherplatzmengen Ihres Premium-Servicelevels auf das Extreme-Servicelevel umstellen, um den Durchsatz zu verbessern. Wir empfehlen, das Volume einem anderen Speicherpool mit einer anderen Dienstebene zuzuweisen.
Die Erhöhung der Speicherkapazität und die Aufrüstung der Dienstebenen wirken sich nicht auf die laufenden I/O-Arbeitslasten auf dem Volume aus und haben keinerlei Auswirkungen auf den Zugriff auf das Volume.
Client anpassen
Sie können die Leistung verbessern, indem Sie die folgenden Einstellungen auf dem Client anpassen:
Clients an einem Ort platzieren: Die Latenzergebnisse werden direkt von den Funktionen und dem Standort des Clients beeinflusst. Die besten Ergebnisse erzielen Sie, wenn Sie den Client in derselben Region wie das Volume platzieren oder so nah wie möglich daran. Testen Sie die Auswirkungen auf die einzelnen Zonen, indem Sie die Latenz von einem Client in jeder Zone messen und die Zone mit der niedrigsten Latenz verwenden.
Compute Engine-Netzwerkbandbreite konfigurieren: Die Netzwerkfunktionen von Compute Engine-VMs hängen vom verwendeten Instanztyp ab. In der Regel können größere Instanzen einen höheren Netzwerkdurchsatz erzielen. Wir empfehlen, eine Client-VM mit einer geeigneten Netzwerkbandbreite auszuwählen, die Netzwerkschnittstelle Google Virtual NIC (gVNIC) auszuwählen und die Tier_1-Leistung zu aktivieren. Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Netzwerkbandbreite.
Mehrere TCP-Sitzungen öffnen: Wenn Ihre Anwendung einen hohen Durchsatz erfordert, kann die einzelne TCP-Sitzung (Transmission Control Protocol), die einer normalen NFS- und SMB-Sitzung zugrunde liegt, überlastet werden. Erhöhen Sie in solchen Fällen die Anzahl der TCP-Sitzungen, die Ihre NFS- und SMB-Verbindung verwendet.
Verwenden Sie einen der folgenden Tabs, um den Client entsprechend dem Clienttyp anzupassen:
Linux
Traditionell verwendet ein NFS-Client eine einzelne TCP-Sitzung für alle NFS-gemounteten Dateisysteme, die einen gemeinsamen Speicherendpunkt nutzen. Mit der Bereitstellungsoption nconnect können Sie die Anzahl der unterstützten TCP-Sitzungen auf maximal 16 erhöhen.
Wir empfehlen die folgenden Best Practices für die Anpassung des Linux-Clienttyps, um nconnect optimal zu nutzen:
Anzahl der TCP-Sitzungen mit nconnect erhöhen: Jede zusätzliche TCP-Sitzung fügt eine Warteschlange für 128 ausstehende Anfragen hinzu, wodurch die potenzielle Parallelität verbessert wird.
Parameter sunrpc.max_tcp_slot_table_entries festlegen:sunrpc.max_tcp_slot_table_entries ist ein Anpassungsparameter auf Verbindungsebene, den Sie ändern können, um die Leistung zu steuern. Wir empfehlen, sunrpc.max_tpc_slot_table_enteries auf 128 Anfragen oder pro Verbindung festzulegen und 10.000 Slots für alle NFS-Clients in einem einzelnen Projekt nicht zu überschreiten, die eine Verbindung zu NetApp-Volumes herstellen. Wenn Sie den Parameter sunrpc.max_tcp_slot_table_entries festlegen möchten, fügen Sie ihn der Datei /etc/sysctl.conf hinzu und laden Sie die Parameterdatei mit dem Befehl sysctl -p neu.
Maximal unterstützten Wert pro Sitzung auf 180 festlegen: Im Gegensatz zu NFSv3 definieren NFSv4.1-Clients die Beziehung zwischen Client und Server in Sitzungen. NetApp Volumes unterstützt mit NFSv3 bis zu 128 ausstehende Anfragen pro Verbindung, während NFSv4.1 auf 180 ausstehende Anfragen pro Sitzung beschränkt ist. Linux NFSv4.1-Clients verwenden standardmäßig 64 max_session_slots pro Sitzung. Sie können diesen Wert jedoch nach Bedarf anpassen. Wir empfehlen, den maximal unterstützten Wert pro Sitzung auf 180 zu ändern.
Wenn Sie max_session_slots optimieren möchten, erstellen Sie eine Konfigurationsdatei unter /etc/modprobe.d. Achten Sie darauf, dass keine Anführungszeichen (" ") in den Textzeilen stehen. Andernfalls wird die Option nicht aktiviert.
Das folgende NFS-nconnect-Vergleichsdiagramm zeigt die Auswirkungen der Verwendung der nconnect-Konfiguration auf eine NFS-Arbeitslast. Diese Informationen wurden mit Fio mit den folgenden Einstellungen erfasst:
Arbeitslast mit 100% Lesezugriffen
Blockgröße von 8 KiB für ein einzelnes Volume
n2-standard-32 virtuelle Maschine mit Red Hat 9-Betriebssystem
6 TiB Arbeitsspeicher
Mit einem nconnect-Wert von 16 wurde eine fünfmal höhere Leistung erzielt als ohne Aktivierung.
Windows
Windows-basierte Clients können SMB Multichannel mit Receive Side Scaling (RSS) verwenden, um mehrere TCP-Verbindungen zu öffnen. Für diese Konfiguration muss Ihrer virtuellen Maschine ein Netzwerkadapter zugewiesen sein, der RSS unterstützt. Wir empfehlen, RSS auf vier oder acht Werte festzulegen. Jeder Wert über 1 sollte den Durchsatz erhöhen.
Das folgende Diagramm zeigt den Unterschied, den die RSS-Konfiguration auf eine SMB-Arbeitslast haben kann. Diese Informationen wurden mit Fio mit den folgenden Einstellungen erfasst:
Arbeitslast mit 100% Lesezugriffen
Blockgröße von 8 KiB für ein einzelnes Volume
Einzelne n2-standard-32-virtuelle Maschine mit Windows 2022
6 TiB Arbeitsspeicher
Es wurden acht Jobs ausgeführt, wobei sich zwischen den Testausführungen nur die SMB-Client-RSS-Option änderte. Mit RSS-Werten von 4, 8 und 16 konnte die Leistung im Vergleich zu einem Wert von 1 verdoppelt werden. Jede RSS-Instanz wurde neunmal mit einem numjobs-Parameter von 8 ausgeführt. Der Parameter iodepth wurde bei jeder Ausführung um fünf erhöht, bis der maximale Durchsatz erreicht wurde.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-03 (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)."]]
