Hinweise zur Leistung

Auf dieser Seite finden Sie eine Anleitung zum Konfigurieren Ihrer Parallelstore-Umgebung, um die beste Leistung zu erzielen.

Allgemeine Empfehlungen

  • Entfernen Sie alle Aliasse aus ls, um die Standardleistung zu verbessern. Auf vielen Systemen ist es mit ls -color=auto aliasiert, was bei der Standardkonfiguration von Parallelstore viel langsamer ist.

  • Wenn die Leistung von Listenvorgängen zu gering ist, sollten Sie das Caching für die dfuse-Bindung aktivieren.

Bibliothek für die Datenabfang

Mit der libioil-Bibliothek lässt sich die Leistung von Lese- und Schreibvorgängen von Anwendungen, die libc verwenden, für DFuse verbessern. Die Bibliothek umgeht den Kernel, indem sie POSIX-Lese- und Schreibaufrufe von der Anwendung abfängt, um sie direkt im Userspace zu bearbeiten. Weitere Informationen finden Sie unter Abfangbibliothek.

In den meisten Fällen empfehlen wir die Verwendung der Interception Library pro Prozess oder pro Anwendung.

In folgenden Fällen sollten Sie die Interception Library nicht verwenden:

  • Nur Anwendungen, die mit libc erstellt wurden, können die Interception Library verwenden.
  • Wenn Sie eine Arbeitslast haben, die vom Caching profitiert, z. B. wenn wiederholt auf dieselben Dateien zugegriffen wird, empfehlen wir, die Interception Library nicht zu verwenden.
  • Wenn Ihre Arbeitslast metadatenintensiv ist, z. B. wenn Sie mit vielen kleinen Dateien oder einem sehr großen Verzeichnislisten arbeiten, verbessert die Interception Library die Leistung wahrscheinlich nicht.

Die LD_PRELOAD-Aufrufmethode kann in Ihrer Shell-Umgebung als Umgebungsvariable festgelegt werden. Dies kann jedoch manchmal zu Problemen führen. Wir empfehlen, sie stattdessen bei jedem Befehl anzugeben.

Alternativ können Sie die Interception Library mit dem Flag -lioil zur Kompilierungszeit in Ihre Anwendung einbinden.

dfuse-Caching

Das Caching ist in dfuse standardmäßig aktiviert.

dfuse verwendet beim Bereitstellen einer Parallelstore-Instanz zwei cachebezogene Flags:

  • --disable-wb-cache verwendet Write-Through- statt Write-Back-Caching.
  • --disable-caching deaktiviert das gesamte Caching.

Die folgenden Vorschläge beziehen sich auf Caching und Leistung:

  • Wenn Sie die Interception Library verwenden, wird das Writeback-Caching umgangen. Wir empfehlen, --disable-wb-cache anzugeben, wenn Sie die Interception Library verwenden.
  • Wenn bei Ihrer Arbeitslast viele Dateien einmal gelesen werden, sollten Sie das Caching deaktivieren.
  • Bei Arbeitslasten, bei denen viele Clients Dateien ändern und die Updates sofort für andere Clients verfügbar sein müssen, müssen Sie das Caching deaktivieren.
  • Wenn bei Ihrer Arbeitslast wiederholt dieselben Dateien gelesen werden, kann das Caching die Leistung verbessern. Das gilt insbesondere, wenn die Dateien in den Arbeitsspeicher der Kunden passen. dfuse verwendet den Linux-Seitencache für das Caching.

  • Bei Arbeitslasten, die aus kleinen E/A-Vorgängen für große Dateien bestehen, kann es sich lohnen, neben dem Aktivieren des Caching auch den Wert für den verteilten Readahead zu erhöhen. Wenn Sie die Vorab-Lesevorgänge von dfuse erhöhen möchten, führen Sie nach dem Bereitstellen von dfuse die folgenden Befehle aus:

    echo 4096 > /sys/class/bdi/\$(mountpoint -d /mnt)/read_ahead_kb
echo 100 > /sys/class/bdi/\$(mountpoint -d /mnt)/max_ratio

Wenn Ihre Arbeitslasten eine Mischung aus den oben genannten Szenarien umfassen, können Sie dieselbe Parallelstore-Instanz an mehreren Bereitstellungspunkten mit unterschiedlichen Caching-Einstellungen bereitstellen.

Threadanzahl und Ereigniswarteschlangenanzahl

Beim Bereitstellen Ihrer Parallelstore-Instanz empfehlen wir die folgenden Werte für --thread-count und --eq-count:

  • Die Anzahl der Threads darf die Anzahl der vCPU-Kerne nicht überschreiten.
  • Die maximal empfohlene Anzahl von Threads liegt zwischen 16 und 20. Darüber hinaus gibt es unabhängig von der Anzahl der verfügbaren Kerne nur einen geringen oder gar keinen Leistungsvorteil.
  • Der Wert für die Ereigniswarteschlange sollte halb so hoch wie der Wert für die Threadanzahl sein.

Wenn Ihre Arbeitslast eine sehr hohe Anzahl von Vorgängen mit kleinen Dateien und einen intensiven Metadatenzugriff umfasst, können Sie die Werte über diese Empfehlungen hinaus erhöhen.

Einstellung für die Dateiaufteilung

Beim Dateistriping wird eine Datei in Blöcke oder Streifen aufgeteilt und auf mehrere Speicherziele verteilt. Durch Dateistreifen kann die Leistung erhöht werden, da paralleles Lesen und Schreiben in mehreren Speicherzielen möglich ist, die die Instanz unterstützen.

Beim Erstellen einer Parallelstore-Instanz können Sie eine der drei Einstellungen für das Dateistriping angeben:

  • Minimum
  • Ausgeglichen
  • Maximum

Diese Einstellungen können sich erheblich auf die Leistung des Parallelspeichers auswirken. Für die meisten Arbeitslasten empfehlen wir die Einstellung „Ausgewogen“. Wenn die Leistung bei der ausgewogenen Einstellung nicht zufriedenstellend ist:

  • Die Mindesteinstellung kann die Leistung bei Arbeitslasten mit vielen kleinen Dateien verbessern, insbesondere wenn die durchschnittliche Dateigröße unter 256 KB liegt.

  • Die maximale Einstellung kann die Leistung für Arbeitslasten mit sehr großen Dateien verbessern, die in der Regel größer als 8 GB sind, insbesondere wenn viele Clients den Zugriff auf dieselben Dateien teilen.

Für eine erweiterte Optimierung bietet das daos-Tool Einstellungen pro Datei oder pro Verzeichnis. Das Experimentieren mit erweiterten Optimierungsoptionen birgt Leistungsrisiken und wird in der Regel nicht empfohlen. Weitere Informationen finden Sie unter Datenredundanz und Sharding in DAOS.

Einstellung für das Verzeichnis-Striping

Beim Erstellen einer Parallelstore-Instanz können Sie eine von drei Einstellungen für das Verzeichnisstriping angeben:

  • Minimum
  • Ausgeglichen
  • Maximum

Für die meisten Arbeitslasten empfehlen wir die maximale Einstellung.

Bei Arbeitslasten, bei denen viele große Verzeichnisse aufgelistet werden, können die ausgewogenen oder Mindesteinstellungen zu einer besseren Listenleistung führen. Die Leistung anderer Vorgänge, insbesondere die Dateierstellung, kann jedoch beeinträchtigt werden.

Mehrere Nutzer

Wenn Sie die Parallelstore-Instanz mit dem dfuse-Tool bereitstellen, empfehlen wir, das Flag --multi-user anzugeben. Dieses Flag weist den Kernel an, das Dateisystem für alle Nutzer auf einem Client verfügbar zu machen, nicht nur für den Nutzer, der den DFuse-Prozess ausführt. DFuse erscheint dann als generisches Mehrbenutzerdateisystem und die Standardaufrufe chown und chgrp werden aktiviert. Wie in einem POSIX-Dateisystem üblich, sind alle Dateisystemeinträge dem Nutzer zugewiesen, der sie erstellt hat.

Wenn Sie das Flag --multi-user angeben, müssen Sie auch /etc/fuse.conf als Root aktualisieren. Fügen Sie dazu die folgende Zeile hinzu:

user_allow_other

Das Bereitstellen Ihrer Instanz als Multi-User hat offenbar keine Auswirkungen auf die Leistung.

Einstellung für die Löschcodierung

Die Datenträgerbeschädigungscodierung ist auf „2+1“ festgelegt. Diese Einstellung kann später nicht mehr geändert werden. Alle I/O-Vorgänge, bei denen EC2+1 nicht verwendet wird, werden abgelehnt.

Ressourcenzuweisung für Sidecar-Container in der Google Kubernetes Engine

In den meisten Fällen ist die unzureichende Leistung mit Google Kubernetes Engine und Parallelstore auf eine unzureichende CPU- oder Arbeitsspeicherzuweisung für den Parallelstore-Sidecar-Container zurückzuführen. Beachten Sie die folgenden Vorschläge, um Ressourcen richtig zuzuweisen:

  • Lesen Sie die Hinweise unter Ressourcen für den Sidecar-Container konfigurieren. Sie erfahren, warum Sie die Ressourcenzuweisung möglicherweise erhöhen müssen, und wie Sie die Ressourcenzuweisung für Sidecar-Container mit Pod-Anmerkungen konfigurieren.

  • Mit dem Wert 0 können Sie alle Ressourcenlimits oder ‑anforderungen in Standardclustern deaktivieren. Wenn Sie beispielsweise gke-parallelstore/cpu-limit: 0 und gke-parallelstore/memory-limit: 0 festlegen, sind die CPU- und Arbeitsspeicherlimits des Sidecar-Containers leer und die Standardanfragen werden verwendet. Diese Einstellung ist nützlich, wenn Sie nicht wissen, wie viele Ressourcen dfuse für Ihre Arbeitslasten benötigt, und möchten, dass alle verfügbaren Ressourcen auf einem Knoten verwendet werden. Sobald Sie anhand Ihrer Arbeitslastmesswerte ermittelt haben, wie viele Ressourcen dfuse benötigt, können Sie entsprechende Limits festlegen.

  • In Autopilot-Clustern können Sie den Wert 0 nicht verwenden, um die Ressourcenlimits und ‑anfragen für Sidecar-Container zurückzusetzen. Sie müssen in Autopilot-Clustern explizit ein höheres Ressourcenlimit für den Sidecar-Container festlegen und anhand von Google Cloud Messwerten entscheiden, ob das Ressourcenlimit erhöht werden muss.