gcloud CLI-Leistung für zonale Buckets optimieren

Wenn Sie Objekte aus zonalen Buckets in Rapid Bucket mithilfe der Google Cloud CLI lesen, wendet die CLI automatisch Standardkonfigurationen für Nebenläufigkeit und Slicing basierend auf den verfügbaren Systemressourcen an.

In diesem Dokument werden diese Standardkonfigurationen beschrieben und es wird erläutert, wie Sie die gcloud CLI-Leistung für bestimmte Arbeitslasten optimieren können. Dazu konfigurieren Sie die Nebenläufigkeit, die Prozessskalierung und optionale Funktionen wie die NIC-Isolierung.

Bevor Sie die Leistungseinstellungen optimieren, müssen Sie einen zonalen Bucket erstellen. Wenn Sie Objekte auf ein angehängtes Speicher-Volume wie Hyperdisk oder eine lokale SSD herunterladen, müssen Sie das Volume in Ihrer Umgebung formatieren und bereitstellen. Wenn Sie zonale Buckets als Dateisystem bereitstellen möchten, anstatt die gcloud CLI zu verwenden, finden Sie weitere Informationen unter Cloud Storage FUSE-Leistung für Rapid Bucket. Allgemeine Konzepte zum Slicing finden Sie unter Segmentierte Objektdownloads.

Standardkonfigurationen für Nebenläufigkeit und Slicing

Die in diesem Abschnitt beschriebenen Standardkonfigurationen gelten speziell, wenn Sie Objekte aus zonalen Buckets in Rapid Bucket mit der gcloud CLI-Version 583.0.0 oder höher lesen. Für Standard-Cloud Storage-Buckets wendet die gcloud CLI eigene Standardeinstellungen für die Nebenläufigkeit an.

Bei zonalen Buckets legt die gcloud CLI automatisch Standardparameter für Nebenläufigkeit und Slicing fest. Diese basieren auf der Anzahl der verfügbaren virtuellen CPU-Kerne (vCPU) und darauf, ob Sie ein einzelnes Objekt oder mehrere Objekte herunterladen. Mit diesen Standardeinstellungen werden die folgenden Attribute konfiguriert:

In den folgenden Abschnitten sind die Standardwerte für Downloads einzelner und mehrerer Objekte aufgeführt.

Downloads einzelner Objekte

Wenn Sie ein einzelnes Objekt herunterladen, wendet die gcloud CLI die folgenden Standardwerte an:

Verfügbare vCPUs Anzahl der Prozesse Threadanzahl Schwellenwert für die Aufteilung Maximale Anzahl von Komponenten Komponentengröße
≥ 8 8 2 50 MiB 16 5 MiB
< 8 4 2 50 MiB 8 5 MiB

Downloads mehrerer Objekte

Wenn Sie mehrere Objekte gleichzeitig herunterladen, wendet die gcloud CLI die folgenden Standardwerte an:

Verfügbare vCPUs Anzahl der Prozesse Threadanzahl Schwellenwert für die Aufteilung Maximale Anzahl von Komponenten Komponentengröße
≥ 48 min(96, available_cores * 0.75) 1 10 MiB 5 5 MiB
4 to 47 16 4 10 MiB 10 5 MiB
< 4 2 10 50 MiB 10 5 MiB

Attribute für Nebenläufigkeit und Slicing konfigurieren

So konfigurieren Sie benutzerdefinierte Abstimmungseinstellungen und wenden sie an:

  1. Installieren oder aktualisieren Sie die Google Cloud CLI auf Version 583.0.0 oder höher.

  2. Führen Sie in Ihrer Entwicklungsumgebung den Befehl gcloud config configurations create aus, um ein Konfigurationsprofil zu erstellen und zu aktivieren:

    gcloud config configurations create CONFIGURATION_NAME

    Ersetzen Sie CONFIGURATION_NAME durch einen Namen für Ihr Konfigurationsprofil, z. B. rapid-perf.

  3. Führen Sie den Befehl gcloud config set aus, um die Attribute für Nebenläufigkeit und Slicing zu konfigurieren:

    gcloud config set storage/thread_count THREAD_COUNT
gcloud config set storage/process_count PROCESS_COUNT
gcloud config set storage/sliced_object_download_threshold THRESHOLD_SIZE
gcloud config set storage/sliced_object_download_component_size COMPONENT_SIZE
gcloud config set storage/sliced_object_download_max_components MAX_COMPONENTS

    Ersetzen Sie Folgendes:

    • THREAD_COUNT: die Anzahl der Threads pro Worker-Prozess, z. B. 1.
    • PROCESS_COUNT: die Anzahl der Worker-Prozesse, z. B. 64.
    • THRESHOLD_SIZE: die Mindestgröße des Objekts, ab der das Slicing ausgelöst wird, z. B. 128 MiB für Arbeitslasten mit mehreren Gigabyte (oder 32 MiB für kleinere Objekte).
    • COMPONENT_SIZE: Die Zielgröße jedes Download-Segments, z. B. 128 MiB für Arbeitslasten mit mehreren Gigabyte (oder 32 MiB für kleinere Objekte).
    • MAX_COMPONENTS: die maximale Anzahl von Slice-Komponenten pro Objekt, z. B. 16.

    Weitere Informationen zu diesen Attributen finden Sie unter Optimierungsempfehlungen.

  4. Führen Sie den Befehl gcloud storage cp aus, um Objekte in Ihren lokalen Speicherpfad herunterzuladen:

    gcloud storage cp -r gs://BUCKET_NAME/SOURCE_PATH LOCAL_DESTINATION_PATH

    Ersetzen Sie Folgendes:

    • BUCKET_NAME: der Name Ihres zonalen Buckets.
    • SOURCE_PATH: das Quellverzeichnis oder der Objektpfad in Ihrem Bucket.
    • LOCAL_DESTINATION_PATH: der Pfad Ihres lokalen Verzeichnisses (z. B. ./data/) oder der Bereitstellungspunkt Ihres lokalen Speicher-Volumes (z. B. /mnt/hyperdisk/data/).

Empfehlungen: Feinabstimmung

Verwenden Sie die folgenden Empfehlungen, um Nebenläufigkeit, Slicing und Systemressourcen für Ihre Arbeitslasten zu optimieren.

Anzahl der Prozesse

Legen Sie die Eigenschaft storage/process_count fest, um parallele Worker-Prozesse basierend auf den verfügbaren CPU-Kernen zu skalieren. Begrenzen Sie die Anzahl der Prozesse auf maximal 80% der verfügbaren CPU-Kerne:

storage/process_count = min(target_cores, 0.8 * available_cores)

Wobei:

  • target_cores: die Anzahl der CPU-Kerne oder Worker-Prozesse, die Sie für die Übertragung zuweisen möchten (z. B. 64).
  • available_cores: die Gesamtzahl der virtuellen CPUs (vCPUs), die auf Ihrem Computer verfügbar sind (z. B. durch Ausführen von nproc unter Linux).

Wenn Ihr Ziel beispielsweise 64 Worker-Prozesse auf einer Maschine mit 80 oder mehr vCPUs ist, setzen Sie storage/process_count auf 64. Legen Sie auf einer Maschine mit weniger als 80 vCPUs storage/process_count auf 80% der verfügbaren vCPUs fest (z. B. 51 auf einer VM mit 64 vCPUs).

Threadanzahl

Legen Sie das Attribut storage/thread_count fest, um die Anzahl der Threads pro Worker-Prozess zu steuern. Legen Sie auf Maschinen mit 48 oder mehr vCPUs storage/thread_count auf 1 fest.

Wenn Sie jeden Worker-Prozess auf Maschinen mit 48 oder mehr vCPUs auf einen einzelnen Thread beschränken, werden Python Global Interpreter Lock (GIL) und gRPC-Thread-Konflikte reduziert.

Schwellenwert für die Aufteilung

Legen Sie das Attribut storage/sliced_object_download_threshold fest, um die Mindestgröße des Objekts anzugeben, die erforderlich ist, um Downloads in Slices auszulösen.

Wir empfehlen, storage/sliced_object_download_threshold auf einen Wert festzulegen, der größer oder gleich storage/sliced_object_download_component_size ist.

Slices pro Objekt

Legen Sie die Attribute storage/sliced_object_download_component_size und storage/sliced_object_download_max_components fest, um die Anzahl der parallelen Slices zu steuern, die pro Objekt generiert werden. Die gcloud CLI berechnet Slices pro Objekt mit der folgenden Formel:

Slices per object = min(object_size / component_size, max_components)

Wenn ein Objekt so groß ist, dass die Aufteilung nach dem component_size-Wert den max_components-Wert überschreiten würde, ignoriert die gcloud CLI den component_size-Wert und teilt das Objekt gleichmäßig in max_components-Slices auf. Wenn Sie beispielsweise ein 100-GiB-Objekt mit component_size=128 MiB und max_components=16 herunterladen, werden 16 Slices mit jeweils 6,25 GiB erstellt.

Die gcloud CLI lädt jeden Slice unabhängig und parallel herunter, basierend auf Ihrer gesamten Worker-Kapazität (storage/process_count × storage/thread_count).

Worker-Sättigung

Damit die Worker-Auslastung während einer Übertragung hoch bleibt, müssen Sie die Anzahl der Prozesse, die Anzahl der Threads, die Komponentengröße und die maximale Anzahl von Komponenten anpassen. Durch diese Anpassungen wird sichergestellt, dass bei typischen Übertragungen genügend Slices generiert werden, um die Gesamtkapazität der Worker zu erreichen oder zu überschreiten:

Total slices across all objects >= storage/process_count * storage/thread_count

Angenommen, Sie möchten vier Objekte mit 64 Worker-Prozessen (process_count=64 und thread_count=1) herunterladen:

  • Vier 2-GiB-Objekte: Wenn Sie component_size=128 MiB festlegen, werden 16 Slices pro Objekt generiert (4 × 16 = 64 Slices), wodurch alle 64 Worker-Prozesse vollständig genutzt werden.
  • Vier 512-MiB-Objekte: Wenn Sie component_size=32 MiB festlegen, werden 16 Slices pro Objekt generiert (4 × 16 = 64 Slices), wodurch alle 64 Worker-Prozesse vollständig ausgelastet werden. Im Gegensatz dazu werden bei Verwendung von component_size=128 MiB für 512-MiB-Objekte nur 4 Slices pro Objekt (insgesamt 16 Slices) erzeugt, sodass 48 Worker-Prozesse inaktiv bleiben.

NIC-Isolation

Auf Linux-Computern mit mehr als 16 CPU-Kernen können Sie die Netzwerkkarte (NIC) isolieren, indem Sie das Attribut storage/use_nic_isolation auf True setzen:

gcloud config set storage/use_nic_isolation True

Wenn Sie dieses Attribut aktivieren, legt die gcloud CLI die CPU-Affinität (os.sched_setaffinity()) fest. Diese Konfiguration isoliert 10% der CPU-Kerne für Interruptanfragen (IRQs) der Netzwerkhardware und reserviert die verbleibenden Kerne für die Datenverarbeitung.

Nächste Schritte