noisia – Generator für schädliche Workloads für PostgreSQL

• Failure-Injection-Tool, das gezielt Ausfallsituationen wie erschöpfte Verbindungen/Warten auf Locks/Deadlocks/OOM/zu wenig Speicherplatz erzeugt und testbar macht
• Unterstützt vielfältige Workloads, von Idle-Transaktionen/Rollbacks/Deadlocks/temporären Dateien/Beenden von Backends bis hin zu WAL-Explosionen/Table Bloat
• Einige Workloads können über erschöpfte max_connections, Replikationsverzögerungen und nachlassende Storage-Performance hinaus eine PANIC oder einen vollständigen Neustart der PostgreSQL-Instanz auslösen
• Kann direkt als Docker-Image ausgeführt werden; einzelne Workloads lassen sich auch in Go-Code importieren. Um endlose Ausführung zu vermeiden, sind context und Timeouts zwingend zu verwenden
• Unterstützte Workloads
  • idle transactions: Transaktionen offen halten und nichts tun lassen, um Cleanup (VACUUM) zu behindern und Tabellen/Indizes aufzublähen
  • rollbacks: Absichtlich fehlerhafte Queries ausführen, Fehler erzeugen und die Anzahl der Rollbacks erhöhen
  • waiting transactions: Eine Session sperrt eine Tabelle, nachfolgende Verbindungen warten der Reihe nach und erreichen schließlich das Verbindungslimit (max_connections), wodurch neue Verbindungen blockiert werden
  • deadlocks: Zwei Transaktionen in einen Deadlock bringen, in dem beide jeweils den Lock der anderen wollen
  • temporary files: Daten sortieren lassen, die größer als der Arbeitsspeicher (work_mem) sind, sodass temporäre Dateien auf die Platte geschrieben werden (verschwindet, wenn work_mem erhöht wird)
  • terminate backends: Laufende Sessions/Queries zufällig zwangsweise beenden, etwa mit pg_terminate_backend()
  • failed connections: Alle Verbindungen belegen, sodass andere Clients sich gar nicht mehr verbinden können. Das Limit von max_connections ist ausgeschöpft
  • fork connections: Jedes Mal nur kurze Queries über neue Verbindungen absetzen, damit Postgres übermäßig viele Kindprozesse erzeugt
  • backend-killer: Eine Session häuft fortlaufend prepared statements an, bläht den Speicher auf und bewirkt per OOM-Kill einen Neustart der gesamten Instanz
  • slot-bloat: Ein Replication Slot, aus dem niemand liest, hält WAL zurück, füllt pg_wal bis zur vollen Festplatte und versetzt die Instanz in PANIC
  • wal-flood: Erzeugt mit parallelen UPDATE-Workern eine WAL-Flut und damit Replikationsverzögerungen/IO-Druck (die „sichtbare“ Version von slot-bloat; ob die Festplatte voll läuft, hängt von der Umgebung ab)
  • bloat-churn: Bläht Tabellen durch parallele UPDATEs schneller auf als autovacuum sie bereinigen kann; nach dem Stoppen kann dies mit VACUUM FULL/pg_repack/REINDEX CONCURRENTLY rückgängig gemacht werden
• Nicht ausführen, ohne es vollständig verstanden zu haben; Nutzung nur zu Testzwecken
• BSD-3-Clause-Lizenz