Leistung optimieren

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 Umstellung der Dienstebenen wirken sich nicht auf laufende 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 nicht mehr als 10.000 Slots für alle NFS-Clients in einem einzelnen Projekt zu verwenden, 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 (" ") inline erscheinen. Andernfalls wird die Option nicht aktiviert.

      $ echo "options nfs max_session_slots=180" > /etc/modprobe/d/nfsclient/conf
$ reboot

Use the systool -v -m nfs command to see the current maximum in use
by the client. For the command to work, at least one NFSv4.1 mount
must be in place.

$ systool -v -v nfs
{
Module = "nfs"
…
Parameters:
…
Max_session_slots = "63" <-
…
}

    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.

    NFS-nconnect-Vergleich mit einer einzelnen Red Hat 9-VM mit einer Blockgröße von 8 KiB.

    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.

    SMB-RSS-Vergleich einer einzelnen Windows 2022-VM mit einer Blockgröße von 8 KiB

Nächste Schritte

Weitere Informationen zu Speicherpools