Eine Anfrage, Daten „sicher“ auf den Datenträger zu schreiben, dauert je nach Datenträger 0,1 ms bis einige Dutzend ms. Häufen sich solche Anfragen, wird die Warteschlange lang.
Warum Regelmäßiges Speichern und Logout-Wellen lösen massenhaft Anfragen zum sicheren Schreiben aus → Folge Disk-Warteschlange wird länger → Auf dem Bildschirm Lag zu jedem Speicherzeitpunkt, verzögerter Logout und Kanalwechsel
Speichervorgänge bündeln (mehrere Speichervorgänge mit einem fsync), Speicherzeitpunkte verteilen.
Aufgaben Infrastrukturteam
Server/OS: Server-SSDs mit Stromausfallschutz einsetzen, Länge der Disk-Warteschlange und fsync-Latenz überwachen. DB-Systeme: Geht das Speichern in die DB, auch den Datenträger für das DB-Log auf solche SSDs legen, Commit-Latenz überwachen.
Größenordnungen
Die Dauer pro Aufruf hängt von der Hardware ab, grob gilt: Server-SSD (mit Stromausfallschutz) 0,1 ms, normale SSD 1 bis einige ms, Cloud-Datenträger 1–2 ms, HDD mindestens 10 ms. Wartet ein einzelner Thread jeden Aufruf einzeln ab, schafft eine HDD nicht einmal 100 pro Sekunde.
Im Graphen
Spitzen in festen Abständen · Länge der Disk-Warteschlange, Flush- und Schreiblatenz
Wo nachsehen
f/s und f_await (vom Datenträger verarbeitete Flushes und deren Dauer) sowie w/s, aqu-sz und w_await aus iostat -x 1 über die Zeitpunkte von regelmäßigem Speichern und Logouts legen. Ältere sysstat-Versionen zeigen aqu-sz als avgqu-sz. Bei Cloud-Datenträgern VolumeQueueLength und VolumeAvgWriteLatency von EBS prüfen
Spricht dafür
Zu jedem Speicherzeitpunkt und jeder Logout-Welle schießen Flush-Anzahl und Warteschlangenlänge gemeinsam hoch, w_await und f_await erreichen ein Mehrfaches des Normalwerts. Speichern und Kanalwechsel verzögern sich dann
Spricht dagegen
Warteschlange schießt zu Zeiten ohne Speichern oder Logouts hoch: Backup oder Komprimierung (dk-backup) oder IOPS-Limit (dk-iops). Gleiche Flush-Anzahl, aber langsamer: eher aufgebrauchte Burst-Credits (dk-burst)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
fsync(2) — Linux manual pageLinux man-pages fsync leert auch den Disk-Cache und blockiert, bis das Gerät den Abschluss meldet
Reliability (PostgreSQL Documentation)PostgreSQL Normale SATA-Festplatten und viele SSDs haben Schreibcaches, deren Inhalt bei Stromausfall verloren geht, für sicheres Speichern ist ein Cache mit Batterie oder Stromausfallschutz nötig
Amazon EBS General Purpose SSD volumesAWS Latenz des Standard-Cloud-Datenträgers (gp3) im einstelligen Millisekundenbereich, io2 Block Express bei 16-KiB-I/O im Mittel unter 500 µs
iostat(1) — Linux manual pagesysstat -x: f/s und f_await (vom Datenträger verarbeitete Flush-Anfragen und deren durchschnittliche Dauer), w/s, w_await, aqu-sz (früher avgqu-sz)
Amazon CloudWatch metrics for Amazon EBSAWS VolumeQueueLength (Anzahl der Anfragen, die auf Abschluss warten), VolumeAvgWriteLatency (Schreiblatenz im 1-Minuten-Mittel, Nitro-Instanzen)