CrestVPS

postgresql vps

Datenbanken und In-Memory-Workloads

Genug Speicher, dass die Festplatte keine Rolle mehr spielt.

Was wir bereitstellen würden

125,30 €/Mo

179 €30% jährlich

Ab einer bestimmten Working-Set-Größe ist die einzige Optimierung, die zählt, das Ganze in den RAM zu bekommen. FORGE bietet bis zu sechzehn Gigabyte pro Kern an registriertem ECC-Speicher mit vorkonfigurierten Hugepages und NUMA-bewusster Platzierung, was PostgreSQL, Redis, ClickHouse und große JVM-Heaps wollen. Darunter liegt Gen5-NVMe in RAID10, damit auch die Schreibvorgänge, die auf die Festplatte treffen, nicht der Engpass sind.

Warum diese Konfiguration

FORGE mit Single-NUMA-Affinität hält den Speicherzugriff lokal auf dem Socket, der die Arbeit verrichtet. Fügen Sie nächtliche Backups mit 30 Wiederherstellungspunkten hinzu, denn der Fehlerfall, den Sie tatsächlich erleben, ist eine schlechte Migration, nicht eine tote Festplatte.

Was wir bereitstellen würden

PlanFORGE F2
vCPU8 (dedicated)
RAM128 GB
Speicher800 GB
ImageDebian 13 Trixie

Sizing

Bemessen Sie RAM auf die Working Set, nicht auf die Datenbank. Die Working Set ist heiße Indexseiten plus tatsächlich berührte Zeilen, oft 10-20% eines 2 TB OLTP-Datensatzes. Setzen Sie den InnoDB Buffer Pool auf 70-75% des RAMs, oder Postgres shared_buffers auf 25% und lassen Sie den Seiten-Cache den Rest halten. FORGE erreicht 16 GB pro Kern, also sitzt ein 512 GB Buffer Pool auf etwa 700 GB RAM und mindestens 44 Kernen. Wenn Lesevorgänge den Cache mehr als 1% der Zeit verfehlen, kaufen Sie RAM.

Hugepages und warum THP nicht dasselbe ist

Ein 256 GB Buffer Pool, der in 4 KB Seiten abgebildet wird, braucht etwa 64 Millionen Page-Table-Einträge. Die TLB kann keinen sinnvollen Bruchteil davon halten, also zahlt ein zufälliger Zugriff bei den meisten Lookups einen Page-Walk. Statische 2 MB Hugepages reduzieren die Eintragszahl um den Faktor 512 und die Walks damit – erwarten Sie einen messbaren Rückgang der CPU-Zeit pro Abfrage bei großen Pools. Weisen Sie sie beim Boot über vm.nr_hugepages zu, bemessen Sie sie für den Pool plus etwa 10%, und geben Sie dem Datenbank-Benutzer das memlock-Limit. Transparente Hugepages erreichen dieselbe Abbildung, aber opportunistisch, mit Kompaktierungs-Stalls. Deaktivieren Sie THP und weisen Sie explizit zu.

Working Set, gemessen statt geraten

Schätzen Sie die Working Set nicht aus der Größe des Datenverzeichnisses. Messen Sie sie. In Postgres sagt Ihnen pg_buffercache, welche Relationen shared_buffers belegen, und das Verhältnis von heap_blks_hit zu heap_blks_read in pg_statio_user_tables ergibt die Cache-Trefferquote pro Tabelle. In MySQL gibt Innodb_buffer_pool_reads gegenüber Innodb_buffer_pool_read_requests dasselbe Signal. Über 99% sind Sie im Speicher und zusätzlicher RAM kauft wenig. Zwischen 95% und 99% sind Sie am Rande der Klippe, und eine einzelne nicht indizierte Abfrage kann Sie darüber stoßen. Unter 95% ist jede Latenzzahl, die Sie haben, wirklich eine Festplatten-Latenzzahl in Verkleidung.

Was schiefgeht

  • Transparente Hugepages aktiviert lassen. THP-Defragmentierung stoppt den Prozess für Millisekunden zu unvorhersehbaren Zeiten, was sich als p99-Latenz zeigt, die niemand erklären kann. Setzen Sie es auf never und weisen Sie statische Hugepages stattdessen zu.
  • NUMA bei einem Zwei-Socket-FORGE ignorieren. Der Buffer Pool landet auf einem Node, die halbe Kerne lesen über den Interconnect, und MySQL kann trotz freiem Speicher swappen. Verwenden Sie numactl --interleave=all oder binden Sie explizit.
  • IOPS anhand des Durchsatzes im Durchschnitt bemessen. Checkpoints, Vakuum und Backups sind die Spitzen, die zählen. Ein Pool, der den stationären Zustand problemlos bewältigt, wird die gesamte Instanz während eines Checkpoint-Flushes anhalten.

Maschine optimieren

  • CPU-SchedulingSingle-NUMA-node affinity · 14 €
  • BackupsDaily backup, 30 restore points · 11 €
  • SonstigesSecond-resolution metrics + alerting · 5 €
  • Speicher und VerschlüsselungZFS with hourly snapshots · 7 €