CrestVPS

postgresql vps

Databases en in-memory workloads

Genoeg geheugen dat de schijf niet meer uitmaakt.

Wat wij zouden implementeren

€ 125,30/mnd

€ 17930% jaarlijks

Voorbij een bepaalde working-set-grootte is de enige optimalisatie die telt het hele ding in RAM passen. FORGE geeft tot zestien gigabyte per core van registered ECC-geheugen met hugepages voorgeconfigureerd en NUMA-bewuste plaatsing, wat is wat PostgreSQL, Redis, ClickHouse en grote JVM-heaps willen. Eronder zit Gen5 NVMe in RAID10, dus de writes die wel naar schijf gaan zijn ook niet de bottleneck.

Waarom deze configuratie

FORGE met single-NUMA-affiniteit houdt geheugentoegang lokaal aan de socket die het werk doet. Voeg nachtelijke back-ups toe met dertig herstelpunten, want de faalmodus die je daadwerkelijk zult tegenkomen is een slechte migratie, niet een dode schijf.

Wat wij zouden implementeren

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

Sizing

Maat RAM op de working set, niet de database. De working set is hete indexpagina's plus rijen die daadwerkelijk worden aangeraakt, vaak 10-20% van een 2 TB OLTP-dataset. Stel de InnoDB buffer pool in op 70-75% van RAM, of Postgres shared_buffers op 25% en laat de page cache de rest houden. FORGE bereikt 16 GB per core, dus een 512 GB buffer pool zit op ongeveer 700 GB RAM en minimaal 44 cores. Als reads meer dan 1% van de tijd cache missen, koop RAM.

Hugepages, en waarom THP niet hetzelfde is

Een 256 GB buffer pool die is gemapt in 4 KB-pagina's heeft ongeveer 64 miljoen page table entries nodig. De TLB kan daar geen betekenisvolle fractie van bevatten, dus willekeurige toegang betaalt een page walk bij de meeste lookups. Statische 2 MB hugepages verminderen het aantal entries met 512 en de walks ermee — verwacht een meetbare daling in CPU-tijd per query op grote pools. Wijs ze toe bij boot via vm.nr_hugepages, maat voor de pool plus ongeveer 10%, en geef de databasegebruiker de memlock-limiet. Transparante hugepages bereiken dezelfde mapping maar doen het opportunistisch, met compaction stalls. Schakel THP uit en wijs expliciet toe.

Working set, gemeten in plaats van gegokt

Schat de working set niet uit de datamapgrootte. Meet het. In Postgres vertelt pg_buffercache je welke relaties shared_buffers bezetten, en de verhouding van heap_blks_hit tot heap_blks_read in pg_statio_user_tables geeft de cache-hitrate per tabel. In MySQL geeft Innodb_buffer_pool_reads tegen Innodb_buffer_pool_read_requests hetzelfde signaal. Boven 99% zit je in het geheugen en koop je met extra RAM weinig. Tussen 95% en 99% sta je op de klifrand, en een enkele ongeïndexeerde query kan je eroverheen duwen. Onder 95% is elk latentiegetal dat je hebt eigenlijk een schijflatentiegetal in vermomming.

Wat er mis kan gaan

  • Transparante hugepages ingeschakeld laten. THP-defragmentatie stalt het proces voor milliseconden op onvoorspelbare momenten, wat zich toont als p99-latentie die niemand kan verklaren. Zet het op never en wijs in plaats daarvan statische hugepages toe.
  • NUMA negeren op een twee-socket FORGE. De buffer pool landt op één node, de helft van de cores leest over de interconnect, en MySQL kan swappen ondanks vrij geheugen. Gebruik numactl --interleave=all of bind expliciet.
  • IOPS meten vanaf gemiddelde doorvoer. Checkpoints, vacuum en back-ups zijn de pieken die ertoe doen. Een pool die de stabiele toestand prima aan kan, zal de hele instantie stallen tijdens een checkpoint-flush.

Tweak de machine

  • CPU-planningSingle-NUMA-node affinity · € 14
  • Back-upsDaily backup, 30 restore points · € 11
  • Al het andereSecond-resolution metrics + alerting · € 5
  • Opslag en encryptieZFS with hourly snapshots · € 7