<p>- Heap betreibt ein Multi-Petabyte-Postgres für Analysen<br />
- Mit dem schnellen Wachstum stieg die Auslastung der Nodes über 80 %, wodurch in der Erfassungs-Pipeline Performance-Probleme auftraten <br />
- Die Ursache war, dass SSDs dazu neigen, an Performance zu verlieren, wenn ihre Auslastung sich 100 % nähert<br />
- Die Probleme wurden dadurch verschärft, dass ZFS als CoW-System (Copy-on-Write) eingesetzt wird <br />
→ Jedes Mal, wenn ein Block aktualisiert wird, wird eine neue Kopie geschrieben <br />
- Natürlich hat CoW auch verschiedene Vorteile<br />
→ Komprimierung auf Dateisystemebene ist im Vergleich zu anderen Dateisystemen einfacher, wodurch mit 4–5x Komprimierung Speicher gespart wird <br />
→ Höhere Haltbarkeit ermöglicht es, `full_page_writes` von Postgres zu deaktivieren, was wiederum die Performance verbessert und die gesamte IO reduziert <br />
→ Point-in-time-Snapshots, die Konsistenz garantieren – da Pages tatsächlich unveränderlich sind, bleiben ältere Pages auch während eines Snapshots erhalten<br />
- Allerdings verlieren CoW-Dateisysteme wie ZFS an Performance, wenn sie sich füllen<br />
→ Bei jedem Page-Update muss der Block-Allocator freie Blöcke finden, daher verschlechtert sich die Performance bei hoher Auslastung deutlich <br />
→ Zuvor unlinked Blöcke müssen gelöscht und mit bestehenden Blöcken vermischt werden <br />
→ Um eine höhere Kompressionsrate zu erzielen, wurde die Blockgröße groß auf 64 KB gesetzt, was die Situation weiter verschlechterte <br />
→ Aus diesen Gründen sollte die Auslastung von ZFS besser nicht über 80 % steigen <br />
<br />
- Es wurde versucht, durch ein Upgrade auf ZFS 2.x von lz4-Komprimierung auf Zstandard-Komprimierung umzustellen <br />
→ lz4 ist extrem schnell und erreicht eine Kompressionsrate von etwa 4,4x <br />
→ Zstandard erreicht eine Kompressionsrate von bis zu etwa 5,5x und verbessert sie damit um 20 % <br />
→ Viele Benchmarks zeigen jedoch, dass Zstandard langsamer ist als lz4<br />
→ Deshalb wurde beschlossen, unter realen Bedingungen strenge Tests durchzuführen <br />
→ Das Testergebnis: Die Query-Performance blieb unverändert, der Storage-Verbrauch sank um etwa 20 %, und die Laufzeit von Schreib-Queries halbierte sich <br />
<br />
- Der DB-Cluster von Heap ist in fünf Nodes aufgeteilt, die jeweils zu einer eigenen ASG gehören <br />
→ 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 <br />
→ Es wurde eine AMI mit der neuen Konfiguration erstellt und dann jeder Node einzeln umgestellt <br />
→ Insgesamt sank der Verbrauch um etwa 21 %, die Schreibzeit verringerte sich um 50 %, und bei der Query-Performance gab es kaum Unterschiede </p>
1 Kommentare