vps postgresql
Bases de données et charges en mémoire
Assez de mémoire pour que le disque cesse de compter.
Ce que nous déploierions
125,30 €/mois
179 €−30% annuel
Au-delà d'une certaine taille de working set, la seule optimisation qui compte est de faire tenir le tout en RAM. FORGE offre jusqu'à seize gigaoctets par cœur de mémoire ECC enregistrée avec des hugepages préconfigurés et un placement NUMA-aware, ce que PostgreSQL, Redis, ClickHouse et les grandes heaps JVM veulent. En dessous, c'est du Gen5 NVMe en RAID10, donc les écritures qui touchent le disque ne sont pas non plus le goulot d'étranglement.
Pourquoi cette configuration
FORGE avec affinité NUMA simple garde l'accès mémoire local au socket qui fait le travail. Ajoutez des sauvegardes nocturnes avec trente points de restauration, car le mode de défaillance que vous rencontrerez réellement est une mauvaise migration, pas un disque mort.
Ce que nous déploierions
Dimensionnement
Dimensionnez la RAM pour le working set, pas pour la base de données. Le working set est composé des pages d'index chaudes plus des lignes réellement touchées, souvent 10 à 20 % d'un ensemble OLTP de 2 To. Définissez le pool de buffers InnoDB à 70-75 % de la RAM, ou shared_buffers de Postgres à 25 % et laissez le cache de pages contenir le reste. FORGE atteint 16 Go par cœur, donc un pool de buffers de 512 Go repose sur environ 700 Go de RAM et au moins 44 cœurs. Si les lectures manquent le cache plus de 1 % du temps, achetez de la RAM.
Hugepages, et pourquoi THP n'est pas la même chose
Un pool de buffers de 256 Go mappé en pages de 4 Ko nécessite environ 64 millions d'entrées de table de pages. Le TLB ne peut pas contenir une fraction significative de cela, donc l'accès aléatoire paie une marche de page sur la plupart des recherches. Les hugepages statiques de 2 Mo réduisent le nombre d'entrées de 512 et les marches avec — attendez-vous à une baisse mesurable du temps CPU par requête sur de grands pools. Allouez-les au démarrage via vm.nr_hugepages, dimensionnez pour le pool plus environ 10 %, et donnez à l'utilisateur de la base de données la limite memlock. Les hugepages transparents réalisent le même mappage mais le font de manière opportuniste, avec des arrêts de compactage. Désactivez THP et allouez explicitement.
Working set, mesuré plutôt que deviné
N'estimez pas le working set à partir de la taille du répertoire de données. Mesurez-le. Dans Postgres, pg_buffercache vous dit quelles relations occupent shared_buffers, et le ratio de heap_blks_hit à heap_blks_read dans pg_statio_user_tables donne le taux de succès de cache par table. Dans MySQL, Innodb_buffer_pool_reads par rapport à Innodb_buffer_pool_read_requests donne le même signal. Au-dessus de 99 %, vous êtes en mémoire et ajouter de la RAM achète peu. Entre 95 % et 99 %, vous êtes au bord du gouffre, et une seule requête non indexée peut vous faire basculer. En dessous de 95 %, chaque chiffre de latence que vous avez est en réalité une latence de disque déguisée.
Ce qui va de travers
- Laisser les hugepages transparents activés. La défragmentation THP stoppe le processus pendant des millisecondes à des moments imprévisibles, ce qui apparaît comme une latence p99 que personne ne peut expliquer. Réglez-le sur never et allouez des hugepages statiques à la place.
- Ignorer NUMA sur un FORGE à deux sockets. Le pool de buffers atterrit sur un nœud, la moitié des cœurs lisent à travers l'interconnect, et MySQL peut swapper malgré la mémoire libre. Utilisez numactl --interleave=all ou liez explicitement.
- Dimensionner les IOPS à partir du débit moyen. Les checkpoints, le vacuum et les sauvegardes sont les pics qui comptent. Un pool qui gère l'état stable bien s'arrêtera pendant un flush de checkpoint.
Réglez la machine
- Planification CPU — Single-NUMA-node affinity · 14 €
- Sauvegardes — Sauvegarde quotidienne, trente points de restauration · 11 €
- Tout le reste — Métriques et alertes à résolution seconde · 5 €
- Stockage et chiffrement — ZFS with hourly snapshots · 7 €
Plus
Conçu pour des tâches spécifiques
Hébergement de serveurs de jeux
Le tick rate est un problème mono-thread. Tout le reste est du bruit.
VPS de trading et basse latence
Distance au moteur de correspondance, et rien entre vous et la ligne.
Endpoints VPN et proxy privé
Votre propre sortie, dans une juridiction choisie délibérément.
Seedboxes et stockage volumineux
Des téraoctets qui restent bon marché et un port qui reste ouvert.
Nœuds workers Kubernetes
Pas cher par cœur, dense, et identique à chaque fois.
Inférence IA et fine-tuning
Un GPU entier, transféré, sur un engagement qui rend les calculs rentables.