한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Game-Lag-Whitepaper › L12 Datenbank

Kalter Cache (direkt nach Neustart) Cold buffer pool after restart

Ursachen-ID db-cold-cache · Hauptzuständig DB-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Nach einem Neustart der DB ist der Cache im Arbeitsspeicher leer, und eine Zeit lang wird jede Abfrage vom Datenträger gelesen.

Warum DB-Neustart wegen Wartung → Folge Häufig genutzte Daten liegen nicht im Arbeitsspeicher und werden vom Datenträger gelesen → Auf dem Bildschirm Direkt nach der Wartung sind Login und Laden eine Zeit lang langsam

Symptome
Kein Login / Endlos-Laden, Input-Lag
Faktoren
Latenz
Wer ist betroffen
Ganzer Server
Wann
Direkt nach Login oder Wartung
Zuständigkeit
Hauptzuständig DB-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Aufgaben Entwicklungsteam
Schrittweise öffnen (die Zahl der Logins über eine Login-Warteschlange stufenweise erhöhen).
Aufgaben Infrastrukturteam
Cache nach dem Neustart vorwärmen (Warm-up, Einstellungen zum Sichern und Wiederherstellen des Buffer Pools prüfen), bei aus Snapshots wiederhergestellten DBs auch den Datenträger vorab lesen.
Im Graphen
Ansturm direkt nach Login oder Wartung · Disk-Lesezugriffe, Trefferquote des Buffer-Caches
Wo nachsehen
MySQL: Verhältnis von Innodb_buffer_pool_reads (Lesevorgänge vom Datenträger, weil die Daten nicht im Buffer Pool lagen) zu Innodb_buffer_pool_read_requests sowie den Fortschritt des Vorwärmens in Innodb_buffer_pool_load_status prüfen. PostgreSQL: blks_read und blks_hit in pg_stat_database prüfen. Auch die Disk-Lesezugriffe des DB-Servers prüfen
Spricht dafür
Direkt nach dem Neustart schießen die Disk-Lesezugriffe hoch und die Trefferquote ist niedrig, mit der Zeit erholt sie sich; in diesem Zeitraum sind Login und Laden langsam
Spricht dagegen
Trefferquote normal, direkt nach der Wartung trotzdem langsam: Login-Ansturm und N+1 (db-login-storm) oder Connection-Pool (db-pool)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
MySQL speichert beim Herunterfahren die Seitenliste des Buffer Pools und liest die Seiten beim Start im Hintergrund wieder ein. Bis der Pool wieder voll ist, dauert es aber. Wurde die DB in der Cloud aus einem Snapshot (Kopie eines Datenträgers) wiederhergestellt, ist auch der Datenträger selbst bei jedem erstmals gelesenen Block langsam, und es dauert noch länger.
Reale Fälle
Roblox 2021: Roblox, 73-stündiger Ausfall: Contention im Service-Discovery-Cluster (Consul)

Quellen

  1. Saving and Restoring the Buffer Pool State MySQL
    Um das Vorwärmen nach dem Neustart zu verkürzen, wird beim Herunterfahren eine Liste der zuletzt genutzten Seiten (Standard 25 %) gespeichert und beim Start wieder eingelesen, beides standardmäßig aktiv
  2. pg_prewarm — preload relation data into buffer caches PostgreSQL
    Schreibt den Inhalt der Shared Buffers regelmäßig weg und lädt ihn nach dem Neustart wieder (autoprewarm)
  3. Initialize Amazon EBS volumes AWS
    Aus einem Snapshot erstellte Volumes haben höhere Latenz und geringere Leistung, bis alle Blöcke geholt sind
  4. Server Status Variables MySQL
    Innodb_buffer_pool_reads (logische Lesevorgänge, die nicht aus dem Buffer Pool bedient werden konnten und direkt vom Datenträger lesen mussten), Innodb_buffer_pool_read_requests, Innodb_buffer_pool_load_status (Fortschritt des Vorwärmens)
  5. The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
    blks_read (vom Datenträger gelesene Blöcke) und blks_hit (im Buffer-Cache gefundene Blöcke) in pg_stat_database

Verwandte Ursachen

Gleiche Schicht: L12 Datenbank

Ursachen aus anderen Schichten mit demselben Symptom (Kein Login / Endlos-Laden)

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen