vps postgresql
Database e carichi di lavoro in-memory
Abbastanza memoria che il disco smette di contare.
Cosa implementeremmo
125,30 €/mese
179 €−30% annuale
Oltre una certa dimensione del working set, l'unica ottimizzazione che conta è far stare tutto in RAM. FORGE dà fino a sedici gigabyte per core di ECC memoria registrata con hugepages preconfigurati e placement NUMA-aware, che è ciò che PostgreSQL, Redis, ClickHouse e grandi heap JVM vogliono. Sotto c'è NVMe Gen5 in RAID10, quindi anche le scritture che colpiscono il disco non sono il collo di bottiglia.
Perché questa configurazione
FORGE con affinità single-NUMA mantiene l'accesso alla memoria locale al socket che fa il lavoro. Aggiungi backup notturni con trenta punti di ripristino, perché il modo di guasto che colpirai davvero è una migrazione sbagliata, non un disco morto.
Cosa implementeremmo
Dimensionamento
Dimensiona la RAM sul working set, non sul database. Il working set è pagine di indice calde più righe effettivamente toccate, spesso il 10-20% di un dataset OLTP da 2 TB. Imposta il buffer pool InnoDB al 70-75% della RAM, o shared_buffers di Postgres al 25% e lascia che la cache di pagina tenga il resto. FORGE arriva a 16 GB per core, quindi un buffer pool da 512 GB sta su circa 700 GB di RAM e almeno 44 core. Se le letture mancano la cache più dell'1% delle volte, compra RAM.
Hugepages, e perché THP non è la stessa cosa
Un buffer pool da 256 GB mappato in pagine da 4 KB ha bisogno di circa 64 milioni di voci di page table. La TLB non può contenere una frazione significativa di quelle, quindi l'accesso casuale paga un page walk sulla maggior parte dei lookup. Hugepages statici da 2 MB riducono il conteggio delle voci di 512 e i walk insieme — aspettati una diminuzione misurabile del tempo CPU per query su pool grandi. Allocali al boot tramite vm.nr_hugepages, dimensiona per il pool più circa il 10% e dai all'utente del database il limite memlock. I transparent hugepages ottengono la stessa mappatura ma lo fanno opportunisticamente, con stalli di compattazione. Disabilita THP e alloca esplicitamente.
Working set, misurato piuttosto che indovinato
Non stimare il working set dalla dimensione della directory dei dati. Misuralo. In Postgres, pg_buffercache ti dice quali relazioni occupano shared_buffers, e il rapporto tra heap_blks_hit e heap_blks_read in pg_statio_user_tables dà il tasso di hit per tabella. In MySQL, Innodb_buffer_pool_reads contro Innodb_buffer_pool_read_requests dà lo stesso segnale. Sopra il 99% sei in memoria e aggiungere RAM compra poco. Tra il 95% e il 99% sei sul bordo del precipizio, e una singola query non indicizzata può spingerti oltre. Sotto il 95% ogni numero di latenza che hai è in realtà un numero di latenza del disco travestito.
Cosa va storto
- Lasciare abilitati i transparent hugepages. La deframmentazione THP ferma il processo per millisecondi in momenti imprevedibili, che si mostra come latenza p99 che nessuno può spiegare. Impostalo su never e alloca hugepages statici invece.
- Ignorare NUMA su un FORGE a due socket. Il buffer pool finisce su un nodo, metà dei core legge attraverso l'interconnect, e MySQL può fare swap nonostante memoria libera. Usa numactl --interleave=all o vincola esplicitamente.
- Dimensionare gli IOPS dalla media del throughput. Checkpoint, vacuum e backup sono i picchi che contano. Un pool che gestisce lo stato stazionario bene durante un checkpoint flush fermerà l'intera istanza.
Configura la macchina
- Scheduling CPU — Single-NUMA-node affinity · 14 €
- Backup — Daily backup, 30 restore points · 11 €
- Tutto il resto — Second-resolution metrics + alerting · 5 €
- Storage e crittografia — ZFS with hourly snapshots · 7 €
Altro
Progettate per lavori specifici
Hosting per server di gioco
Il tick rate è un problema single-thread. Tutto il resto è rumore.
VPS per trading e bassa latenza
Distanza dal matching engine, e niente tra te e il wire.
Endpoint VPN e proxy privati
La tua uscita, in una giurisdizione scelta apposta.
Seedbox e storage bulk
Terabyte che restano economici e una porta che resta aperta.
Nodi worker Kubernetes
Economico per core, denso, e identico ogni volta.
Inferenza AI e fine-tuning
Una GPU intera, passata attraverso, su un impegno che fa funzionare la matematica.