Schreibt die DB in regelmäßigen Abständen die Änderungen aus dem Arbeitsspeicher gebündelt auf den Datenträger, werden Queries in diesem Moment langsam.
Warum Aufgelaufene Änderungen werden regelmäßig auf den Datenträger geschrieben → Folge Der Datenträger ist in diesem Moment ausgelastet, Queries verzögern sich → Auf dem Bildschirm Speichern und Laden werden in festen Abständen langsam
Checkpoints in kleine Schritte aufteilen und gleichmäßig verteilen, Transaktionslog (Redo-Log, WAL) großzügig bemessen, schnelle Datenträger einsetzen.
Im Graphen
Spitzen in festen Abständen · DB-Query-Latenz, Disk-Schreibvolumen
Wo nachsehen
PostgreSQL: Checkpoint-Zeitpunkte und geschriebene Buffer im Log von log_checkpoints (in neueren Versionen standardmäßig an), Anzahl der Checkpoints (ab 17 num_timed und num_requested in pg_stat_checkpointer, bis 16 checkpoints_timed und checkpoints_req in pg_stat_bgwriter) und checkpoint_warning-Warnungen prüfen. MySQL: im Abschnitt LOG von SHOW ENGINE INNODB STATUS die Differenz zwischen Log sequence number und Last checkpoint at prüfen. Disk-Schreibvolumen und Schreiblatenz des Servers darüberlegen
Spricht dafür
Spitzen der Query-Latenz fallen mit Checkpoint-Zeitpunkten zusammen, gleichzeitig schießen Disk-Schreibvolumen und Schreiblatenz hoch. Gibt es in PostgreSQL deutlich mehr angeforderte Checkpoints (num_requested) als zeitgesteuerte (num_timed), erreicht WAL oft max_wal_size, und Checkpoints werden vorgezogen
Spricht dagegen
Spitzen in einem Rhythmus ohne Bezug zu den Checkpoint-Zeitpunkten: Backup oder Batch-Job (dk-backup, db-batch)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Ist das Transaktionslog, das die Änderungen aufnimmt (Redo-Log bei MySQL, WAL bei PostgreSQL), zu klein, muss die DB bei jedem vollen Log hastig einen Checkpoint durchziehen. Der Schreibdurchsatz bricht dann immer wieder kurz stark ein.
Quellen
WAL Configuration (PostgreSQL Documentation)PostgreSQL Checkpoint standardmäßig alle 5 Minuten oder alle 1 GB WAL (max_wal_size), teuer, weil alle Dirty Pages geschrieben werden. checkpoint_completion_target verteilt die Schreibvorgänge und vermeidet I/O-Spitzen. Ist der Checkpoint-Abstand kürzer als checkpoint_warning, steht im Log eine Warnung, max_wal_size zu erhöhen
Configuring Buffer Pool FlushingMySQL Ist das Redo-Log voll, sinkt der Durchsatz durch einen hastigen (sharp) Checkpoint kurzzeitig; adaptives Flushing verteilt die Schreibvorgänge gleichmäßig