Best Practices für die Leistungsoptimierung

In diesem Dokument finden Sie eine Anleitung, wie Sie Cloud Storage FUSE mithilfe wichtiger Cloud Storage FUSE-Features und -Konfigurationen verbessern können, um einen maximalen Durchsatz und eine optimale Leistung zu erzielen, insbesondere für Arbeitslasten im Bereich künstliche Intelligenz und maschinelles Lernen (KI/ML) wie Training, Bereitstellung und Prüfpunkte.

Hinweise

Bevor Sie die auf dieser Seite empfohlenen Konfigurationen anwenden, sollten Sie Folgendes beachten:

• Sie können die empfohlenen Konfigurationen auf dieser Seite mit den folgenden Methoden anwenden:

  • Cloud Storage FUSE-Feld profile oder Option --profile, mit der Einstellungen für KI/ML-Training, Prüfpunkte oder Bereitstellungsarbeitslasten automatisch konfiguriert werden, wenn sie verwendet werden.

  • Cloud Storage FUSE-Konfigurationsdatei

  • Cloud Storage FUSE-CLI

  • Nur für Google Kubernetes Engine: Google Kubernetes Engine-YAML-Beispieldateien

• Prüfen Sie, ob Sie die aktuelle Version von Cloud Storage FUSE verwenden. Die empfohlenen Konfigurationen sollten nur auf Cloud Storage FUSE-Version 3.0 oder höher und den Cloud Storage FUSE-CSI-Treiber für die Google Kubernetes Engine angewendet werden, der auf GKE-Clustern der Version 1.32.2-gke.1297001 oder höher ausgeführt wird.

• Bei den empfohlenen Konfigurationen werden Cloud Storage-Metadaten für die Dauer des Jobs im Cache gespeichert und nach dem ersten Bereitstellen des Dateisystems nicht mehr geprüft. Daher empfehlen wir, dass das Dateisystem schreibgeschützt ist oder die Dateisystemsemantik write-to-new-Anwendungen verwendet, d. h. Anwendungen schreiben immer in neue Dateien, um eine optimale Leistung zu erzielen. Die folgenden KI-/ML-Arbeitslasten sind „Write-to-New“:

  • Prüfpunkte

  • Training

  • Bereitstellung

  • jax.jit()-Caching

• Die empfohlenen Konfigurationen auf dieser Seite wurden für Cloud-GPUs und große Cloud TPU-Maschinentypen in großem Umfang validiert, bei denen eine große Menge an Arbeitsspeicher und eine Netzwerkschnittstelle mit hoher Bandbreite vorhanden sind. Cloud-GPUs und Cloud TPU-Maschinentypen können sich hinsichtlich der Anzahl der verfügbaren Ressourcen wie CPU, Arbeitsspeicher und lokaler Speicher in ihrer Hostknotenkonfiguration unterscheiden. Dies kann sich direkt auf die Leistung von Konfigurationen wie den folgenden auswirken:

  • A3 Ultra

  • A3 Mega: 1,8 TiB Arbeitsspeicher, mit 6 TiB LSSD

  • Cloud TPU v5e: 188 GiB Speicher, ohne LSSD

  • Cloud TPU v5p: 448 GiB Arbeitsspeicher, ohne LSSD

  • Cloud TPU v6e (Trillium) – 1,5 TiB Arbeitsspeicher, ohne LSSD

  • Cloud TPU 7x (Ironwood) – 1,1 TiB Arbeitsspeicher, ohne LSSD

Unterstützung für Rapid-Buckets

Ab Version 3.7.1 unterstützt Cloud Storage FUSE Rapid Bucket mit optimiertem Lesepfad.

Der optimierte Lesepfad verbessert die Leistung erheblich, da standardmäßig der Read-Ahead-Algorithmus des Linux-Kernels verwendet wird. Damit dieser optimierte Lesepfad verwendet werden kann, sind bestimmte Konfigurationsänderungen auf Maschinenebene für die Parameter read_ahead_kb, max_background und congestion_threshold erforderlich. In Google Kubernetes Engine-Umgebungen (GKE), die den Cloud Storage FUSE-CSI-Treiber verwenden, werden diese Konfigurationen vollständig verwaltet und automatisch angewendet. Für Compute Engine-VMs und andere Nicht-GKE-Umgebungen benötigt Cloud Storage FUSE die Berechtigungen sudo, um diese Änderungen automatisch anzuwenden. Alternativ müssen Sie diese Parameter manuell konfigurieren.

Beachten Sie bei der Verwendung des optimierten Lesepfads für Rapid Bucket die folgenden Verhaltensweisen und Einschränkungen:

• Kompatibilität mit Dateicache und gepuffertem Reader: Da der optimierte Lesepfad auf dem Read-Ahead-Algorithmus des Kernels basiert, ist er nicht mit dem Dateicache und dem gepufferten Reader von Cloud Storage FUSE kompatibel. Standardmäßig sind diese Funktionen für Rapid Bucket inaktiv (No-Op). Wenn für Ihre Arbeitslast der Dateicache oder der gepufferte Reader erforderlich ist, müssen Sie den Kernel-Reader explizit deaktivieren, indem Sie beim Mounten enable-kernel-reader: false festlegen. Dadurch verwendet Cloud Storage FUSE den Standardlesepfad, der mit Dateicaching und gepufferten Lesevorgängen kompatibel ist.
• Anforderungen für die Einbindung:Der neue Lesepfad wird nur für statische Einbindungen unterstützt. Bei Verwendung der dynamischen Bereitstellung wird dies nicht unterstützt.

Buckets mit aktiviertem hierarchischen Namespace verwenden

Verwenden Sie immer Buckets mit aktiviertem hierarchischen Namespace. Mit dem hierarchischen Namespace werden Ihre Daten in einer hierarchischen Dateisystemstruktur organisiert. Das macht Vorgänge im Bucket effizienter, was zu schnelleren Antwortzeiten und weniger List-Aufrufen für jeden Vorgang führt.

Der hierarchische Namespace bietet unter anderem folgende Vorteile:

• Buckets mit hierarchischem Namespace bieten bis zu achtmal mehr anfängliche Abfragen pro Sekunde (QPS) im Vergleich zu flachen Buckets. Der hierarchische Namespace unterstützt 40.000 Anfragen zum Lesen von Objekten pro Sekunde und 8.000 Anfragen zum Schreiben von Objekten pro Sekunde. Das ist deutlich mehr als bei typischen Cloud Storage FUSE-Buckets, die anfangs nur 5.000 Anfragen zum Lesen von Objekten pro Sekunde und 1.000 Anfragen zum Schreiben von Objekten pro Sekunde bieten.

• Der hierarchische Namespace bietet atomare Verzeichnisumbenennungen, die für das Checkpointing mit Cloud Storage FUSE erforderlich sind, um die Atomarität zu gewährleisten. Die Verwendung von Buckets mit aktiviertem hierarchischen Namespace ist besonders vorteilhaft, wenn Sie Prüfpunkte in großem Umfang erstellen, da ML-Frameworks Verzeichnisumbenennungen verwenden, um Prüfpunkte abzuschließen. Dies ist ein schneller, atomarer Befehl, der nur in Buckets mit aktiviertem hierarchischen Namespace unterstützt wird. Wenn Sie keinen Bucket mit aktiviertem hierarchischen Namespace verwenden möchten, lesen Sie den Abschnitt Umbenennungslimit für Nicht-HNS-Buckets erhöhen.

Informationen zum Erstellen eines Buckets mit aktiviertem hierarchischen Namespace finden Sie unter Buckets mit aktiviertem hierarchischen Namespace erstellen. Informationen zum Bereitstellen eines Buckets mit aktiviertem hierarchischen Namespace finden Sie unter Buckets mit aktiviertem hierarchischen Namespace bereitstellen. Hierarchische Namespaces werden ab Google Kubernetes Engine-Version 1.31.1-gke.2008000 unterstützt.

Verzeichnisspezifische Bereitstellung durchführen

Wenn Sie auf ein bestimmtes Verzeichnis in einem Bucket zugreifen möchten, können Sie statt des gesamten Buckets nur das bestimmte Verzeichnis mit der Bereitstellungsoption only-dir bereitstellen. Durch das Ausführen einer verzeichnisspezifischen Bereitstellung werden Listenaufrufe beschleunigt und die Gesamtzahl der Listen- und Statistikaufrufe reduziert, da die Anzahl der Verzeichnisse, die beim Auflösen eines Dateinamens durchlaufen werden müssen, begrenzt wird. Das liegt daran, dass LookUpInode-Aufrufe und Zugriffsanfragen für Buckets oder Verzeichnisse automatisch Listen- und Statistikaufrufe für jede Datei oder jedes Verzeichnis im Pfad generieren.

Verwenden Sie eine der folgenden Methoden, um ein bestimmtes Verzeichnis einzubinden:

mountOptions:
    - only-dir:DIRECTORY_NAME

mountOptions: "OTHER_OPTIONS,only-dir:DIRECTORY_NAME"

gcsfuse --only-dir DIRECTORY_NAME BUCKET_NAME MOUNT_POINT

Weitere Informationen zum Bereitstellen eines Verzeichnisses finden Sie unter Verzeichnis in einem Bucket bereitstellen.

Metadaten-Cache-Werte erhöhen

Um die Leistung bei wiederholten Lesevorgängen zu verbessern, können Sie Cloud Storage FUSE so konfigurieren, dass eine große Menge an Metadaten im Cache gespeichert und das Ablaufen von Metadaten umgangen wird. Dadurch werden wiederholte Metadatenanfragen an Cloud Storage vermieden und die Leistung deutlich verbessert.

Das Erhöhen der Metadatencachewerte ist für Arbeitslasten mit wiederholten Lesevorgängen sinnvoll, um wiederholte Cloud Storage-Aufrufe zu vermeiden, und für Volumes mit Lesezugriff, für die eine unendliche TTL festgelegt werden kann.

Beachten Sie Folgendes, bevor Sie die Werte für den Metadaten-Cache erhöhen:

• Eine unendliche Gültigkeitsdauer (Time to Live, TTL) sollte nur für Volumes festgelegt werden, die entweder schreibgeschützt sind oder nur für neue Schreibvorgänge verwendet werden.

• Der Metadatencache sollte nur auf Knoten mit großen Speicherkonfigurationen aktiviert werden, da er alle Metadaten für den angegebenen Bereitstellungspunkt auf jedem Knoten im Cache speichert und zusätzliche Zugriffe auf Cloud Storage überflüssig macht.

• Mit den Konfigurationen in diesem Abschnitt werden alle aufgerufenen Metadaten mit einer unendlichen TTL im Cache gespeichert. Dies kann sich auf die Konsistenzgarantien auswirken, wenn Änderungen am selben Cloud Storage-Bucket von einem anderen Client vorgenommen werden, z. B. Überschreibungen oder Löschungen einer Datei.

• Prüfen Sie, ob die vom Metadaten-Cache verbrauchte Speichermenge für Sie akzeptabel ist. Diese kann bis zu Gigabyte groß sein und hängt von der Anzahl der Dateien in den bereitgestellten Buckets und der Anzahl der verwendeten Bereitstellungspunkte ab. Die Metadaten jeder Datei benötigen beispielsweise etwa 1,5 KiB Speicherplatz. Die Metadaten von einer Million Dateien benötigen also etwa 1,5 GiB Speicherplatz. Weitere Informationen finden Sie unter Caching – Übersicht.

So konfigurieren Sie Cloud Storage FUSE, um eine große Menge an Metadaten im Cache zu speichern und den Ablauf von Metadaten zu umgehen:

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

metadata-cache:
stat-cache-max-size-mb: -1
ttl-secs: -1

  mountOptions:
      - metadata-cache:ttl-secs:-1
      - metadata-cache:stat-cache-max-size-mb:-1

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

Metadaten-Cache vorab ausfüllen

Bevor Sie eine Arbeitslast ausführen, empfehlen wir, den Metadatencache vorab zu füllen. Dadurch wird die Leistung erheblich verbessert und die Anzahl der Metadatenaufrufe an Cloud Storage deutlich reduziert, insbesondere wenn das Feld implicit-dirs oder die Option --implicit-dirs verwendet wird. Der Cloud Storage FUSE-CSI-Treiber für GKE bietet eine API, die das Vorabfüllen des Metadatencaches übernimmt. Weitere Informationen finden Sie unter Metadaten-Prefetch zum Vorabfüllen des Metadatencaches verwenden.

Verwenden Sie eine der folgenden Methoden, um den Metadaten-Cache vorab auszufüllen:

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: training-bucket-pv
  spec:
    ...
    csi:
      volumeHandle: BUCKET_NAME
      volumeAttributes:
        ...
        gcsfuseMetadataPrefetchOnMount: "true"
  

ls -R MOUNT_POINT > /dev/null

ls -R MOUNT_POINT > /dev/null

Datei-Caching und parallele Downloads aktivieren

Mit dem Datei-Caching können Sie häufig aufgerufene Dateidaten lokal auf Ihrem Computer speichern. Dadurch werden wiederholte Lesevorgänge beschleunigt und die Cloud Storage-Kosten gesenkt. Wenn Sie das Datei-Caching aktivieren, werden automatisch auch parallele Downloads aktiviert. Bei parallelen Downloads werden mehrere Worker verwendet, um eine Datei parallel herunterzuladen. Dabei wird das Datei-Cache-Verzeichnis als Prefetch-Puffer verwendet, was zu einer neunmal schnelleren Ladezeit des Modells führt.

Informationen zum Aktivieren und Konfigurieren von Datei-Caching und parallelen Downloads finden Sie unter Caching-Verhalten aktivieren und konfigurieren. Eine Beispielkonfiguration finden Sie unter Beispielkonfiguration zum Aktivieren von Datei-Caching und parallelen Downloads.

Überlegungen zu Cloud GPUs und Cloud TPU für die Verwendung von Datei-Caching und parallelen Downloads

Der Datei-Cache kann auf lokalen SSDs, RAM, Persistent Disk oder Google Cloud Hyperdisk gehostet werden. Beachten Sie dazu die folgenden Hinweise. In allen Fällen müssen die Daten oder die einzelne große Datei in die verfügbare Kapazität des Dateicache-Verzeichnisses passen, das mit dem Feld max-size-mb oder der Option --file-cache-max-size-mb gesteuert wird.

Hinweise zu Cloud GPUs

Lokale SSDs eignen sich ideal für Trainingsdaten und Checkpoint-Downloads. Cloud GPU-Maschinentypen umfassen SSD-Kapazität, die verwendet werden kann, z. B. A4-Maschinentypen mit 12 TiB SSD.

• Eine RAM-Disk bietet die beste Leistung beim Laden von Modellgewichtungen, da sie im Vergleich zur ungenutzten RAM-Menge auf dem System klein ist.

• Sowohl Persistent Disk als auch Google Cloud Hyperdisk können als Cache verwendet werden.

Cloud TPU-Überlegungen

Cloud TPU unterstützt keine lokalen SSDs. Wenn Sie das Dateicaching auf Cloud TPU ohne Änderungen verwenden, ist der Standardspeicherort das Boot-Volume. Dies wird nicht empfohlen und führt zu einer schlechten Leistung.

Anstelle des Boot-Volumes empfehlen wir die Verwendung einer RAM-Disk, die aufgrund ihrer Leistung und der fehlenden zusätzlichen Kosten bevorzugt wird. Ein RAM-Laufwerk ist jedoch oft in der Größe begrenzt und eignet sich am besten für die Bereitstellung von Modellgewichtungen oder Prüfpunkt-Downloads, je nach Größe des Prüfpunkts und des verfügbaren RAM. Außerdem empfehlen wir die Verwendung von Persistent Disk und Google Cloud Hyperdisk für das Caching.

Beispielkonfiguration zum Aktivieren von Datei-Caching und parallelen Downloads

Standardmäßig wird für den Dateicache eine lokale SSD verwendet, wenn der ephemeral-storage-local-ssd-Modus für den Google Kubernetes Engine-Knoten aktiviert ist. Wenn keine lokale SSD verfügbar ist, z. B. auf Cloud TPU-Maschinen, verwendet der Dateicache das Bootlaufwerk des Google Kubernetes Engine-Knotens. Dies wird nicht empfohlen. In diesem Fall können Sie eine RAM-Festplatte als Cacheverzeichnis verwenden. Berücksichtigen Sie jedoch, wie viel RAM für das Zwischenspeichern von Dateien verfügbar ist und wie viel vom Pod benötigt wird.

gcsfuse --file-cache-max-size-mb=-1 \
      --file-cache-cache-file-for-range-read=true \
      --file-cache-enable-parallel-downloads=true \
      BUCKET_NAME

file-cache:
  max-size-mb: -1
  cache-file-for-range-read: true
  enable-parallel-downloads: true

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

# RAM disk file cache if LSSD not available. Uncomment to use
# volumes:
#   - name: gke-gcsfuse-cache
#     emptyDir:
#       medium: Memory

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

volumes:
    - name: gke-gcsfuse-cache
      emptyDir:
        medium: Memory

gcsfuse --file-cache-max-size-mb=-1 \
      --file-cache-cache-file-for-range-read=true \
      --file-cache-enable-parallel-downloads=true \
      BUCKET_NAME MOUNT_POINT

Negative Statistik-Cache-Einträge deaktivieren

Cloud Storage FUSE speichert standardmäßig negative Statistikeinträge, d. h. Einträge für nicht vorhandene Dateien, mit einer TTL von fünf Sekunden im Cache. Bei Arbeitslasten, bei denen Dateien häufig erstellt oder gelöscht werden, z. B. bei verteilten Prüfpunkten, können diese im Cache gespeicherten Einträge schnell veralten, was zu Leistungsproblemen führt. Um dies zu vermeiden, empfehlen wir, den negativen Statistik-Cache für Trainings-, Bereitstellungs- und Prüfpunkt-Arbeitslasten mit dem Feld negative-ttl-secs oder der Option --metadata-cache-negative-ttl-secs zu deaktivieren.

So deaktivieren Sie den Cache für negative Statistiken:

gcsfuse --metadata-cache-negative-ttl-secs=0 \
  BUCKET_NAME

metadata-cache:
 negative-ttl-secs: 0

mountOptions:
    - metadata-cache:negative-ttl-secs:0

gcsfuse --metadata-cache-negative-ttl-secs=0 \
  BUCKET_NAME MOUNT_POINT

Streaming-Schreibvorgänge aktivieren

Bei Streaming-Schreibvorgängen werden Daten direkt in Cloud Storage hochgeladen, während sie geschrieben werden. Dadurch werden die Latenz und die Speicherplatznutzung reduziert. Das ist besonders bei großen, sequenziellen Schreibvorgängen wie Checkpoints von Vorteil. Streaming-Schreibvorgänge sind in Cloud Storage FUSE ab Version 3.0 standardmäßig aktiviert.

Wenn Streaming-Schreibvorgänge nicht standardmäßig aktiviert sind, folgen Sie der Anleitung unten, um sie zu aktivieren. Für die Aktivierung von Streaming-Schreibvorgängen ist Cloud Storage FUSE Version 3.0 erforderlich, die in Google Kubernetes Engine-Versionen 1.32.1-gke.1729000 oder höher verfügbar ist.

gcsfuse --enable-streaming-writes=true \
  BUCKET_NAME

write:
 enable-streaming-writes: true

mountOptions:
    - write:enable-streaming-writes:true

gcsfuse --enable-streaming-writes=true \
  BUCKET_NAME MOUNT_POINT

Gepufferte Lesevorgänge aktivieren

Gepufferte Lesevorgänge können die sequenzielle Leseleistung für große Dateien um das Zwei- bis Fünffache verbessern, indem Teile eines Cloud Storage-Objekts asynchron in einen Arbeitsspeicher-Puffer vorgeholt werden. Dadurch können nachfolgende Lesevorgänge aus dem Puffer bedient werden, ohne dass Netzwerkaufrufe erforderlich sind.

Beachten Sie Folgendes, bevor Sie gepufferte Lesevorgänge aktivieren:

• Gepufferte Lesevorgänge sind nicht mit dem Dateicaching kompatibel. Wenn sowohl gepufferte Lesevorgänge als auch Datei-Caching aktiviert sind, hat das Datei-Caching Vorrang und gepufferte Lesevorgänge werden ignoriert.

• Gepufferte Lesevorgänge können viel Arbeitsspeicher und Rechenressourcen in Anspruch nehmen.

So aktivieren Sie gepufferte Lesevorgänge:

gcsfuse --enable-buffered-read=true \
  BUCKET_NAME

read:
 enable-buffered-read: true

Kernel-Read-Ahead-Größe erhöhen

Bei Arbeitslasten, die hauptsächlich sequenzielle Lesevorgänge großer Dateien umfassen, z. B. Bereitstellungen und Prüfpunktwiederherstellungen, kann die Leistung durch Erhöhen der Read-Ahead-Größe erheblich verbessert werden. Dazu können Sie den Linux-Kernel-Parameter read_ahead_kb auf Ihrem lokalen Computer verwenden. Wir empfehlen, den Kernel-Parameter read_ahead_kb auf 1 MB zu erhöhen, anstatt den Standardwert von 128 KB zu verwenden, der bei den meisten Linux-Distributionen festgelegt ist. Für Compute Engine-Instanzen sind entweder die Berechtigungen sudo oder root erforderlich, um den Kernelparameter zu erhöhen.

So erhöhen Sie den Kernelparameter read_ahead_kb für ein bestimmtes mit Cloud Storage FUSE bereitgestelltes Verzeichnis auf 1 MB: Ihr Bucket muss in Cloud Storage FUSE bereitgestellt sein, bevor Sie den Befehl ausführen. Andernfalls wird der Kernel-Parameter nicht erhöht.

Bei zonalen Buckets verwaltet Cloud Storage FUSE den Kernelparameter read_ahead_kb automatisch in Google Kubernetes Engine-Version 1.35.0-gke.3047001 oder höher und in Compute Engine-Umgebungen mit Cloud Storage FUSE-Version 3.7.0 oder höher. Da dies automatisch erfolgt, ist die Mount-Option read_ahead_kb nicht mehr relevant. Alle von Ihnen angegebenen Werte werden ignoriert. In Compute Engine-Umgebungen erfordert Cloud Storage FUSE Root- oder passwortlose sudo-Berechtigungen, um diesen Parameter automatisch zu verwalten.

mountOptions:
    - read_ahead_kb=1024

export MOUNT_POINT=/path/to/mount/point
echo 1024 | sudo tee /sys/class/bdi/0:$(stat -c "%d" $MOUNT_POINT)/read_ahead_kb

Security Token Service deaktivieren, um redundante Prüfungen zu vermeiden

Der Cloud Storage FUSE-CSI-Treiber für die Google Kubernetes Engine verfügt über Zugriffsprüfungen, um die Wiederherstellbarkeit von Pods sicherzustellen, wenn Nutzer die Workload Identity-Bindungen zwischen dem Bucket und dem GKE-Dienstkonto falsch konfiguriert haben. Dies kann bei großen Datenmengen zu einer Überschreitung der Standardkontingente der Security Token Service API führen. Dies kann deaktiviert werden, indem Sie das Volume-Attribut skipCSIBucketAccessCheck des CSI-Treibers für nichtflüchtige Volumes festlegen. Wir empfehlen, dass Sie dafür sorgen, dass das GKE-Dienstkonto den richtigen Zugriff auf den Cloud Storage-Ziel-Bucket hat, um Mount-Fehler für den Pod zu vermeiden.

Außerdem muss das Kontingent für den Security Token Service über den Standardwert von 6000 erhöht werden, wenn ein Google Kubernetes Engine-Cluster aus mehr als 6.000 Knoten besteht. Wenn das Kontingent bei umfangreichen Bereitstellungen nicht erhöht wird, kann dies zu 429-Fehlern führen. Das Kontingent für den Security Token Service muss über die Seite Kontingente und Limits erhöht werden. Wir empfehlen, das Kontingent an die Anzahl der Bereitstellungen anzupassen. Wenn es beispielsweise 10.000 Bereitstellungen im Cluster gibt, sollte das Kontingent auf 10000 erhöht werden.

So legen Sie das Attribut „skipCSIBucketAccessCheck-Volume“ fest:

  volumeAttributes:
      - skipCSIBucketAccessCheck: "true"
   

Leistung für OCDBT-Orbax-Prüfpunkte optimieren

Bei Arbeitslasten, für die Orbax-Prüfpunkte im OCDBT-Format verwendet werden, können Sie die Leistung beim Bereitstellen und Wiederherstellen von Prüfpunkten mit den folgenden Empfehlungen verbessern:

• Transparente große Seiten auf always festlegen: Wenn Sie transparente große Seiten auf always festlegen, wird die Leistung verbessert, da die Speicherfragmentierung und die Systemaufrufe reduziert werden. Diese Einstellung ist am effektivsten, wenn große Arbeitsspeicherblöcke zugewiesen werden, was bei diesen Arbeitslasten häufig der Fall ist. Diese Einstellung ist standardmäßig auf Cloud TPU-Maschinen konfiguriert und muss nur für andere Maschinentypen festgelegt werden. Führen Sie den folgenden Befehl mit root-Berechtigungen aus, um transparente große Seiten auf Ihrem lokalen Computer zu aktivieren.

  echo always | tee /sys/kernel/mm/transparent_hugepage/enabled
  

  In einer GKE-Umgebung können Sie einen privilegierten Pod erstellen, um dasselbe zu tun.

• Kernel-Read-Ahead-Größe erhöhen: Wenn Sie die Kernel-Read-Ahead-Größe auf 1.024 KB erhöhen, wird die Leistung beim sequenziellen Lesen verbessert. Weitere Informationen finden Sie unter Kernel-Read-Ahead-Größe erhöhen.

• ocdbt_target_data_file_size auf 200 MiB festlegen: Legen Sie ocdbt_target_data_file_size auf 200 MiB fest. Das ist optimal für die Leseleistung mit Cloud Storage FUSE.

• DNS-Caching verwenden: DNS-Caching reduziert die Latenz, da DNS-Lookups lokal im Cache gespeichert werden. In GKE können Sie NodeLocal DNSCache aktivieren, um DNS-Lookups zu cachen. Alternativ können Sie Cloud Storage FUSE Version 3.5 oder höher in Compute Engine oder GKE-Version 1.34.1-gke.3899000 oder höher in einer GKE-Umgebung verwenden.

Weitere Hinweise zur Leistung

Neben den primären Optimierungen, die wir besprochen haben, können auch andere Faktoren die Gesamtleistung von Cloud Storage FUSE erheblich beeinträchtigen. In den folgenden Abschnitten werden zusätzliche Leistungsaspekte beschrieben, die Sie bei der Verwendung von Cloud Storage FUSE berücksichtigen sollten.

Limit für das Umbenennen von Buckets ohne HNS erhöhen

Für Checkpointing-Arbeitslasten sollte immer ein Bucket mit aktiviertem hierarchischem Namespace verwendet werden, da atomare und schnellere Umbenennungen sowie ein höherer QPS für Lese- und Schreibvorgänge möglich sind. Wenn Sie jedoch das Risiko akzeptieren, dass Verzeichnisumbenennungen nicht atomar sind und länger dauern, können Sie das Feld rename-dir-limit oder die Option --rename-dir-limit verwenden, wenn Sie Prüfpunkte mit Buckets ohne hierarchischen Namespace durchführen, um ein Limit für die Anzahl der Dateien oder Vorgänge festzulegen, die zu einem bestimmten Zeitpunkt an einem Verzeichnisumbenennungsvorgang beteiligt sind.

Wir empfehlen, für diese Einstellung einen hohen Wert anzugeben, um Fehler beim Checkpointing zu vermeiden. Da Cloud Storage FUSE einen flachen Namespace verwendet und Objekte unveränderlich sind, müssen beim Umbenennen eines Verzeichnisses alle einzelnen Dateien im Verzeichnis umbenannt und gelöscht werden. Sie können die Anzahl der Dateien, die von einem Umbenennungsvorgang betroffen sind, mit der gcsfuse-Option rename-dir-limit steuern.

Verwenden Sie die folgende Anleitung, um die Konfigurationsoption rename-dir-limit festzulegen:

gcsfuse --rename-dir-limit=200000 \
  BUCKET_NAME

file-system:
 rename-dir-limit: 200000

mountOptions:
    - rename-dir-limit=200000

gcsfuse --rename-dir-limit=200000 \
  BUCKET_NAME MOUNT_POINT

Kernel-Listen-Caching

Der Listen-Cache ist ein Cache für Verzeichnis- und Dateilisten oder ls, Antworten zur Verbesserung der Geschwindigkeit von Listenvorgängen. Im Gegensatz zum Statistik-Cache, der von Cloud Storage FUSE verwaltet wird, wird der Listen-Cache im Seiten-Cache des Kernels gespeichert und vom Kernel basierend auf der Arbeitsspeicherverfügbarkeit gesteuert.

Das Aktivieren des Kernel-Listen-Caching ist für die folgenden Anwendungsfälle am vorteilhaftesten:

• Arbeitslasten mit wiederholten Verzeichnisauflistungen: Diese Konfiguration ist besonders nützlich für Arbeitslasten, die häufig vollständige Verzeichnisauflistungen durchführen, z. B. KI/ML-Trainingsläufe. Das kann sowohl für Serving- als auch für Trainingsarbeitslasten von Vorteil sein.

• Schreibgeschützte Bereitstellungen: Das Caching von Listen wird bei schreibgeschützten Bereitstellungen empfohlen, um Konsistenzprobleme zu vermeiden.

Das Aktivieren des Kernel-Listen-Caching sollte mit Vorsicht erfolgen und nur dann verwendet werden, wenn das Dateisystem wirklich Lesezugriff hat und während der Ausführung eines Jobs keine Änderungen am Verzeichnisinhalt zu erwarten sind. Das liegt daran, dass die lokale Anwendung mit diesem Flag nie Aktualisierungen sieht, insbesondere wenn die TTL auf -1 gesetzt ist.

In Client 1 ist beispielsweise directoryA aufgeführt. Dadurch wird directoryA im Kernel-Listen-Cache gespeichert. Client 2 erstellt fileB unter directoryA im Cloud Storage-Bucket. Client 1 sucht kontinuierlich nach fileB in directoryA. Dabei wird im Wesentlichen der Cache-Eintrag der Kernel-Liste geprüft und es wird nie über das Netzwerk gegangen. Client 1 sieht nicht, dass sich eine neue Datei im Verzeichnis befindet, da die Liste der Dateien kontinuierlich aus dem lokalen Kernel-Listencache bereitgestellt wird. Bei Client 1 tritt dann eine Zeitüberschreitung auf und das Programm wird unterbrochen.

So aktivieren Sie das Listencaching:

gcsfuse --kernel-list-cache-ttl-secs=-1 \
  BUCKET_NAME

file-system:
 kernel-list-cache-ttl-secs: -1

mountOptions:
    - file-system:kernel-list-cache-ttl-secs:-1

gcsfuse --kernel-list-cache-ttl-secs=-1 \
  BUCKET_NAME MOUNT_POINT

Wenn Sie die Bereitstellungsoption file-system:kernel-list-cache-ttl-secs verwenden, haben die Werte die folgende Bedeutung:

• Ein positiver Wert, der die TTL in Sekunden darstellt, um die Antwort der Verzeichnisliste im Seitencache des Kernels zu speichern.

• Der Wert -1 umgeht den Ablauf des Eintrags und gibt die Listenantwort aus dem Cache zurück, wenn sie verfügbar ist.

Persistenten JAX-Kompilierungs-Cache (JIT) mit Cloud Storage FUSE verwenden

JAX unterstützt den Just-In-Time-Cache (JIT), einen optionalen nichtflüchtigen Kompilierungscache, in dem kompilierte Funktionsartefakte gespeichert werden. Wenn Sie diesen Cache verwenden, können Sie nachfolgende Scriptausführungen erheblich beschleunigen, da redundante Kompilierungsschritte vermieden werden.

Damit Sie JIT-Caching aktivieren können, müssen die folgenden Anforderungen erfüllt sein:

• Aktuelle Version von JAX verwenden: Verwenden Sie JAX-Versionen 0.5.1 oder höher, um die neuesten Cachefunktionen und ‑optimierungen zu nutzen.

• Cache-Kapazität maximieren: Um Leistungseinbußen aufgrund von Cache-Entfernung zu vermeiden, sollten Sie eine unbegrenzte Cache-Größe festlegen, insbesondere wenn Sie die Standardeinstellungen überschreiben möchten. Dazu können Sie die Umgebungsvariable festlegen:

  export JAX_COMPILATION_CACHE_MAX_SIZE=-1
  

• YAML für Prüfpunkt-Pod prüfen: Verwenden Sie die Prüfpunktkonfiguration für den Mountpoint für den JAX-JIT-Cache.

Receive Flow Steering (RFS) für A4X konfigurieren

Auf Compute Engine-Instanzen arbeiten Receive Packet Steering (RPS) und Receive Flow Steering (RFS) zusammen, um die Netzwerkleistung zu verbessern. Dazu wird die Verarbeitung von Netzwerkpaketen intelligent auf mehrere CPUs verteilt. Wir empfehlen diese Einstellungen für Netzwerkverkehr mit hoher Rate auf Maschinentypen wie A4X.

• RPS verteilt eingehende Netzwerkpakete zur Verarbeitung auf verschiedene CPUs. Dies hilft, die Last auszugleichen und zu verhindern, dass eine einzelne CPU zu einem Engpass wird. Das ist besonders nützlich für Netzwerkverkehr mit hoher Rate und kann zu einer niedrigeren Latenz beitragen.

• RFS baut auf RPS auf, um die Netzwerklatenz durch eine verbesserte CPU-Cache-Effizienz weiter zu reduzieren. Sie leitet Pakete an den spezifischen CPU-Kern weiter, auf dem die Anwendung ausgeführt wird, die die Pakete verarbeitet. Dadurch wird die Trefferrate des CPU-Datencaches erhöht und die Netzwerklatenz verringert.

Leistungsvorteile

RFS verbessert die Leistung bei verschiedenen Arbeitslasten erheblich und erhöht den Durchsatz um bis zu 40%.

Hinweise

Diese Einstellungen sind zwar unter Last effektiv, aber möglicherweise nicht in allen Szenarien nützlich:

• Single-Thread- oder Single-Flow-Arbeitslasten:Eine Single-Flow-Arbeitslast tritt auf, wenn der gesamte Netzwerkverkehr eine einzelne Netzwerkverbindung verwendet, z. B. eine einzelne massive Dateiübertragung über eine TCP-Verbindung. Diese Anwendungen profitieren oft kaum und können sogar einen geringfügigen Rückgang des Durchsatzes verzeichnen (z.B. ca.7,7 % in bestimmten nginx-Tests). Anwendungen mit einem einzelnen Datenfluss sind in Hochleistungskontexten im Allgemeinen selten.

• Häufige Thread-Migration: Wenn Anwendungs-Threads häufig zwischen CPUs verschoben werden, aktualisiert RFS ständig die CPU-Zuweisungen(z. B. bei Anwendungen, die große dynamische Arbeitsthread-Pools verwenden, in denen Anfragen häufig zwischen verschiedenen Kernen übergeben werden). Dies kann zu übermäßigem CPU-übergreifenden Traffic und einer Neuordnung von Paketen führen.

Konfigurationsskript

Führen Sie das folgende Script auf dem Gastbetriebssystem Ihrer Compute Engine-Instanz aus. Für das Skript sind die Berechtigungen sudo oder root erforderlich, um Kernelparameter zu ändern.

Das Script aktiviert RPS, ordnet Netzwerk-Warteschlangen im Round-Robin-Verfahren verfügbaren CPUs zu und legt die Größe der Flusstabelle pro Warteschlange auf 65.536 fest.

#!/bin/bash
set -e

# Note: This script uses 'apt' and is intended for Debian-based systems.
# If 'iproute2' is not found, you may need to run 'sudo apt update' first.
sudo apt install -y iproute2

# This script enables and configures RPS (Receive Packet Steering) and RFS
# (Receive Flow Steering) for the primary network interface.
# It creates a 1:1 mapping of CPUs to receive queues and sets a specific
# flow count for each queue.

# --- Configuration ---
# The desired number of flow entries per receive queue.
RPS_FLOW_CNT_PER_QUEUE=65536

# --- Script Body ---

# 1. Auto-detect the primary network interface.
INTERFACE=$(ip route | grep default | awk '{print $5}' | head -n 1)

if [ -z "$INTERFACE" ]; then
  echo "Error: Could not determine the primary network interface."
  exit 1
fi
echo "Primary network interface detected: $INTERFACE"

echo "Starting RPS/RFS configuration for interface: $INTERFACE"

# 2. Determine the number of receive queues for the interface.
NUM_QUEUES=$(ls -d /sys/class/net/$INTERFACE/queues/rx-* 2>/dev/null | wc -l)
if [ "$NUM_QUEUES" -eq 0 ]; then
  echo "Error: No receive queues found for interface $INTERFACE."
  echo "Please check if the network driver supports multi-queue."
  exit 1
fi
echo "Found $NUM_QUEUES receive queues for interface $INTERFACE."

# 3. Determine the number of CPUs.
NUM_CPUS=$(nproc)
if [ -z "$NUM_CPUS" ] || [ "$NUM_CPUS" -eq 0 ]; then
  echo "Error: Could not determine the number of CPUs."
  exit 1
fi
echo "Found $NUM_CPUS CPUs."

# 4. Calculate and set the total socket flow entries.
# This is the total number of entries in the global socket flow table.
RPS_SOCK_FLOW_ENTRIES=$((NUM_QUEUES * RPS_FLOW_CNT_PER_QUEUE))
echo "Setting the total RPS socket flow entries to $RPS_SOCK_FLOW_ENTRIES..."
if ! echo "$RPS_SOCK_FLOW_ENTRIES" | sudo tee /proc/sys/net/core/rps_sock_flow_entries > /dev/null; then
  echo "Error: Failed to set rps_sock_flow_entries. Please run with sufficient privileges."
  exit 1
fi

# 5. Configure each receive queue.
for i in $(seq 0 $((NUM_QUEUES - 1))); do
  RX_QUEUE="/sys/class/net/$INTERFACE/queues/rx-$i"

  # a) Assign a CPU to this queue (round-robin).
  CPU_INDEX=$((i % NUM_CPUS))
  CPU_BITMAP_HEX=$(printf '%x' $((1 << CPU_INDEX)))
  echo "Assigning CPU $CPU_INDEX (bitmap: $CPU_BITMAP_HEX) to queue rx-$i"
  if ! echo "$CPU_BITMAP_HEX" | sudo tee "$RX_QUEUE/rps_cpus" > /dev/null; then
    echo "Error writing bitmap to $RX_QUEUE/rps_cpus"
    exit 1
  fi

  # b) Set the flow count for this queue.
  echo "Setting flow count for $RX_QUEUE to $RPS_FLOW_CNT_PER_QUEUE"
  if ! echo "$RPS_FLOW_CNT_PER_QUEUE" | sudo tee "$RX_QUEUE/rps_flow_cnt" > /dev/null; then
    echo "Error writing to $RX_QUEUE/rps_flow_cnt"
    exit 1
  fi
done

echo "RPS and RFS configuration updated successfully for $INTERFACE."

Nächste Schritte

• Verwenden Sie eine YAML-Beispieldatei für die Google Kubernetes Engine, um Best Practices für die Optimierung zu konfigurieren.

• Weitere Informationen zu profilbasierten Konfigurationen für KI/ML-Arbeitslasten

• Leistung des Cloud Storage FUSE-CSI-Treibers in der Google Kubernetes Engine optimieren