10 Punkte von xguru 2021-11-15 | 1 Kommentare | Auf WhatsApp teilen
  • Heap betreibt ein Multi-Petabyte-Postgres für Analysen

  • Mit dem schnellen Wachstum stieg die Auslastung der Nodes über 80 %, wodurch in der Erfassungs-Pipeline Performance-Probleme auftraten

  • Die Ursache war, dass SSDs dazu neigen, an Performance zu verlieren, wenn ihre Auslastung sich 100 % nähert

  • Die Probleme wurden dadurch verschärft, dass ZFS als CoW-System (Copy-on-Write) eingesetzt wird

→ Jedes Mal, wenn ein Block aktualisiert wird, wird eine neue Kopie geschrieben

  • Natürlich hat CoW auch verschiedene Vorteile

→ Komprimierung auf Dateisystemebene ist im Vergleich zu anderen Dateisystemen einfacher, wodurch mit 4–5x Komprimierung Speicher gespart wird

→ Höhere Haltbarkeit ermöglicht es, full_page_writes von Postgres zu deaktivieren, was wiederum die Performance verbessert und die gesamte IO reduziert

→ Point-in-time-Snapshots, die Konsistenz garantieren – da Pages tatsächlich unveränderlich sind, bleiben ältere Pages auch während eines Snapshots erhalten

  • Allerdings verlieren CoW-Dateisysteme wie ZFS an Performance, wenn sie sich füllen

→ Bei jedem Page-Update muss der Block-Allocator freie Blöcke finden, daher verschlechtert sich die Performance bei hoher Auslastung deutlich

→ Zuvor unlinked Blöcke müssen gelöscht und mit bestehenden Blöcken vermischt werden

→ Um eine höhere Kompressionsrate zu erzielen, wurde die Blockgröße groß auf 64 KB gesetzt, was die Situation weiter verschlechterte

→ Aus diesen Gründen sollte die Auslastung von ZFS besser nicht über 80 % steigen

  • Es wurde versucht, durch ein Upgrade auf ZFS 2.x von lz4-Komprimierung auf Zstandard-Komprimierung umzustellen

→ lz4 ist extrem schnell und erreicht eine Kompressionsrate von etwa 4,4x

→ Zstandard erreicht eine Kompressionsrate von bis zu etwa 5,5x und verbessert sie damit um 20 %

→ Viele Benchmarks zeigen jedoch, dass Zstandard langsamer ist als lz4

→ Deshalb wurde beschlossen, unter realen Bedingungen strenge Tests durchzuführen

→ Das Testergebnis: Die Query-Performance blieb unverändert, der Storage-Verbrauch sank um etwa 20 %, und die Laufzeit von Schreib-Queries halbierte sich

  • Der DB-Cluster von Heap ist in fünf Nodes aufgeteilt, die jeweils zu einer eigenen ASG gehören

→ Für einen Node-Wechsel genügt es, ihn aus der ASG zu entfernen; die ASG erstellt dann einen neuen Node, stellt ihn aus dem letzten Backup wieder her und versetzt ihn in den Warm-Standby-Modus

→ Es wurde eine AMI mit der neuen Konfiguration erstellt und dann jeder Node einzeln umgestellt

→ Insgesamt sank der Verbrauch um etwa 21 %, die Schreibzeit verringerte sich um 50 %, und bei der Query-Performance gab es kaum Unterschiede

1 Kommentare

 
xguru 2021-11-15

Im Artikel wird die CPU-Auslastung nicht erwähnt, aber laut dem Kommentar des Originalautors auf HN ist sie von ~40 % auf ~50 % gestiegen. (Das heißt, Zstd nutzt mehr CPU.)